Я хочу знать, что более безопасно реализовать для аутентификации? & Why? Аутентификация на основе сеанса или аутентификация на основе токена
Я знаю, что сеансы могут использоваться и для других вещей, но сейчас меня интересует только проверка подлинности.
Верно ли, что на стороне сервера ничего не хранится, если использовать токены (даже не в памяти)? Если да, то как оно идентифицируется от истекших жетонов, поскольку это также было подписано с использованием того же самого секретного?
При аутентификации на основе сеансов сервер выполняет всю тяжелую работу на стороне сервера. Вообще говоря, клиент аутентифицируется с помощью своих учетных данных и получает session_id (который может быть сохранен в cookie) и присоединяет его к каждому последующему исходящему запросу. Так что это можно считать "токеном", поскольку он является эквивалентом набора учетных данных.
Однако в этом session_id-String нет ничего особенного. Это просто идентификатор, а сервер делает все остальное. Это с состоянием. Он связывает идентификатор с учетной записью пользователя (например, в памяти или в базе данных). Он может ограничить или ограничить этот сеанс определенными операциями или определенным периодом времени и может сделать его недействительным, если есть проблемы с безопасностью и, что более важно, он может делать и изменять все это на лету.
Кроме того, он может регистрировать пользователей каждый шаг на веб-сайте (ах). Возможными недостатками являются плохая масштабируемость (особенно для более чем одной фермы серверов) и интенсивное использование памяти.
В аутентификации на основе Tok en- ни один сеанс не сохраняется на стороне сервера (без сохранения состояния). Начальные шаги одинаковы. Учетные данные обмениваются с токеном, который затем присоединяется к каждому последующему запросу (его также можно сохранить в файле cookie).
Однако с целью уменьшения использования памяти, легкого масштабирования и общей гибкости (токены могут быть обменены с другим клиентом) выдается строка со всей необходимой информацией (токен), которая проверяется после каждого запроса, сделанного клиентом сервер.
Существует несколько способов использования/создания токенов:
используя механизм хеширования, например, HMAC-SHA1
token = user_id|expiry_date|HMAC(user_id|expiry_date, k)
--id и expiry_id отправляются в виде открытого текста с присоединенным результирующим хешем (k известно только серверу)
шифровать токен симметрично, например, с помощью AES
token = AES(user_id|expiry_date, x)
--x представляет en-/ключ дешифрования
асимметричное шифрование, например, с помощью RSA
token = RSA(user_id|expiry_date, private key)
Продуктивные системы обычно более сложны, чем эти два архетипа. Amazon, например, использует оба механизма на своем веб-сайте. Также гибриды могут использоваться для выдачи токенов, как описано в 2, а также связывать с ним сеанс пользователя для отслеживания пользователя или возможного отзыва и при этом сохранять клиентскую гибкость классических токенов. Кроме того, OAuth 2.0 использует краткосрочные и специальные токены-носители и долгосрочные токены обновления, например, для получения токенов-носителей.
Источники:
Прежде чем я отвечу на ваш вопрос, позвольте мне рассказать вам о плюсах и минусах использования аутентификации на основе токенов и аутентификации на основе сеансов:
Сеансовая аутентификация Плюсы:
Минусы: 1. Сервер хранит пользовательский сеанс в базе данных, кэше или памяти 2. Он должен быть защищен от CRSF
Проверка подлинности токена Доводы
Против 1) Серверу по-прежнему необходимо хранить черные списки токенов, что побеждает цель сохранения состояния 2) При масштабировании необходимо передавать секрет между серверами. 3) данные, хранящиеся в токене, могут устареть, поскольку они кэшируются 4) Самое главное, что он уязвим для атаки XSS. Это означает, что любой вредоносный код, сценарий или атака могут получить доступ или украсть пользовательскую информацию, разрешения и т.д. В случае компрометации
Первый вопрос:
Что безопаснее реализовать? Ответ: аутентификация сеанса
Причины: 1. В любом случае вам все равно нужно поддерживать состояние сервера 2. Ваши данные всегда более защищены на стороне сервера, чем на стороне клиента. 3. Противостоять атакам CSRF легче или проще, чем XSS 4. Сессии легко управляются 5. И данные никогда не устаревают
Второй вопрос Ответ: пользовательские сессии не сохраняются на стороне сервера, кроме отозванных токенов