Руководство для начинающих, чтобы понять аутентификацию на основе токенов и файлов cookie.
С появлением одностраничных приложений и собственных мобильных приложений аутентификация на основе токенов становится все более популярной. Но что такое аутентификация на основе токенов и чем она отличается от аутентификации на основе файлов cookie?
Чтобы ответить на эти вопросы, мы должны понимать разницу между приложениями без отслеживания состояния и без отслеживания состояния.
Stateful против Stateless
В основном мы взаимодействуем с веб-приложениями с отслеживанием состояния. Например, когда пользователь переходит на Amazon без аутентификации, у него нет доступа к своей учетной записи Amazon. Однако, когда пользователь входит в Amazon, он может видеть свои заказы и добавлять товары в корзину. И если пользователь добавляет товар в корзину и переходит на другую страницу, товары в его корзине сохраняются.
Приложения с отслеживанием состояния сохраняют постоянное соединение между клиентом и сервером. Каждый запрос зависит от предыдущего запроса, и если запрос прерывается, последующий запрос может продолжаться с того места, где был остановлен последний запрос, поскольку состояние приложение где-то хранится. Приложениям с отслеживанием состояния также необходимо различать сеансы.
С другой стороны, всемирная паутина разработана на основе протокола без сохранения состояния, HTTP. В каждой HTTP-транзакции сервер и клиент подтверждают друг друга, а затем обмениваются некоторой информацией. После завершения транзакции клиент и сервер забывают о существовании другого.
Приложения без сохранения состояния не сохраняют никакой информации после запроса; каждый запрос совершенно новый и полностью независимый.
Итак, если всемирная паутина не имеет состояния, как мы можем создавать приложения с отслеживанием состояния на основе этой системы?
Отличный вопрос!
Аутентификация на основе файлов cookie
Дилемма представляет собой традиционный метод аутентификации на основе файлов cookie. Файлы cookie - это небольшие файлы данных, которые содержат информацию о конкретном веб-сеансе. Аутентификация файлов cookie выполняется с отслеживанием состояния. Информация о сеансе аутентификации должна храниться как на клиенте, так и на сервере.
Когда пользователь входит в систему, используя свои учетные данные, сервер создает сеанс, сохраняет его в постоянном хранилище, таком как база данных, и предоставляет клиенту идентификатор сеанса. Затем идентификатор сеанса используется в каждом запросе для проверки сеанса с использованием данных сеанса, хранящихся на сервере.
Есть два типа файлов cookie. Постоянные файлы cookie хранятся на жестком диске пользователя. Они позволяют пользователям повторно посещать веб-сайт, который уже прошел аутентификацию, даже если пользователь закрывает браузер или перезагружает свой компьютер. У этих типов файлов cookie также есть срок годности, который выдается веб-сервером.
С другой стороны, файлы cookie сеанса временно хранятся в памяти. Если пользователь закрывает свою вкладку, браузер или перезапускает компьютер, сеанс прерывается.
Обратной стороной файлов cookie является то, что их сложно поддерживать. Файлы cookie привязаны к одному домену. Это не идеально для одностраничных приложений, потому что SPA может делать запросы к различным типам служб. Файлы cookie также хранятся в двух местах: на клиенте и на сервере. Когда пользователь выходит из системы, сеанс должен быть уничтожен в обоих местах. Кроме того, есть небольшие накладные расходы, чтобы выполнять поиск на сервере при каждом запросе к постоянному хранилищу.
Аутентификация на основе токенов
Аутентификация на основе токенов устраняет некоторые недостатки традиционной аутентификации на основе файлов cookie. Аутентификация на основе токенов не имеет состояния. Серверу не нужно знать данные сеанса. Сервер только подписывает и проверяет токены, чтобы определить, действителен ли сеанс.
Когда пользователь входит в систему, используя свои учетные данные, сервер генерирует закодированный токен с сервера и возвращает его клиенту. После этого сервер ничего не знает о токене. Однако, когда сервер получает токен в запросе, он может его декодировать и проверить сеанс. Токен может храниться на клиенте в файле cookie, в котором мы можем использовать различные типы файлов cookie. Однако метод аутентификации по-прежнему основан на токенах.
Поскольку серверу не нужно хранить информацию о сеансе, нет необходимости выполнять поиск в постоянном хранилище для каждого запроса. Следовательно, это устраняет некоторые тяжелые накладные расходы. Токены также не привязаны к одному домену. Приложение может иметь несколько токенов для доступа к разным сервисам.
Однако у аутентификации на основе токенов все еще есть некоторые недостатки. Токены нужно где-то хранить на клиенте. У каждого местоположения, такого как локальное хранилище, файлы cookie, сессионное хранилище, есть свои плюсы и минусы. Так что разработчикам стоит выбирать с умом.
Токены также более восприимчивы к атакам с использованием межсайтовых сценариев (XSS) и подделки межсайтовых запросов (CSRF). XSS-атаки представляют собой атаки типа инъекции, когда злоумышленник внедряет вредоносные сценарии на доверенные веб-сайты. Поскольку токены хранятся на клиенте, вредоносный сценарий может легко украсть токены. CSRF-атаки позволяют злоумышленникам выполнять действия под видом жертвы. Злоумышленники могут выполнять HTTP-запросы к API, используя токен пользователя. Есть профилактические меры. Однако это все еще утомительный вопрос, который увеличивает время разработки.
Веб-токены JSON
Веб-токены JSON, также известные как JWT, являются открытым стандартом (RFC 7519) и представляют собой способ передачи данных с использованием JSON. Существуют различные типы токенов, некоторые из которых связаны с JWT, а некоторые - нет.
Токены доступа не являются эксклюзивными для JWT и используются для доступа к API. носителю токена доступа разрешено делать запросы к API в определенной области. Область действия - это типы действий или запросов, которые конечный пользователь может направить к API. Токены доступа не используются для аутентификации на стороне клиента; они в первую очередь защищают внутренние ресурсы.
Идентификационные токены, с другой стороны, являются JWT, но они предназначены для использования клиентом. Эти типы токенов предоставляют клиенту важные и основные данные о пользователе.
Важно отметить, что ни один из этих токенов не должен содержать конфиденциальную информацию о пользователе.
Последние мысли
Как аутентификация на основе токенов, так и на основе файлов cookie являются жизнеспособными вариантами для обработки аутентификации. Я бы не сказал, что одно значительно лучше другого. Можно также использовать сочетание разных типов аутентификации для разных целей. Например, для взаимодействия с API веб-приложений можно использовать файлы cookie. Однако для взаимодействия с внешними ресурсами можно использовать токены.
Надеюсь, это прояснило все сомнения.
Удачного кодирования! ❤
