Ответ 1
Сеансовая аутентификация
При аутентификации на основе сеансов сервер выполняет всю тяжелую работу на стороне сервера. Вообще говоря, клиент аутентифицируется с помощью своих учетных данных и получает session_id (который может быть сохранен в cookie) и присоединяет его к каждому последующему исходящему запросу. Так что это можно считать "токеном", поскольку он является эквивалентом набора учетных данных.
Однако в этом session_id-String нет ничего особенного. Это просто идентификатор, а сервер делает все остальное. Это с состоянием. Он связывает идентификатор с учетной записью пользователя (например, в памяти или в базе данных). Он может ограничить или ограничить этот сеанс определенными операциями или определенным периодом времени и может сделать его недействительным, если есть проблемы с безопасностью и, что более важно, он может делать и изменять все это на лету.
Кроме того, он может регистрировать пользователей каждый шаг на веб-сайте (ах). Возможными недостатками являются плохая масштабируемость (особенно для более чем одной фермы серверов) и интенсивное использование памяти.
Tok en- на основе аутентификации
В аутентификации на основе 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 использует краткосрочные и специальные токены-носители и долгосрочные токены обновления, например, для получения токенов-носителей.
Источники: