Jwt token что это

JWT — как безопасный способ аутентификации и передачи данных

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

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

В этой статье разберу, что такое Access токен, Refresh токен и как с ними работать.

Для дальнейших разборов будет использован токен:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9.E4FNMef6tkjIsf7paNrWZnB88c3WyIfjONzAeEd4wF0

После того, как посетитель прошел авторизацию в нашей системе, указав свой логин и пароль, система выдает ему 2 токена: access token и refresh токен.

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

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

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

Это можно проверить прям в браузере, выполнив в консоле или js коде:

const header = atob(‘eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9’); console.log(header);

typ — это наш тип токена JWT. Alg — алгоритм шифрования HMAC-SHA256. Их может быть несколько, но здесь буду говорить именно об этом алгоритме.

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

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

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

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

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

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

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

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

Берем заголовок, например и кодируем его в base64, получаем ту самую часть eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Тоже самое проделываем с данными eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9

После этого склеиваем их и получаем eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9

Далее эти данные шифруем с помощью нашего алгоритма HMAC-SHA256 и ключа.

const header = ‘<"alg":"HS256","typ":"JWT">‘ // строка const payload = » // строка // кодируем заголовок и данные в base64 const headerBase64 = base64urlEncode(header) const payloadBase64 = base64urlEncode(payload) // склеиваем точкой полученные строки const data = headerBase64 + ‘.’ + payloadBase64 // кодируем алгоритмом шифрования нашим ключем шифрования const secret = ‘123456’ const sig = HMAC-SHA256(data, secret) // и, наконец, получаем окончательный токен const jwt = data + ‘.’ + sig

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

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

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

Refresh token

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

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

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

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

Для проекта odo24.ru я использовал следующий подход.

Генерируется Access токен и после случайная строка, например T6cjEbghMZmybUd_fhE

С нашего нового Access токена eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9.E4FNMef6tkjIsf7paNrWZnB88c3WyIfjONzAeEd4wF0 беру последние шесть знаков, получаю Ed4wF0

Склеиваю и получаю рефреш токен T6cjEbghMZmybUd_fhEEd4wF0

Это сделано для привязки Access токена к Refresh. Для получения новых токенов необходимо передать эти два токена. Делается проверка на их связку и только после валидируется Access токен. Если и второй этап прошел успешно, тогда получаем с базы данных по текущему user_id рефреш токен и сверяем с тем, что к нам пришел. Если они совпадают, тогда генерируются новые токены и в базе данных обновляется Refresh токен на новый.

Где хранить токены?

В моем случае я разделил оба токена и храню в разных местах. Access токен нужен только для идентификации пользователя и на клиенте (JS) он не нужен, поэтому он передается в Cookie (http only).

Refresh токен хранится в LocalStorage и используется только когда Access токен перестал быть актуальным.

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

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

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

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

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

В своей реализации 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-е

Заключение

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

Единый вход с использованием JWT

iSpring Learn позволяет использовать JWT (JSON Web Token) для реализации единого входа. JWT – это открытый стандарт для передачи пакетов между сторонами в веб-среде. Он используется для шифрования и передачи данных авторизованных пользователей между поставщиком идентификации (ваш корпоративный веб-сайт) и поставщиком услуг (iSpring Learn).

Для настройки нужно

• Навыки веб-разработки (PHP, JavaScript, JSON, JWT).
• Доступ к вашему хостингу с правами администратора.
• Аккаунт iSpring Learn с доступом администратора.

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

JSON Web Token передается в iSpring Learn как GET-параметр.

Составляющие части JWT

JWT Токен передается в зашифрованном виде и состоит из трёх частей, разделенных точками:

1. XXXXXX закодированный заголовок

Заголовок представляет собой base64-код, который содержит информацию о типе стандарта («JWT») и об алгоритме шифрования («HS256»).

1. YYYYYY тело токена

Тело токена, также называемое “полезный груз” или payload содержит идентификатор пользователя (электронная почта). Он также представлен в формате base64-кода.

«IAT»: 123456789,
«JTI»: f4as6d5f4as6d54fasd6df4,
«ехр»: 123456849,
«электронная почта»:
«username@yourcompany.com»>

IAT (Issued At) — содержит время создания токена;
JTI (JWT ID) — идентификатор маркера, выдается автоматически, закодирован;
ехр — время истечения этого токена;
email — адрес электронной почты пользователя (или идентификатор пользователя)который требуется для проверки подлинности.

1. ZZZ цифровая подпись

Эта часть содержит ключ для шифрования всего токена (все 3 части) и выглядит следующим образом:

HMACSHA256(base64UrlEncode(XXXXXX) + «.» + base64UrlEncode(YYYYYY), secret)

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

Настройка параметров JWT для единого входа в СДО

Настройка JWT в аккаунте iSpring Learn достаточно проста.

1. Войдите в свой аккаунт iSpring Learn под учётной записью администратора и введите путь к настройкам в строке браузера: https://yourcompany.ispringlearn.ru/settings/sso/jwt
2. Поставьте галочку в поле Enable JWT login for this account.
3. Укажите Security key. Это значение также является криптографическим ключом и секретной частью частью JWT токена.
4. Identity provider URL содержит адрес страницы вашего сайта, на котором располагается скрипт для генерации JWT токенов для входа пользователя.
5. Logout URL содержит адрес страницы вашего сайта, на котором располагается скрипт для генерации JWT токенов для выхода пользователя.

Мы рекомендуем использовать протокол HTTPS вместо HTTP для повышения безопасности.

Примечание: при необходимости можно использовать GET параметр no_jwt=1 для доступа к форме логинации в СДО в обход SSO: https://yourcompany.ispringlearn.ru/login?no_jwt=1 Например, если ввести этот параметр, то пользователь сможет войти, даже если единый вход по какой-то причине не работает.

Логика единого входа JWT

Весь процесс показан на временной UML-диаграме ниже:

На этапе проверки пользователя, если его нет в базе iSpring Learn, он будет автоматически добавлен и залогинен.

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

Другим пример автоматической авторизации может быть тот случай, если пользователь сразу зашел на сайт iSpring Learn, без предварительной авторизации на вашем сайте. Если в аккаунте Learn включена опция JWT, то пользователь будет автоматически перенаправлен на соответствующую страницу вашего сайта (поставщика идентификации) https://www.yourwebsite.com/login-token/. После ввода логина и пароля на стороне вашего сайта, пользователь сможет беспрепятственно войти на портал Learn.

Примеры реализации на PHP

Аутентификация (вход)

Данный cерверный скрипт должен быть размещён на вашем сайте. Возможные случаи и результаты:

1. Если пользователь авторизован на вашем сайте, система перенаправляет этого пользователя в СДО iSpring Learn.
2. Если не авторизован, то пользователю предлагается ввести логин и пароль к вашему сайту. В случае успеха пользователь будет залогинен в СДО iSpring Learn.

Запрос на выход

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

Ссылки на англоязычные ресурсы по JWT:

1. Introduction to JSON Web Tokens
2. Anatomy of a JWT request
3. JWT Debugger
4. Libraries for Token Signing/Verification
5. http://www.base64decode.org/

• Как создать портфолио курсов с iSpring Page
• Мобильное приложение iSpring Play
• Системные требования при конвертации в видео

JWT для начинающих: что такое JSON Web Tokens и зачем они нужны

JWT — это JSON Web Tokens, простой и безопасный способ передачи информации между клиентом и сервером с помощью шифрования.

JWT — это JSON Web Tokens, простой и безопасный способ передачи информации между клиентом и сервером.

JWT — это что-то вроде секретного зашифрованного сообщения, расшифровать которое может только его получатель.

Структура JWT

JWT состоит из трех отдельных частей, разделенных точкой (.):

1. Заголовок: содержит метаданные о токене и используемом криптографическом алгоритме, обычно это HMAC SHA256 или RSA.
2. Полезная нагрузка: фактические данные, которые содержит токен, хранятся здесь. Полезная нагрузка также известна как “утверждения” и может включать данные вроде информации о пользователе и дополнительных метаданных.
3. Подпись: криптографически защищенное доказательство (proof), которое подтверждает отправителя и гарантирует, что сообщение не было изменено во время передачи.

Как работает JWT

Вот пошаговый алгоритм работы JWT:

1. Клиент выполняет вход, используя учетные данные, отправляя запрос на сервер.
2. Сервер проверяет эти учетные данные. Если они действительны, сервер генерирует JWT и отправляет его обратно клиенту.
3. Клиент сохраняет JWT, обычно в локальном хранилище, и включает его в заголовок каждого последующего HTTP-запроса.
4. Сервер, получая эти запросы, проверяет JWT. Если он действителен, клиент аутентифицирован и авторизован.

Зачем использовать JWT

JWT универсальны – любой язык программирования может генерировать JWT, поскольку они по своей сути являются JSON.

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

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

Несмотря на удобство использования JWT, у них есть уязвимости:

1. Кража токена: JWT хранятся на стороне клиента и могут быть украдены. Убедитесь, что передача данных защищена, предпочтительно с использованием протокола HTTPS.
2. Нет встроенного механизма недействительности: JWT не могут быть недействительными индивидуально или группой у пользователя из-за их бессостоятельной природы.
3. Размер токена: хранение слишком большого количества данных в JWT может сделать его тяжелым, что повлияет на производительность сети.
4. Уязвимости алгоритмов: некоторые алгоритмы в заголовках JWT уязвимы к атакам. Всегда используйте безопасные и обновленные алгоритмы и обращайтесь с ключами подписи как с секретной информацией.

Заключение

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

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

Что такое JWT токен?

Эта статья посвящена детальному разбору JWT и его возможностей. Мы изучим структуру токена и построим его с нуля. Затем рассмотрим наиболее распространенные способы использования.

7 авг. 2021 · 10 минуты на чтение

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

Когда у вас один сервис, все довольно просто:

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

Эта строка обычно хранится в куках браузера, а потому называется авторизационной кукой.

Все было отлично, пока не пришли микросервисы. Допустим у нас есть сервер авторизации, который находится на домене auth.foo.com, и парочка других сервисов. Один из ваших сервисов находится на домене blog.foo.com.

Когда пользователь авторизуется на сервере авторизации, то кука будет записана для домена auth.foo.com. Сервис blog.foo.com уже не будет иметь доступ к этой куке.

Это можно исправить, если хранить куку в LocalStorage браузера. Тогда возникает другая проблема. У сервиса blog.foo.com нет возможности проверить куку, так как он ее не выдавал. Сервису необходимо сделать запрос на сервер авторизации, чтобы проверить существование куки и кому она принадлежит. Это создает нагрузку на сервер авторизации.

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

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

Спонсор поста

Формат JWT

JWT состоит из трех основных частей: заголовка (header), нагрузки (payload) и подписи (signature). Заголовок и нагрузка формируются отдельно в формате JSON, кодируются в base64, а затем на их основе вычисляется подпись. Закодированные части соединяются друг с другом, и на их основе вычисляется подпись, которая также становится частью токена.

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

Header

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

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

Поле alg обязательно для заполнения. В приведенном случае был применен алгоритм HS256 (HMAC-SHA256), в котором для генерации и проверки подписи используется единый секретный ключ.

Для подписи JWT могут применяться и алгоритмы асимметричного шифрования, например RS256 (RSA-SHA256). Стандарт допускает использование и других алгоритмов, включая HS512, RS512, ES256, ES512, none и др.

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

Закодируем этот JSON в base64 и получим: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload

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

• iss — (issuer) издатель токена
• sub — (subject) “тема”, назначение токена
• aud — (audience) аудитория, получатели токена
• exp — (expire time) срок действия токена
• nbf — (not before) срок, до которого токен не действителен
• iat — (issued at) время создания токена
• jti — (JWT id) идентификатор токена

Все эти claims не являются обязательными, но их использование не по назначению может привести к коллизиям.

Любые другие данные можно передавать по договоренности между сторонами, использующими токен. Например, payload может выглядеть так:

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

Payload не шифруется при использовании токена, поэтому не стоит передавать в нем чувствительные данные. Например, паспортные данные.

Размер payload не ограничен, но не стоит передавать в нем много данных. Из-за размера токена могут начаться проблемы с производительностью.

Закодируем наш payload в base64 и получим вторую часть токена: eyJpc3MiOiJBdXRoIFNlcnZlciIsInN1YiI6ImF1dGgiLCJleHAiOjE1MDU0Njc3NTY4NjksImlhdCI6MTUwNTQ2NzE1MjA2OSwidXNlciI6MX0 .

У нас уже есть 2/3 токена, осталось сгенерировать подпись.

Signature

Подпись генерируется следующим образом: Закодированные заголовок и полезная нагрузка объединяются с точкой («.») в качестве разделителя. Затем эта строка хешируется указанным в header алгоритмом. Результат работы алгоритма хеширования и есть подпись.

В нашем примере токен будет выглядеть так: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJBdXRoIFNlcnZlciIsInN1YiI6ImF1dGgiLCJleHAiOjE1MDU0Njc3NTY4NjksImlhdCI6MTUwNTQ2NzE1MjA2OSwidXNlciI6MX0.9VPGwNXYfXnNFWH3VsKwhFJ0MazwmNvjSSRZ1vf3ZUU

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

Официальный сайт jwt.io предлагает два алгоритма хэширования: HS256 и RS256. Но можно использовать любой алгоритм с приватным ключом.

Аутентификация

Схема аутентификации с использованием JWT предельно проста.

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

При последующих обращениях токен передается приложению в запросах от пользователя: в cookie, заголовках запроса, POST или GET параметрах и т. д.

Получив токен, приложение сперва проверяет его подпись. Убедившись, что подпись действительна, приложение извлекает из части полезной нагрузки сведения о пользователе и на их основе авторизует его.

Можно реализовать всю эту схему вручную, а можно использовать одну из библиотек указанных на jwt.io.

Преимущества JWT

Перечислим преимущества использования JWT в сравнении с классической схемой аутентификации, использующей сессии.

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

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

В-третьих, при использовании отдельного сервиса аутентификации становится возможным организовать единую точку входа в различные сервисы с одними и теми же учетными данными (SSO). Единожды пройдя процедуру аутентификации, пользователь сможет получить доступ со своим токеном к тем ресурсам, которые доверяют этому сервису аутентификации.

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

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

Уязвимости JWT

В этом разделе будут рассмотрены основные атаки на JWT и даны рекомендации по их предотвращению.

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

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

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

В соответствии с лучшими практиками для предотвращения подобной угрозы рекомендуется:

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

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

Здесь рекомендации будут следующие:

• как и в первом случае, использовать защищенное соединение при передаче токенов;
• ограничить время жизни JWT и использовать механизм refresh tokens.

Refresh tokens

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

• access token — JWT, на основе которого приложение идентифицирует и авторизует пользователя;
• refresh token — токен произвольного формата, служащий для обновления access token.

Access token при таком подходе имеет сильно ограниченное время жизни (например, одну минуту). Refresh token же имеет длительное время жизни (день, неделя, месяц), но он одноразовый и служит исключительно для обновления access token пользователя.

Схема аутентификации в таком случае выглядит следующим образом:

• пользователь проходит процедуру аутентификации и получает от сервера access token и refresh token;
• при обращении к ресурсу пользователь передает в запросе свой access token, на основе которого сервер идентифицирует и авторизует клиента;
• при истечении access token клиент передает в запросе свой refresh token и получает от сервера новые access token и refresh token;
• при истечении refresh token пользователь заново проходит процедуру аутентификации.

Подбор ключа симметричного алгоритма подписи

При использовании симметричных алгоритмов для подписи JWT (HS256, HS512 и др.) злоумышленник может попытаться подобрать ключевую фразу.

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

В нашем примере из первой части статьи для подписи JWT в качестве ключевой фразы была использована строка password. Она простая, короткая и содержится во всех основных словарях для перебора паролей. Злоумышленнику не составит труда подобрать эту ключевую фразу с использованием программ John the Ripper или hashcat.

Рекомендации для защиты от атаки в этом случае такие:

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

Использование алгоритма none

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

Рассмотрим подобную атаку на нашем примере. Наш токен в незакодированном виде выглядит следующим образом

header: < "typ": "JWT", "alg": "HS256" >payload: < "id": "1337", "username": "bizone", "iat": 1594209600, "role": "user" >signature: ZvkYYnyM929FM4NW9_hSis7_x3_9rymsDAx9yuOcc1I

Предположим, мы хотим, чтобы приложение считало нас администратором. Для этого необходимо установить значение admin в поле role полезной нагрузки. Но при внесении в токен этого изменения подпись токена станет невалидной, и приложение не примет такой JWT.

Для обхода защитного механизма мы можем попытаться изменить значение поля alg в заголовке токена на none. Наш токен примет следующий вид:

header: < "typ": "JWT", "alg": "none" > payload: < "id": "1337", "username": "bizone", "iat": 1594209600, "role": "admin" >

Поскольку мы используем алгоритм none, подпись отсутствует. В закодированном виде наш JWT будет выглядеть так: eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJpZCI6IjEzMzciLCJ1c2VybmFtZSI6ImJpem9uZSIsImlhdCI6MTU5NDIwOTYwMCwicm9sZSI6ImFkbWluIn0

Этот токен мы и передадим на сервер. Уязвимое приложение, проверив заголовок JWT и обнаружив в нем alg: none, примет этот токен без всяких проверок, как если бы он был легитимным, в результате чего мы получим привилегии администратора.

Чтобы защититься от такой атаки:

• необходимо вести на стороне приложения белый список разрешенных алгоритмов подписи и отбрасывать все токены с алгоритмом подписи, отличным от разрешенного на сервере;
• желательно работать строго с одним алгоритмом, например HS256 или RS256.

Изменение алгоритма подписи

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

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

Для рассмотрения примера этого варианта атаки нам понадобится новый JWT:

header: < "alg": "RS256", "typ": "JWT" >payload: < "id": "1337", "username": "bizone", "iat": 1594209600, "role": "user" >signature: YLOVSKef-paSnnM8P2JLaU2FiS8TbhYqjewLmgRJfCj1Q6rVehAHQ-lABnKoRjlEmHZX-rufHEocDxGUYiGMjMexUQ3zt-WqZITvozJ4pkvbV-mJ1nKj64NmqaR9ZkBWtmF-PHJX50eYjgo9rzLKbVOKYOUa5rDkJPHP3U0aaBXFP39zsGdOTuELv436WXypIZBeRq2yA_mDH13TvzegWCK5sjD4Gh177bCq57tBYjhGIQrDypVe4cWBPlvwFlmG8tdpWGu0uFp0GcbTAfLUlbTSuGROj88BY0XeUs0iqmGlEICES3uqNx7vEmdT5k_AmL436SLedE0VHcyxve5ypQ

В кодированном виде он будет выглядеть следующим образом: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjEzMzciLCJ1c2VybmFtZSI6ImJpem9uZSIsImlhdCI6MTU5NDIwOTYwMCwicm9sZSI6InVzZXIifQ.YLOVSKef-paSnnM8P2JLaU2FiS8TbhYqjewLmgRJfCj1Q6rVehAHQ-lABnKoRjlEmHZX-rufHEocDxGUYiGMjMexUQ3zt-WqZITvozJ4pkvbV-mJ1nKj64NmqaR9ZkBWtmF-PHJX50eYjgo9rzLKbVOKYOUa5rDkJPHP3U0aaBXFP39zsGdOTuELv436WXypIZBeRq2yA_mDH13TvzegWCK5sjD4Gh177bCq57tBYjhGIQrDypVe4cWBPlvwFlmG8tdpWGu0uFp0GcbTAfLUlbTSuGROj88BY0XeUs0iqmGlEICES3uqNx7vEmdT5k_AmL436SLedE0VHcyxve5ypQ

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

Как и в предыдущем примере, модифицируем токен:

header: < "typ": "JWT", "alg": "HS256" >payload:

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

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6IjEzMzciLCJ1c2VybmFtZSI6ImJpem9uZSIsImlhdCI6MTU5NDIwOTYwMCwicm9sZSI6ImFkbWluIn0

Остается только подсчитать подпись с использованием публичного ключа сервиса.

Для начала переводим ключ в hex-представление:

Затем генерируем подпись с использованием openSSL:

Полученное значение E1R1nWNsO-H7h5WoYCBnm6c1zZy-0hu2VwpWGMVPK2g добавляем к уже имеющейся строке, и наш токен принимает следующий вид: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6IjEzMzciLCJ1c2VybmFtZSI6ImJpem9uZSIsImlhdCI6MTU5NDIwOTYwMCwicm9sZSI6ImFkbWluIn0.E1R1nWNsO-H7h5WoYCBnm6c1zZy-0hu2VwpWGMVPK2g

Подставляем в поле secret на jwt.io наш публичный ключ, и JWT успешно проходит проверку. Не забудьте поставить галочку secret base64 encoded.

Для предотвращения такой атаки рекомендуется:

• работать только с одним алгоритмом, например HS256 или RS256;
• выбирать хорошо известные и проверенные библиотеки для работы с JWT, которые с меньшей вероятностью содержат логические ошибки в процедурах проверки токенов.

Заключение

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

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

Итак, для безопасного использования JWT следует:

• использовать защищенное соединение при передаче токенов;
• не передавать в токенах чувствительные пользовательские данные;
• ограничить время жизни JWT и использовать механизм refresh tokens;
• использовать ключевые фразы большой длины;
• обеспечить периодическую смену ключевой фразы;
• вести на стороне приложения белый список разрешенных алгоритмов подписи;
• в идеальном случае работать строго с одним алгоритмом подписи;
• выбирать хорошо известные и проверенные библиотеки для работы с JWT;
• всегда валидировать и санитизировать полученные от пользователя данные.

После беглого знакомства с JSON web tokens может сложиться впечатление, что они встроены в современные механизмы авторизации и аутентификации, такие как OAuth или OpenID. Однако это не совсем так. JSON токены действительно используются в этих системах, но не являются их частью. Более того, сфера их использование гораздо шире авторизации.

В отдельной статье вы можете посмотреть на реализацию JWT аунтентификации ��