Обзор аутентификации на основе токенов / Хабр

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

Аутентификация на основе токенов упрощает процесс аутентификации для уже известных пользователей. Для начала работы пользователь отправляет запрос к серверу, указав имя пользователя и пароль. Затем сервер подтверждает их на основании значений, зарегистрированных в его базе данных идентификационной информации. Если идентификационные данные подтверждены, сервер возвращает токен аутентификации (который тоже хранится в базе данных).

Когда тот же пользователь в дальнейшем шлёт запросы на доступ к защищённым ресурсам, эти запросы могут быть авторизованы при помощи токена аутентификации вместо имени пользователя и пароля. Сервер сверяет токен с зарегистрированным в базе данных токеном и предоставляет доступ. Аутентификацию можно реализовать на основе различных типов токенов, например, OAuth и JSON Web Tokens (JWT).

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

Безопасна ли аутентификация на основе токенов?

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

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

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

Похожее: uid.me – сервис личных страниц от uCoz

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

Как работает аутентификация на основе токенов?

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

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

Аутентификация на основе токенов обычно состоит из четырёх этапов:

Первоначальный запрос — пользователь запрашивает доступ к защищённому ресурсу. Изначально пользователь должен идентифицировать себя способом, не требующим токена, например, при помощи имени пользователя или пароля.
Верификация — аутентификация определяет, что идентификационные данные пользователя верны, и проверяет, какие полномочия он имеет в запрошенной системе.
Токены — система выпускает токен и передаёт его пользователю. В случае аппаратного токена это подразумевает физическую передачу токенов пользователю. В случае программных токенов это происходит в фоновом режиме, пока фоновые процессы пользователя обмениваются данными с сервером.
Сохранение — токен удерживается пользователем, или физически, или в браузере/мобильном телефоне. Это позволяет ему выполнять аутентификацию без указания идентификационных данных.

Основные типы токенов аутентификации

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

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

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

На стороне сервера можно
использовать библиотеку NPM (такую как jsonwebtoken) для
создания токенов:

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

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

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

Браузер может хранить
этот маркер в локальном хранилище, хранилище сеансов или в хранилище cookies.
Затем он будет добавлен в заголовок авторизации и отправлен на сторону сервера
для валидации запросов.

Добавление токена в заголовок должно быть реализовано с помощью JavaScript.

Authorization: Bearer <token>

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

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

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

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

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

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

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

Api-токены

Если вкратце, то API-токены используются как уникальные идентификаторы приложения, запрашивающего доступ к сервису. Сервис генерирует API-токен для приложения, чтобы оно использовало его при запросе сервиса. Для аутентификации и предоставления доступа API-токен можно сопоставить с сохранённым токеном. В некоторых случаях можно реализовать Session ID, но это бывает очень нечасто.

Cookie-based authentication

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

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

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

Json web tokens (jwt)

JSON Web Token (JWT) — это открытый стандарт (RFC 7519). Он определяет простой автономный способ защищённой передачи информации между сторонами. Стандарт JWT использует объекты JavaScript Object Notation (JSON) для передачи токенов между сторонами. Эти токены могут использоваться для аутентификации, а также для передачи дополнительной информации о пользователе или аккаунте.

Payload или полезные данные

Вторым блоком идет eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9

Это есть полезные данные, так же закодированные в Base64. После раскодирования получим:

Refresh token

Основной токен, про который шла речь выше, обычно имеет короткий срок жизни – 15-30 минут. Больше давать не стоит.

Как только время выйдет, пользователю снова придется проходить авторизацию. Так вот чтобы этого избежать, существует Refresh токен. С помощью него можно продлить Access токен.

В действительности, Refresh токен обязательно должен быть одноразовым. Его задача – получить новую пару токенов. Как только это было сделано, предыдущий токен будет считаться недействительным. Срок жизни Refresh токена уже может быть большим – до года, а может даже и больше.

У него, обычно, нет какой-то структуры и это может быть некая случайная строка.

Аппаратные токены (usb)

Аппаратные токены — это физические устройства, обеспечивающие авторизацию пользователей для доступа к защищённым сетям. Также иногда их называют токенами аутентификации или безопасности. Задача аппаратного токена — обеспечение дополнительного слоя защиты благодаря двухфакторной или многофакторной аутентификации (2FA или MFA). Владелец токена привязывает токен к системе или сервису, доступ к которому ему необходим.

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

Безопасность

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

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

Заголовок

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 – это первая часть токена – есть заголовок. Она закодирована в Base64 и если её раскодировать, получим строку:

Зачем 2 токена?

Представим ситуацию, когда у нас каким-то образом украли Access токен. Да, это уже плохо и где-то у нас брешь в безопасности. Злоумышленник в этом случае сможет им воспользоваться не более чем на 15-30 минут. После чего токен “протухнет” и перестанет быть актуальным. Ведь нужен второй токен для продления.

Если украли Refresh токен, то без Access токена (который недоступен в JS) продлить ничего нельзя и он оказывается просто бесполезным.

Как работает jwt?

Если есть данные, достоверность которых следует подтвердить, нам надо подписать их секретным ключом, используя HMAC. Для этого применяется такой же способ хеширования, что и для одноразовых паролей, только вместо шести цифр берется весь хеш целиком. Единственная разница — это сам алгоритм хеширования: в таких токенах SHA-1 считают слишком коротким и небезопасным, поэтому обычно используют SHA-256.

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

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

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

Не подходит для api

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

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

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

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

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

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

Одноразовые токены one-time password (otp)

Токены One-time password (OTP) — это защищённые аппаратные устройства или программы, способные генерировать одноразовые пароли. Чаще всего это personal identification numbers (PIN) — числовые коды длиной 4-12 цифр.

Для генерации или получения одноразовых паролей часто применяются смартфоны. После того, как пользователь доказал, что владеет конкретным телефоном, он может использовать приложение аутентификатора, генерирующее пароли OTP — в этом случае телефон служит генератором кодов. Или же OTP могут отправляться в устройство через SMS.

Одноразовые пароли усиливают существующие системы идентификации и паролей, добавляя в них динамически генерируемые идентификационные данные. Токены OTP генерируют PIN синхронно или асинхронно, это зависит от их поставщика:

Плюсы и минусы программных токенов

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

Подписываемся под данными

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

Схема генерации HMAC (hash-based message authentication code), кода аутентификации сообщений с использованием хеш-функции

Алгоритм хеширования может меняться, но суть этого подхода проста и неизменна: для подтверждения целостности сообщения необходимо снова найти подпись защищаемых данных и сравнить ее с имеющейся подписью.

Подходит для хранения дополнительных данных

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

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

Все эти манипуляции можно провести и с помощью токенов. Например, токены JWT позволяют хранить Claim-объекты. Поскольку это увеличит размер токена, сохранение большего их количества повлияет на нагрузку сети.

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

Постскриптум

В своей реализации Refresh токена использовал общую длину 24 знака. Первые 6 знаков – это дата его “протухания”, следующие 12 знаков – случайно сгенерированные данные. И в конце 6 знаков – это часть Access токена последней части сигнатуры.

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

Дата содержит год, месяц, день, час и минуты. Хранится в ASCII

Кодирование даты на Golang:

// приводим к целочисленному числу uint32. Итого 32 бита.
// расчет простой: год 12 бит, месяц 4 бита, день 5 бит и т.д. Таким образом в аккурат умещаемся в 32 бита или 4 байта.
date := uint32(year<<20) | uint32(month<<16) | uint32(day<<11) | uint32(hour<<6) | uint32(minute)

// в цикле кодируем байты в ASCII. 1 знак это шесть бит. Итого и получаем шесть знаков даты по таблице ASCII – печатные знаки.
for n := 0; n < 6; n {
b6Bit = byte(date>>i) & 0x3F
sBuilder.WriteByte(byte8bitToASCII(b6Bit))
…
}

Всю реализацию на Go можно изучить на Github-е

Придумываем коды доступа

Люди, которые придумали двухфакторную аутентификацию, по всей видимости, руководствовались принципом «одна голова хорошо, а две — лучше». И действительно — два пароля точно безопаснее одного. Но пароли, которые отправляет сайт в SMS, нельзя назвать абсолютно защищенными: сообщение чаще всего можно перехватить.

Создание безопасных одноразовых паролей состоит из двух этапов:

Первичная настройка — включение двухфакторной аутентификации.
Использование пароля — непосредственный ввод кода и отправка для проверки.

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

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

На самом деле весь секрет — последовательность из случайных символов, которые закодированы в формате Base32. Суммарно они занимают не меньше 128 бит, а чаще и все 190 бит. Эту последовательность и видит пользователь как текст или QR-код.

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

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

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

Возьмем время празднования Нового года в формате UNIX (1577811600000) и посчитаем порядковый номер нашего пароля: поделим на 30 секунд — 52593720. Воспользуемся нашим секретом и вычислим хеш — по стандарту RFC 6238 это функция SHA-1:

Проблемы безопасности

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

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

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

Проверка токена

Для проверка токена необходимо проделать ту же операцию.

Берем склейку заголовок данные, кодируем с помощью алгоритма HMAC-SHA256 и нашего приватного ключа. А далее берем сигнатуру с токена и сверяем с результатом кодирования. Если результаты совпадают – значит данные подтверждены и можно быть уверенным, что они не были подменены.

Сигнатура

Последняя часть токена – наиболее важная. У нас это E4FNMef6tkjIsf7paNrWZnB88c3WyIfjONzAeEd4wF0

Как вы уже могли заметить – первые данные передаются практически в открытом виде и раскодировать их может любой. Но шифровать их нет необходимости. Цель токена – подтвердить, что эти данные не были изменены. Вот для этих целей и выступает сигнатура. И чтобы её сгенерировать нужен приватный ключ.

Она получается примерно следующим образом:

Это stateless-механизм

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

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

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

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

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

Заключение

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

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

Спасибо за внимание!

***

Дополнительные материалы: