Техническая разница между аутентификацией на основе сеанса и токена

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

Итак, я сравнивал методы аутентификации на основе сеанса и токена, но есть несколько моментов, которые мне неясны относительно того, как работают токены и чем они лучше, чем аутентификация сеанса:

Единственные преимущества, которые мне на 100% ясны, заключаются в том, что токены могут использоваться от клиентов, у которых нет хранилища файлов cookie, и что их можно использовать с разными поддоменами и полностью отдельными доменами, потому что это не препятствует политике CORS браузеров.

  • Я читал, что все файлы cookie отправляются с каждым запросом в исходный домен (за исключением случаев, когда cookie настроен на отправку только по безопасному соединению), что означает, что токен будет присутствовать дважды в запросе, если, конечно, вы не аутентифицируете пользователи из другого домена. Это правильное предположение?
  • Как проходит проверка токена на сервере? После дешифрования, проверяется ли он по имени пользователя, паролю и секретному / закрытому ключу, или здесь используется только секретный / закрытый ключ?
  • Если мне нужно имя пользователя / идентификатор пользователя при авторизации их для определенного ресурса на сервере, на котором я не аутентифицировал их, могу ли я слепо доверять этим учетным данным, если у меня нет исходных данных пользователя для проверки?

Наконец, во многих статьях утверждается, что токены защищают от CSRF.

Из этой статьи:

CSRF: у нас также будет защита от подделки межсайтовых запросов (CSRF). Пользователи подвержены атакам CSRF, поскольку они уже могут быть аутентифицированы, скажем, на банковском сайте, и этим можно воспользоваться при посещении других сайтов.

Что для меня не имеет никакого смысла. Кажется, он говорит, что система типа OAuth предотвращает CSRF? Я не очень разбираюсь в том, как работает CSFR, поэтому здесь может быть только я, но, насколько я понимаю, ни сеансы, ни токены не защищают от этого, поскольку ни один из них не уникален для каждого запроса.

Изменить: Я только что понял, что токены могут препятствовать CSFR в том, что они не отправляются автоматически браузером, если другому сайту удается отправить форму на ваш сервер из вашего браузера. Но это означает, что токены могут быть восприимчивыми, если они извлечены из заголовка cookie на сервере, что, если вы используете JWT, не должно быть проблемой, поскольку он использует собственный заголовок авторизации, который вы должны установить с помощью JS. Но из-за этого утверждения статей на scotch.io кажутся мне чепухой.


person Hjort-e    schedule 29.11.2016    source источник


Ответы (1)


Подробное описание характеристики традиционных систем аутентификации на основе файлов cookie и более современной системы на основе токенов.

TL; DR Аутентификация на основе токенов актуальна как никогда. Мы исследуем различия и сходства между аутентификацией на основе файлов cookie и токенов, преимущества использования токенов и решаем общие вопросы и проблемы, которые возникают у разработчиков в отношении аутентификации на основе токенов.

Я не большой поклонник этой точной терминологии, потому что то, что вы фактически помещаете в файл cookie, также можно считать токеном; в большинстве случаев это токен по ссылке, который сопоставляется с некоторыми данными на стороне сервера, в то время как так называемая аутентификация на основе токена поддерживает токены по значению (JWT - Изучить веб-токены JSON), которые несут данные внутри самого токена.

JSON Web Token (JWT) - это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Эту информацию можно проверить и доверять, потому что она имеет цифровую подпись.

Проверка этих маркеров по значению выполняется с помощью подписей, которые гарантируют, что маркер был создан сущностью, содержащей связанный ключ, используемый во время подписания, и что содержимое не может быть изменено кем-либо еще без знания ключа. Эта предпосылка является основанием для доверия полученным токенам.

Что касается CSRF, это правда, что система на основе токенов будет смягчать это, потому что, в отличие от того, что происходит с файлами cookie, браузер не будет автоматически отправлять эти учетные данные токенов (предполагается, что токены не включены в запрос в виде файлов cookie).

Представьте себе следующее: приложение CK предоставляет ресурсы, защищенные с помощью файлов cookie сеанса, а приложение TK предоставляет ресурсы, защищенные токенами.

Пользователь X аутентифицируется в обоих приложениях, и поэтому ему будет выдан файл cookie сеанса для приложения CK и токен для приложения TK. Если злоумышленник создает вредоносный сайт EV и обманом заставляет пользователя X посетить его, он может выполнять автоматические запросы к приложению CK и TK из браузера пользователя.

Однако для приложения CK браузер пользователя X автоматически включит файл cookie сеанса, и поэтому злонамеренный сайт EV только что получил доступ к защищенному ресурсу, в то время как для запроса приложения TK браузер не будет включать токен автоматически.

person João Angelo    schedule 29.11.2016