Слияние кода завершено, страница обновится автоматически
Что такое JSON Web Token (JWT)
JSON Web Token (JWT) — это открытый стандарт (RFC 7519), который определяет простой и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Благодаря цифровой подписи эти данные можно проверить и доверять им.
JWT можно подписать с помощью секрета (с использованием алгоритма HMAC) или с помощью открытого/закрытого ключа (RSA или ECDSA).
Хотя JWT можно использовать для обмена данными между сторонами, предоставляя секрет (секретный ключ), основное внимание уделяется подписанным токенам. Подписанные токены позволяют проверять целостность данных, а зашифрованные токены могут скрывать утверждения от других сторон.
Когда токен подписывается с использованием открытого/закрытого ключей, только сторона, владеющая закрытым ключом, может подписать его.
Ключевые термины на английском и русском языках
Когда следует использовать JSON Web Tokens
В некоторых сценариях JSON Web Tokens могут быть полезны:
Аутентификация и авторизация (Authentication): Это наиболее распространённое применение JWT. После успешной аутентификации пользователя каждый последующий запрос будет содержать информацию о JWT. Механизм проверки JWT позволяет пользователю получать доступ к маршрутам, сервисам и ресурсам, разрешённым токеном. Из-за небольшого размера JWT они широко используются в системах единого входа (Single Sign On).
Обмен информацией (Information Exchange): Поскольку JWT можно подписывать, они обеспечивают безопасный обмен информацией между различными системами. Например, используя пары открытых/закрытых ключей, вы можете гарантировать подлинность отправителя запроса. Кроме того, поскольку информация в заголовке и полезной нагрузке участвует в расчётах, вы можете проверить, не была ли она подделана.
Структура JSON Web Token
JSON Web Tokens состоят из трёх частей, разделённых точками:
— заголовок (Header); — полезная нагрузка (Payload); — подпись (Signature).
Именно благодаря этой организации JWT обычно выглядит следующим образом: xxxxx.yyyyy.zzzzz.
Давайте подробно рассмотрим эту форму.
Заголовок (Header)
Данные в заголовке обычно содержат две части: тип токена (в данном случае «JWT») и используемый алгоритм подписи, например SHA256 или RSA. Пример формата: { "alg": "HS256", "typ": "JWT" }
Затем данные JSON кодируются с использованием алгоритма Base64Url, что даёт первую часть JWT.
Полезная нагрузка (Payload)
Вторая часть JWT состоит из утверждений. Утверждения — это информация о сущности (обычно пользователе) и другие данные. Существует три типа утверждений: зарегистрированные, публичные и частные.
Зарегистрированные утверждения (Registered claims): Эти утверждения предварительно определены и рекомендуются к использованию, но не обязательны. Они предоставляют ряд общепринятых конфигураций, таких как iss (эмитент), exp (срок действия), sub (субъект), aud (аудитория) и другие. Обратите внимание, что эти стандартные конфигурации имеют длину всего три символа, чтобы уменьшить размер данных.
Публичные утверждения (Public claims): Эти данные могут свободно определяться пользователем, использующим JWT, но для предотвращения конфликтов рекомендуется ссылаться на них в IANA JSON Web Token Registry или определять их как URI, избегая потенциальных конфликтов.
Частные утверждения (Private claims): Эти данные являются настраиваемыми и используются для временного преобразования данных при передаче. Эти данные не определены в зарегистрированных и публичных утверждениях.
Пример полезной нагрузки: { "sub": "1234567890", "name": "John Doe", "admin": true }
Как и заголовок, полезная нагрузка кодируется с использованием Base64Url, образуя вторую часть JWT. Обратите внимание, что данные в этой части также защищены от несанкционированного доступа, но могут быть расшифрованы. Поэтому не рекомендуется включать какие-либо ключи в эти данные, если только ключ не был уже зашифрован.
Подпись (Signature)
Для создания подписанной части необходимо иметь закодированные заголовок и полезную нагрузку, а также ключ (secret) и указанный в заголовке алгоритм шифрования. Например, если вы хотите использовать алгоритм HMAC SHA256 для подписи, данные в алгоритме будут следующими: HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Цель подписи — проверить, что передаваемый токен не был подделан. Если токен подписан с использованием закрытого ключа, он также может быть проверен, чтобы убедиться, что отправитель использовал действительную подпись.
Объединив эти три части и закодировав их с помощью Base64-URL, можно создать JWT. Каждая часть данных разделяется точкой, обеспечивая лёгкую передачу токенов по сети HTTP и HTML. По сравнению с XML-токенами, такими как SAML, JWT более лаконичны и эффективны.
Вот пример JWT, который включает в себя данные заголовка, полезную нагрузку и цифровую подпись, объединённые вместе:
Если вы хотите использовать JWT или расшифровать существующий JWT, вы можете использовать инструменты на сайте https://jwt.io/#debugger-io для декодирования, проверки и создания JWT-токенов. Приложение также не должно хранить эти конфиденциальные данные в браузере, поскольку это может привести к утечке информации, см. ссылку: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#local-storage.
В любое время, когда пользователь хочет получить доступ к защищённому ресурсу или маршруту, он должен включать JWT-токен в запрос на доступ. Обычно этот токен хранится в заголовке HTTP-запроса, обычно используя поле «Authorization» с режимом «Bearer».
Содержимое, содержащееся в заголовке HTTP, выглядит следующим образом:
Authorization: Bearer <token>
В некоторых случаях можно использовать механизм авторизации без сохранения состояния. Защищённые маршруты на сервере будут проверять JWT-токены, представленные вместе с запросом на доступ. Если токен действителен, пользователю будет разрешён доступ к определённому ресурсу.
Если JWT-токен содержит необходимую информацию, серверу не нужно будет выполнять дополнительные запросы к базе данных, что ускоряет доступ. Конечно, это не всегда возможно.
Когда токен отправляется вместе с заголовком «Authorization», нам не нужно использовать файлы cookie, поэтому совместное использование ресурсов между источниками (Cross-Origin Resource Sharing (CORS)) не должно быть проблемой.
Следующий пример показывает, как получается JWT и как он используется для доступа к API сервера.
Обратите внимание, что хотя пользователь не может изменить используемый токен, вся информация, содержащаяся в токене, будет доступна пользователю или другим приложениям. Поэтому вы не должны хранить ключи или любую конфиденциальную информацию в своём токене.
Давайте обсудим преимущества JSON Web Tokens (JWT) по сравнению с Simple Web Tokens (SWT) и Security Assertion Markup Language Tokens (SAML).
По сравнению с XML формат JSON более лаконичен, а после кодирования объём данных меньше. Это делает JWT более компактным по сравнению с SAML, что упрощает передачу данных через HTTP и HTML.
С точки зрения безопасности SWT может использовать только симметричное подписание с помощью алгоритма HMAC. И JWT, и SAML могут использовать шифрование и дешифрование на основе пары открытого и закрытого ключей X.509. По сравнению с подписью JSON, подпись XML легче подвержена уязвимостям безопасности.
Что касается обработки JSON, почти все языки поддерживают и анализируют его, потому что данные JSON легче сопоставить с объектами данных. XML не имеет поддержки сопоставления текста с объектами. Это делает обработку JWT проще по сравнению с SAML.
В использовании JWT широко применяется в Интернете и подходит для многоплатформенного использования. На клиенте JSON проще использовать, особенно на мобильных платформах.
Сравнение содержимого JSON и SAML см. на следующем рисунке:
Из сравнения на рисунке видно, что контент на основе JSON меньше и выразительнее.
Для получения дополнительной информации о использовании JSON Web Tokens и начала их применения в вашей системе обратитесь к официальному представлению и документации Auth0, доступному по ссылке: http://auth0.com/learn/json-web-tokens.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )