Что такое веб-токен JSON?
JSON Web Token (JWT) - это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Эта информация может быть проверена и надежна, потому что она имеет цифровую подпись. JWT могут быть подписаны с использованием секрета (с помощью алгоритма HMAC ) или пары открытого / секретного ключей с использованием RSA или ECDSA .
Хотя JWT могут быть зашифрованы для обеспечения секретности между сторонами, мы сосредоточимся на подписанных токенах. Подписанные токены могут проверять целостность утверждений, содержащихся в нем, в то время как зашифрованные токены скрывают эти утверждения от других сторон. Когда токены подписаны с использованием пар открытого и закрытого ключей, эта подпись также подтверждает, что подписать ее является только сторона, имеющая закрытый ключ.
Когда следует использовать веб-токены JSON?
Вот несколько сценариев, в которых полезны веб-токены JSON:
Авторизация: Это наиболее распространенный сценарий использования JWT. Как только пользователь вошел в систему, каждый последующий запрос будет включать JWT, позволяющий пользователю получать доступ к маршрутам, службам и ресурсам, которые разрешены с этим токеном. Single Sign On - это функция, которая в настоящее время широко использует JWT из-за небольших накладных расходов и способности легко использоваться в разных доменах.
Обмен информацией: Веб-токены JSON являются хорошим способом безопасной передачи информации между сторонами. Поскольку JWT могут быть подписаны, например, с использованием пар открытого и закрытого ключей, вы можете быть уверены, что отправители - это те, кем они себя называют. Кроме того, поскольку подпись рассчитывается с использованием заголовка и полезной нагрузки, вы также можете убедиться, что содержимое не было подделано.
Что такое структура JSON Web Token?
В своей компактной форме веб-токены JSON состоят из трех частей, разделенных точками (.):
- Заголовок
- Payload
- Подпись
Следовательно, JWT обычно выглядит следующим образом.
xxxxx.yyyyy.zzzzz
Давайте разберем разные части.
Заголовок
Заголовок обычно состоит из двух частей: тип токена, который является JWT, и используемый алгоритм подписи, такой как HMAC SHA256 или RSA.
Например:
{
"alg": "HS256",
"typ": "JWT"
}
Затем этот JSON кодируется Base64Url , образуя первую часть JWT.
Payload
Вторая часть токена - это полезная нагрузка, которая содержит заявки. Претензии - это заявления о сущности (обычно о пользователе) и дополнительные данные. Существует три типа претензий: зарегистрированные, публичные и частные.
Зарегистрированные заявки: Это набор предопределенных заявок, которые не являются обязательными, но рекомендуются для предоставления набора полезных, совместимых заявок. Некоторые из них: iss (эмитент), exp (срок действия), sub (субъект), aud (аудитория), и другие .
Notice that the claim names are only three characters long as JWT is meant to be compact.
Публичные заявления: Они могут быть определены по желанию теми, кто использует JWT. Но чтобы избежать коллизий, они должны быть определены в IANA JSON Web Token Registry или определены как URI, который содержит пространство имен, устойчивое к столкновениям.
Частные претензии: Это пользовательские претензии, созданные для обмена информацией между сторонами, которые согласились их использовать и не являются ни зарегистрированными, ни публичными претензиями.
Пример полезной нагрузки может быть:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Полезная нагрузка затем кодируется Base64Url для формирования второй части веб-токена JSON.
Do note that for signed tokens this information, though protected against tampering, is readable by anyone. Do not put secret information in the payload or header elements of a JWT unless it is encrypted.
Подпись
Чтобы создать часть подписи, вы должны взять закодированный заголовок, кодированную полезную нагрузку, секрет, алгоритм, указанный в заголовке, и подписать его.
Например, если вы хотите использовать алгоритм HMAC SHA256, подпись будет создана следующим образом:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Подпись используется для проверки того, что сообщение не было изменено по пути, и, в случае токенов, подписанных с помощью закрытого ключа, оно также может проверить, что отправитель JWT является тем, кем он является.
Собираем все вместе
Выходные данные представляют собой три строки Base64-URL, разделенных точками, которые можно легко передавать в средах HTML и HTTP, при этом они более компактны по сравнению со стандартами на основе XML, такими как SAML.
Ниже показан JWT, в котором были закодированы предыдущий заголовок и полезная нагрузка и который подписан секретом. Кодированный JWT
Если вы хотите поиграть с JWT и применить эти концепции на практике, вы можете использовать jwt.io Debugger для декодирования, проверки и генерации JWT.
JWT.io Отладчик
Как работают веб-токены JSON?
При аутентификации, когда пользователь успешно входит в систему, используя свои учетные данные, возвращается веб-токен JSON. Поскольку токены являются учетными данными, необходимо тщательно следить за тем, чтобы не допустить проблем с безопасностью. Как правило, вы не должны хранить токены дольше, чем требуется.
Всякий раз, когда пользователь хочет получить доступ к защищенному маршруту или ресурсу, пользовательский агент должен отправлять JWT, как правило, в заголовке Авторизация , используя схему Bearer . Содержимое заголовка должно выглядеть следующим образом:
Authorization: Bearer <token>
В некоторых случаях это может быть механизм авторизации без сохранения состояния. Защищенные маршруты сервера будут проверять допустимый JWT в заголовке Authorization , и, если он присутствует, пользователю будет разрешен доступ к защищенным ресурсам. Если JWT содержит необходимые данные, потребность в запросе базы данных для определенных операций может быть уменьшена, хотя это может не всегда иметь место.
Если токен отправляется в заголовке Authorization , обмен ресурсами между источниками (CORS) не будет проблемой, поскольку он не использует файлы cookie.
Следующая диаграмма показывает, как JWT получается и используется для доступа к API или ресурсам:
- Приложение или клиент запрашивает авторизацию
сервер авторизации. Это выполняется через один из разных
потоки авторизации. Например, типичный OpenID Connect-совместимый
веб-приложение будет проходить через конечную точку / oauth / authorize, используя
поток кода авторизации.
- Когда авторизация предоставлена, сервер авторизации возвращает
токен доступа к приложению.
- Приложение использует токен доступа для доступа к защищенному ресурсу.
(как API).
Обратите внимание, что с подписанными токенами вся информация, содержащаяся в токене, предоставляется пользователям или другим сторонам, даже если они не могут ее изменить. Это означает, что вы не должны помещать секретную информацию в токен.
Почему мы должны использовать JSON Web Tokens?
Давайте поговорим о преимуществах веб-токенов JSON (JWT) по сравнению с простыми веб-токенами (SWT) и токенами языка разметки утверждений безопасности (SAML) .
Поскольку JSON менее многословен, чем XML, при кодировании его размер также меньше, что делает JWT более компактным, чем SAML. Это делает JWT хорошим выбором для передачи в средах HTML и HTTP.
С точки зрения безопасности SWT может быть подписан только симметрично общим секретным ключом с использованием алгоритма HMAC. Однако токены JWT и SAML могут использовать для подписи пару открытый / закрытый ключи в форме сертификата X.509. Подписание XML с помощью цифровой подписи XML без введения непонятных дыр в безопасности очень сложно по сравнению с простотой подписания JSON.
Парсеры JSON распространены в большинстве языков программирования, потому что они отображаются непосредственно на объекты. И наоборот, XML не имеет естественного отображения документа на объект. Это облегчает работу с JWT, чем с утверждениями SAML.
Что касается использования, JWT используется в масштабе Интернета. Это подчеркивает простоту обработки клиентского веб-токена JSON на нескольких платформах, особенно мобильных.
Сравнение длины кодированного JWT и кодированного SAML Сравнение длины кодированного JWT и кодированного SAML
Если вы хотите узнать больше о веб-токенах JSON и даже начать использовать их для аутентификации в своих собственных приложениях, перейдите на целевую страницу Веб-токен JSON в Auth0.