Что такое JSON Web Tokens или его еще называют сокращенно JWT. JWT (JSON Web Tokens) — это простой и безопасный способ передачи информации между клиентом и сервером с помощью шифрования. Это своего рода секретное зашифрованное сообщение, расшифровать которое может только его получатель.
Это современный стандарт для организации безопасной передачи информации между клиентом и сервером. JSON Web Tokens облегчает поддержку сессии на стороне клиента и снижает нагрузку на сервере. Давайте разбираться и поговорим про JWT подробнее.
Что такое JSON Web Tokens?
JWT — это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Эта информация может быть проверена и ей можно доверять, поскольку она имеет цифровую подпись. JWT можно подписать с использованием секретного ключа (алгоритм HMAC) или пары открытый / закрытый ключи с использованием RSA или ECDSA.
Когда следует использовать JSON Web Tokens?
Приведу пару сценариев применения JSON Web Tokens:
- Авторизация. Это наиболее распространенный сценарий использования JWT. После того как пользователь первый раз войдет в систему, в каждый следующий запрос будет добавляться JWT, позволяя пользователю получать доступ к маршрутам, службам и ресурсам, которые разрешены этому токену. SSO — это функция, которая в настоящее время широко использует JWT из-за ее небольших накладных расходов и возможности простого использования в разных доменах.
- Обмен информацией. JSON Web Tokens — это надёжный способ безопасной передачи информации между различными сервисами. Благодаря возможности подписывать JWT, например, с помощью пар открытого и закрытого ключей, вы можете быть уверены, что отправители — те, за кого себя выдают. Кроме того, поскольку подпись вычисляется на основе заголовка и полезной нагрузки, вы также можете быть уверены, что содержимое не было подделано.
Какая структура у JWT
В своей компактной форме веб-токены JSON состоят из трех частей, разделенных точками (.), которые являются:
- Заголовком (Header)
- Полезной нагрузкой (Payload)
- Подписью (Signature)
Следовательно, JWT обычно выглядит следующим образом.
xxxxx.yyyyy.zzzzz
Давайте разберем его на разные части.
Header. Обычно состоит из двух частей: типа токена, которым является JWT, и используемого алгоритма подписи, такого как HMAC SHA256 или RSA.
Пример заголовка:
{ "alg": "HS256", "typ": "JWT" }
Затем этот JSON кодируется в Base64Url, чтобы сформировать первую часть JWT.
Вы могли заметить что все имена параметров в header из трех букв, это не случайный пример и не совпадение. Все ради экономии трафика.
Payload. Вторая часть токена — это полезная нагрузка, которая содержит утверждения. Утверждения — это утверждения о сущности (обычно, пользователе) и дополнительных данных. Существует три типа утверждений: зарегистрированные(Registered claims), общедоступные(Public claims) и частные утверждения.
- Зарегистрированные утверждения: это набор предопределенных утверждений, которые не являются обязательными, но рекомендуются для предоставления набора полезных, совместимых утверждений. Вот некоторые из них: iss (эмитент), exp (время истечения срока действия), sub (тема), aud (аудитория) и другие.
- Общедоступные утверждения: Они могут быть определены по желанию теми, кто использует JWTS. Но во избежание коллизий они должны быть определены в реестре веб-токенов IANA JSON Web Token Registry или как URI, содержащий пространство имен, устойчивое к коллизиям.
- Частные утверждения: Это пользовательские утверждения, созданные для обмена информацией между сторонами, которые соглашаются на их использование, и не являются ни зарегистрированными, ни общедоступными утверждения.
Пример пейлоада:
{ "sub": "1234567890", "name": "John Doe", "admin": true }
Затем пейлоад кодируется в Base64Url для формирования второй части JSON Web Tokens.
Signature. Чтобы создать часть подписи, вы должны взять закодированный заголовок, закодированный пейлоад, секрет, алгоритм, указанный в заголовке, и подписать.
Например, если вы хотите использовать алгоритм HMAC SHA256, подпись будет создана следующим образом:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Подпись используется для проверки того, что сообщение не было изменено по пути, и, в случае токенов, подписанных закрытым ключом, она также может подтвердить, что отправитель JWT тот, за кого он себя выдает.
Соберем все вместе
Выходные данные представляют собой три строки Base64-URL, разделенные точками, которые могут быть легко переданы в средах HTML и HTTP, при этом они более компактны по сравнению со стандартами на основе XML, такими как SAML.
Ниже показан JWT, в котором закодированы предыдущий заголовок и полезная нагрузка, и он подписан секретом.

Если вы хотите поиграть с JWT, можете использовать jwt.io Debugger для декодирования, проверки и генерации JWT.

Как работает JWT?
При аутентификации, когда пользователь успешно входит в систему, используя свои учетные данные, возвращается JWT. Поскольку токены являются учетными данными, необходимо проявлять большую осторожность для предотвращения проблем с безопасностью. Как правило, вам не следует хранить токены дольше, чем требуется.
Вам также не следует хранить конфиденциальные данные сеанса в хранилище браузера — это не безопасно.
Всякий раз, когда пользователь хочет получить доступ к защищенному маршруту или ресурсу, юзерагент должен отправлять JWT, обычно в заголовке авторизации, используя схему Bearer. Содержимое заголовка должно выглядеть следующим образом:
Authorization: Bearer <token>
В определенных случаях это может быть механизм авторизации без сохранения состояния. Защищенные маршруты сервера проверяют наличие действующего JWT в заголовке авторизации, и если он там есть, пользователю будет разрешен доступ к защищенным ресурсам. Если в JWT есть информация о ролях или доступах, делать дополнительные вызовы к БД не нужно.
Обратите внимание, что если вы отправляете токены JWT через HTTP-заголовки, вы должны попытаться предотвратить их слишком большой размер. Некоторые серверы не принимают заголовки размером более 8 КБ. Если вы пытаетесь встроить слишком много информации в токен JWT, например, включив все разрешения пользователя, вам может понадобиться альтернативное решение, например, детализированная авторизация Auth0.
Если токен отправляется в заголовке Authorization, совместное использование ресурсов из разных источников (CORS) не будет проблемой, поскольку он не использует файлы cookie.
Давайте посмотрим на диаграмме, как JWT получается и используется для доступа к API или ресурсам:

- Приложение или клиент запрашивает авторизацию у сервера авторизации.
- Сервер авторизации предоставляет приложению токен доступа.
- Приложение использует токен доступа для доступа к защищенному ресурсу (например, API).
Обратите внимание, что с подписанными токенами вся информация, содержащаяся в токене, доступна пользователям или другим сторонам, даже если они не могут ее изменить. Это означает, что вы не должны помещать секретную информацию в токен.
Почему мы должны использовать JSON Web Tokens?
Давайте разберемся какие есть преимущества у JWT по сравнению с SWT и SAML.
- SWT — Simple Web Tokens
- SAML — Security Assertion Markup Language Tokens
Поскольку JSON менее подробный, чем XML, при кодировании его размер также меньше, что делает JWT более компактным, чем SAML. Меньший размер JWT является преимуществом при передаче данных через HTTP.
С точки зрения безопасности SWT может быть симметрично подписан только общим секретом с использованием алгоритма HMAC. Однако токены JWT и SAML могут использовать пару открытых / закрытых ключей в форме сертификата X.509 для подписи. Подписание XML с помощью XML Digital Signature сложнее организовать безопасно по сравнению с простотой подписания JSON.
Если говорить про использование JWT не в закрытом корпоративном контуре, а в интернете. Обработка JSON Web Tokens в разы проще, особенно на мобильных платформах, что несомненно является весомым плюсом.

Сравнение длины закодированного JWT и закодированного SAML
Надеюсь статья была для вас полезна и вы узнали что-то новове.
Подписывайтесь на мой телеграм канал, там тоже интересно: https://t.me/CrazyElephant_note
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.