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

Каков предпочтительный механизм и метод аутентификации для поддержания сеанса в приложении?

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

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

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

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

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

Аутентификация на основе файлов cookie работает следующим образом:

  1. Вход пользователя в систему путем ввода учетных данных
  2. Сервер проверяет правильность учетных данных пользователя и создает файл cookie с информацией о сеансе, который хранится в базе данных.
  3. Файл cookie с идентификатором сеанса и другой информацией также сохраняется в браузере.
  4. Когда пользователь перемещается по различным страницам в браузере, файл cookie сверяется с базой данных, чтобы проверить, действительны ли учетные данные пользователя.
  5. Когда пользователь выходит из системы, сеанс также удаляется из базы данных.

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

Когда мы говорим об аутентификации на основе токенов, мы часто ссылаемся на JWT (JSON Web Token), потому что он широко используется во всех отраслях и фактически стал стандартом аутентификации. JWT - это открытый стандарт, который определяет компактный, безопасный и автономный способ передачи данных между сторонами в JSON. JWT - это тип аутентификации без сохранения состояния. Это означает, что сервер не хранит информацию о сеансе в базе данных. Нет необходимости вести учет того, какой пользователь вошел в систему или какой токен выдан для какого пользователя. Вместо этого клиент будет отправлять последующие запросы на сервер с заголовком в формате bearer-{JWT-token}, или, чаще, клиент отправляет его в теле запроса POST или в качестве параметра URL.

Аутентификация на основе токенов работает следующим образом:

  1. Вход пользователей в систему с их учетными данными
  2. Сервер проверяет учетные данные пользователя, создает подписанный токен и отправляет токен обратно клиенту.
  3. Маркер хранится либо в локальном хранилище, либо в хранилище сеанса на стороне клиента.
  4. Последующие запросы к серверу будут включать этот токен, обычно встроенный в заголовок в формате bearer- {JWT-token}
  5. После выхода пользователя из системы токен уничтожается на стороне клиента; никакое взаимодействие с сервером не требуется, потому что сервер не имеет состояния.

Веб-токен JSON состоит из 3 частей:

  1. Заголовок
  2. Полезная нагрузка (содержит идентификатор пользователя) + срок действия
  3. Подпись

Аутентификация на основе токенов приобрела большую популярность благодаря широкому использованию в современных веб-приложениях, одностраничных приложениях (SPA), веб-API и IoT. Однако это может привести к появлению новых уязвимостей в приложении, если разработчики не реализовали аутентификацию должным образом.

Cookie против аутентификации на основе токенов

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

Преимущества использования аутентификации на основе файлов cookie

HttpOnly и безопасный флаг

Внедрение или хранение вашего токена в файлах cookie делает приложение отслеживающим состояние. Наличие флага HttpOnly защитит cookie от вредоносных атак JavaScript (например, XSS-атак). XSS-атака - это атака, при которой объект внедряет вредоносный скрипт на сайт жертвы. Фактическая атака происходит, когда жертва пытается посетить веб-страницы, на которых выполняется вредоносный код. Часто это скрыто в форме отправки или встроенного изображения iframe. Кроме того, файлы cookie сеанса могут быть созданы с помощью флажка безопасности, который предотвращает передачу токена по незашифрованным каналам. Поэтому всегда передавайте данные через HTTPS, чтобы злоумышленник не мог перехватить канал связи между браузером и сервером, а затем украсть файл cookie, чтобы выдать себя за пользователя.

Меньше работы для клиента, больше работы для сервера

Создавая файлы cookie на сервере и вставляя «set-cookie» в заголовок ответа, браузер автоматически отправляет аутентификационную информацию при каждом последующем запросе на сервер. Таким образом, клиенту не нужно вручную управлять состояниями файлов cookie между страницами.

Недостатки использования аутентификации на основе файлов cookie

CSRF или XSRF атака

Атака CSRF - это когда объект запускает вредоносный скрипт JavaScript, нацеливаясь на веб-сайт без ведома используемого браузера. Это больше ориентированная на цель атака, когда злоумышленник хочет знать, что пользователь хочет выполнить. Атаку CSRF нелегко понять, потому что вам нужно знать, откуда исходит злоумышленник. Для защиты от CSRF вы можете реализовать токен синхронизатора. Эта ссылка взята из StackOverflow, где более подробно объясняется, как и что это такое, если вы хотите узнать больше о токенах синхронизатора. С токенами синхронизатора вам потребуется реализовать другую логику JavaScript для синхронизированного токена в пользовательском интерфейсе. Следовательно, это может добавить еще один уровень сложности в вашу систему.

Производительность и масштабируемость

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

Более того, современные приложения не только создаются в Интернете, но и являются нативными. Внедрение файлов cookie для мобильных приложений намного сложнее и ненадежно, поскольку оно должно работать в различных нативных средах. Файлы cookie в Интернете были созданы на гипертекстовом языке, или Http, который создает единую среду для всех браузеров. Поскольку большинство пользователей будут многократно использовать один и тот же браузер и компьютер, сеансовые файлы cookie могут отслеживать активность пользователей. Кроме того, для мобильных устройств не только приложения будут работать в разных операционных системах, но и у каждого собственного приложения есть свое собственное правило. При использовании на одних и тех же устройствах браузеры играют в «песочнице», отличной от «песочниц», из-за чего очень сложно реализовать файлы cookie для собственных приложений.

Преимущества использования аутентификации на основе токенов

Без гражданства

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

Представление

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

CSRF безопасно

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

Недостатки использования аутентификации на основе токенов

XSS-атака

Приложения, реализующие аутентификацию на основе токенов, должны будут знать об атаках межсайтового скриптинга. Атаки межсайтового скриптинга происходят, когда злоумышленник может выполнить вредоносный JavaScript изнутри вашего приложения. Эта атака часто происходит, когда входные данные формы не очищены, а данные должным образом проверены перед отправкой формы. Следовательно, токен JWT уязвим. Однако современная веб-платформа имеет встроенные функции для очистки ввода, чтобы предотвратить произвольный код во время отправки формы. Например, ввод формы React автоматически дезинфицируется по умолчанию, если вы не измените параметр ввода на dangerouslySetInnerHTML. Другой способ предотвратить атаку XSS при использовании аутентификации на основе токена - установить ограничение срока действия токена на один час, чтобы даже в случае кражи токена он быстро стал непригодным для использования.

Соображения по поводу дизайна - где хранить токен?

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

Размер JWT

Размер JWT может быть относительно большим по сравнению с файлом cookie сеанса, поскольку большинство файлов cookie меньше среднего размера JWT. Размер токенов JWT не превышает 8 КБ, что намного больше, чем размер файлов cookie размером 4 КБ. В зависимости от способа передачи данных размер токена JWT может быть проблематичным, если вы добавите к нему много утверждений.

Какой мне использовать?

Пример использования файлов cookie

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

Пример использования токена

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

Пример использования гибридного

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

Заворачивать

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

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

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

Первоначально опубликовано на https://edward-huang.com.

Ссылка