Я читал об аутентификациях и запутался в классификации типов.

Начнем с проверки подлинности на основе файлов cookie. Если я правильно понимаю, ключевой момент заключается в том, что все данные, необходимые для проверки подлинности пользователя, хранятся в файлах cookie. И это моя первая путаница: в куки мы можем хранить

• идентификатор сеанса, и поэтому он становится аутентификацией на основе сеанса?
• утверждений, и поэтому его следует называть проверкой подлинности на основе утверждений?
• Я обнаружил, что некоторые люди даже хранят токен JWT в cookie, но это похоже на собственную реализацию собственного потока аутентификации ...

Теперь давайте перейдем к аутентификации на основе утверждений. Основным элементом является претензия, а сбор претензий можно использовать в качестве контейнера

• куки (как обсуждено выше)
• токен (JWT в качестве примера).

С другой стороны, когда мы говорим о токене, он может содержать любую информацию ... Идентификатор сессии, например ...

Так что я пропустил? Почему люди не определяют нечто подобное Cookie-Session-basedили Token-Claims-basedаутентификацию, когда говорят о типах аутентификации?

Я согласен с тем, что названия различных концепций сбивают с толку. Говоря об аутентификации в веб-контексте, необходимо учитывать несколько аспектов.

Какую информацию клиент отправляет при аутентификации?

• Идентификатор сеанса . Это означает, что на сервере есть хранилище сеансов, которое содержит активные сеансы. Сеансы сохраняют состояние на стороне сервера.
• Набор претензий . Заявки содержат информацию о том, какие операции может выполнять клиент. Сервер не отслеживает каждого аутентифицированного клиента, но доверяет утверждениям. Заявки, как правило, не сохраняют состояния на стороне сервера.

Как клиент отправляет информацию аутентификации?

• Печенье . Браузеры отправляют куки автоматически с каждым запросом после того, как куки были установлены. Файлы cookie уязвимы для XSRF.
• Другие заголовки . Как правило, для этого используется заголовок авторизации. Эти заголовки не отправляются браузером автоматически, но должны быть установлены клиентом. Это уязвимо для XSS.
• URL запроса . Информация об аутентификации включена в URL. Это обычно не используется.

Каков формат информации аутентификации?

• Простой, неподписанный текст . Это может быть использовано для идентификаторов сеансов. Идентификатор сеанса обычно не угадывается клиентом, поэтому сервер может доверять тому, что клиент не подделал его.
• Json Web Token . JWT криптографически подписаны и содержат информацию об истечении срока действия. Клиент обычно может декодировать токен, но не может изменить его без уведомления сервера.
• Любой другой подписанный формат . То же, что и JWT. Важной вещью является криптографическая подпись, которая предотвращает изменение данных клиентом.

Бонус: как клиент хранит информацию локально

• Печенье . Это, конечно, тот случай, когда файлы cookie используются для передачи информации. Но Cookies также можно использовать как механизм хранения на стороне клиента. Это требует, чтобы cookie был читаемым из сценариев, чтобы быть полезным. Например, клиент может прочитать cookie с помощью JavaScript и отправить информацию с помощью заголовка авторизации.
• Локальное хранилище . Часто это единственный возможный метод, если файлы cookie недоступны. Требуется управление с помощью JavaScript.

Что люди имеют в виду, когда говорят ...

• "Проверка подлинности на основе файлов cookie" . Я нахожу, что это обычно означает «Идентификатор сеанса, отправка cookie, возможно в виде простого текста».
• Msgstr "Аутентификация на основе токена" . Обычно это означает: «Заявки отправляются с использованием заголовка аутентификации, закодированного в виде веб-токена Json».
• "Проверка подлинности на основе утверждений" . Может быть что угодно, кроме идентификатора сеанса.

Проще говоря,

1. Проверка подлинности на основе файлов cookie

   • Веб-клиент (например, веб-браузер) хранит куки, отправленные веб-сервером после успешной аутентификации.
   • Cookie содержит информацию о пользователе, клиенте, метке времени authN и другие полезные данные с уникальным идентификатором для определения cookie.
   • Как правило, cookie-файл шифруется веб-сервером с установленным атрибутом домена (например:) google.comи отправляет его веб-клиенту.
   • Всякий раз, когда веб-клиент хочет получить доступ к ресурсу домена (например, mail.google.com), он отправляет все файлы cookie, основанные на его домене (например, google.com), на веб-сервер, который проверяет / проверяет и разрешает / запрещает доступ на основе состояния и отметки времени печенье.

2. Сеансовая аутентификация

   • Наряду с файлом cookie веб-клиента, если веб-сервер хранит данные авторизации пользователя в его бэкэнде, он будет называться аутентификацией на основе сеанса.
   • Это очень полезно в случае любого нарушения, когда веб-клиент получил доступ к системе, к которой он не должен получить доступ, тогда с серверной части сеанс веб-клиента может быть отменен администратором.

3. Аутентификация на основе токенов

   • Обычно это используется в сценариях, отличных от веб-клиента, где нет способа сохранить cookie на стороне клиента.
   • Следовательно, веб-сервер отправляет подписанный токен (содержащий информацию о пользователе, клиенте, метку времени authN и другие полезные данные с уникальным идентификатором) клиенту после успешной аутентификации.
   • Когда клиент хочет получить доступ к ресурсу, ему необходимо отправить этот токен, и веб-сервер проверяет / проверяет токен, прежде чем разрешить доступ к ресурсу.

4. Аутентификация на основе утверждений

   • Это то же самое, что и аутентификация на основе токена, только добавление в токен дополнительных данных о клиенте и / или пользователе, связанных с клиентом.
   • Эти данные относятся к авторизации, которая говорит о том, что клиент должен делать внутри ресурса (например: mail.read, mail.delete, calendar.read).