Веб-аутентификация: файлы cookie или токены

Как выбрать между файлами cookie и токенами при веб-аутентификации.

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

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

Аутентификация на основе файлов cookie

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

При аутентификации на основе файлов cookie этот уникальный идентификатор (файл cookie) создается на стороне сервера и отправляется в браузер.

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

Чтобы лучше понять, как работают файлы cookie, давайте разделим этот процесс на 5 частей.

1. Пользователь входит в приложение, используя учетные данные.

2. Сервер проверяет учетные данные и создает сеанс в базе данных.

Примечание. Хотя сеанс можно создать в памяти, его нельзя масштабировать.

3. Сервер отправляет файл cookie браузеру, включая его в заголовок Set-Cookie.

Этот файл cookie отправляется в виде пары имя-значение и содержит уникальный идентификатор для идентификации пользователя.

В дополнение к этому файл cookie может содержать такие данные, как срок действия, домен и возраст. Пример ответа с несколькими заголовками Set-Cookie будет выглядеть так:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain>
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path>
Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

[page content]

Примечание. Вы также можете использовать один заголовок Set-Cookie для установки нескольких атрибутов (Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain>; Secure; HttpOnly).

4. Браузер сохраняет Cookie в хранилище и отправляет его с последующими запросами.

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

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

5. Когда пользователь выйдет из системы, сервер удалит сеанс из базы данных.

Как только пользователь выйдет из системы, сервер истечет срок действия Cookie, очистив сеанс базы данных. Браузер делает то же самое, удаляя его из хранилища файлов cookie.

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

Это полностью автоматизированный процесс.

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

Браузер позаботится об обработке файлов cookie и автоматически добавит файлы cookie для всех запросов.

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

Кроме того, злоумышленники CSRF могут воспользоваться этим механизмом, чтобы обманом заставить браузер отправлять запросы с cookie на ложные веб-сайты.

Измерения безопасности.

По умолчанию аутентификация на основе файлов cookie не имеет надежной защиты от атак, и они в основном уязвимы для атак с использованием межсайтовых сценариев (XSS) и подделки межсайтовых запросов (CSRF).

Но мы можем явно изменить заголовки файлов cookie, чтобы защитить их от таких атак.

Например, файлы cookie можно легко защитить от XSS-атак с помощью атрибута HttpOnly при настройке заголовков файлов cookie.

Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

Кроме того, мы можем использовать атрибут SameSite в заголовке cookie для эффективного предотвращения атак CSRF.

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax

Есть 3 значения, которые можно использовать для атрибута SameSite.

• SameSite=Lex, будет следить за тем, чтобы браузер не отправлял файлы cookie при межсайтовых запросах (это поведение файлов cookie по умолчанию, если вы не определяете атрибут SameSite).
• SameSite=Strict будет следить за тем, чтобы браузер отправлял cookie только для запросов к тому же сайту.
• SameSite=None позволит вам отправлять файлы cookie как с межсайтовыми, так и с межсайтовыми запросами.

Обычно работает в одном домене.

Файлы cookie работают только в одном домене, если вы специально не настроили его.

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

Однако, если ваш интерфейс и серверная часть (API) находятся в разных доменах или субдоменах, вам необходимо явно занести их в белый список в Cookie. В противном случае браузер не отправит файл cookie вместе с запросом.

Не подходит для API.

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

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

Могут возникнуть проблемы с масштабируемостью.

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

Хотя есть хорошо зарекомендовавшие себя способы обеспечения масштабируемости (например, использование баз данных в памяти, таких как Redis, в качестве хранилища сеансов), это все же добавляет сложности.

Но по мере роста числа пользователей могут возникнуть проблемы с масштабированием и управлением этими сеансами.

Наиболее подходит для хранения дополнительных данных.

Поскольку этот подход поддерживает отдельные сеансы для каждого пользователя, мы можем хранить данные, прикрепленные к сеансу.

С помощью файлов cookie и сеансов мы можем хранить определенные данные, такие как персонализация пользователя, контроль доступа и сеанс. Затем это позволяет нам использовать его для последующих запросов.

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

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

Может ограничивать доступ к cookie в браузере.

Поскольку Cookie предоставляет возможность HTTP-Only, мы можем ограничить доступ JavaScript к нему. Кроме того, это предотвратит любой доступ к файлам cookie с помощью межсайтовых сценариев атак.

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

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

В отличие от файлов cookie, подход на основе токенов требует ручной реализации, а токены сохраняются на стороне клиента.

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

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

Чтобы лучше понять, как работают токены, давайте разделим этот процесс на 4 части и в качестве примера возьмем JWT, наиболее широко используемый стандарт токенов.

JSON Web Token (JWT) — наиболее часто используемый открытый стандарт аутентификации на основе токенов.

1. Пользователь входит в приложение, используя учетные данные.

2. Сервер проверяет учетные данные, генерирует токен, подписывает его секретным ключом и отправляет обратно в браузер.

Обычно вам необходимо использовать шифрование при передаче, например SSL, для защиты канала.

На стороне сервера вы можете использовать библиотеку NPM, например jsonwebtoken, для генерации этих токенов.

// Install
npm install jsonwebtoken
// Usage
var jwt = require('jsonwebtoken');
var token = jwt.sign(
              { data: user}, 
              privateKey, 
              { algorithm: 'RS256'},
              exp: Math.floor(Date.now() / 1000) + (60 * 60),            );

Токен, созданный из библиотеки jsonwebtoken, будет выглядеть следующим образом:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Этот токен состоит из 3 частей: заголовка, полезной нагрузки и подписи (header.payload.signature). Они разделены ., и вы можете использовать веб-сайт jwt.io для анализа информации токена.

3. Сохраните токен в хранилище браузера и добавьте его в последующие запросы с помощью JavaScript.

Браузер может хранить этот токен в локальном хранилище, хранилище сеансов или хранилище файлов cookie. Затем этот токен будет добавлен в заголовок авторизации необходимых запросов и отправлен на сервер для проверки запросов. Следовательно, добавление токена в заголовок необходимо реализовать с помощью JavaScript.

Authorization: Bearer <token>

Кроме того, вы можете использовать функцию jwt.decode() в библиотеке jsonwebtoken для декодирования этого токена и использования данных полезной нагрузки в приложении.

5. При выходе пользователя из системы необходимо вручную удалить токен из его хранилища.

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

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

Это механизм без гражданства.

В отличие от файлов cookie, подход на основе токенов не имеет состояния. Это означает, что он не сохраняет никакой информации о пользователях в базе данных или на сервере.

Сервер отвечает только за создание и проверку токенов, что позволяет создавать более масштабируемые решения, чем подход на основе файлов cookie.

Проблемы с безопасностью.

Хотя токены пытаются решить проблемы безопасности в файлах cookie, они не являются полностью надежными.

Токены, сохраненные в браузере, могут быть уязвимы для XSS-атак, если ваше приложение позволяет встраивать внешние скрипты JavaScripts в ваше приложение.

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

Заключение

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

Как видим, ни один из этих методов не идеален на 100%, и у них есть несколько недостатков.

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

Спасибо за чтение !!!

Создавайте из независимых компонентов, для скорости и масштабирования

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

Инструменты OSS, такие как Bit, предлагают отличные возможности разработчика для создания независимых компонентов и составления приложений. Многие команды начинают с создания своих дизайн-систем или микро-интерфейсов с помощью независимых компонентов.
Попробуйте →

Учить больше

Заменит ли Bit npm?
Какую роль Bit и Bit.dev играют в веб-разработке? blog.bitsrc.io

Важность проверок целостности в JavaScript
Как защитить свои веб-приложения с помощью целостности субресурсов (SRI) blog.bitsrc.io

5 лучших решений аутентификации для React Native
Познакомьтесь с 5 поставщиками аутентификации для React Native, чтобы начать процесс аутентификации blog.bitsrc.io