WikiDer > Веб-токен JSON

JSON Web Token

Веб-токен JSON
Положение делИнтернет Стандарт
Впервые опубликовано28 декабря 2010 г. (2010-12-28)
Последняя версияRFC 7519
Май 2015 г.
ОрганизацияIETF
СокращениеJWT

Веб-токен JSON (JWT, иногда произносится /dʒɒт/, то же, что и английское слово "jot"[1]) - это Интернет-стандарт для создания данных с дополнительной подписью и / или дополнительным шифрованием, полезная нагрузка которых содержит JSON что утверждает некоторое количество претензий. Токены подписываются с использованием личного секрета или открытого / закрытого ключа. Например, сервер может сгенерировать токен с утверждением «зарегистрирован как администратор» и предоставить его клиенту. Затем клиент может использовать этот токен, чтобы доказать, что он вошел в систему как администратор. Токены могут быть подписаны закрытым ключом одной стороны. (обычно серверный) чтобы эта сторона могла впоследствии проверить, является ли токен законным. Если другая сторона каким-либо подходящим и заслуживающим доверия способом владеет соответствующим открытым ключом, она также может проверить легитимность токена. В жетоны разработаны, чтобы быть компактными,[2] URL-безопасный,[3] и особенно полезен в веб-браузер Единая точка входа (SSO) контекст. Утверждения JWT обычно могут использоваться для передачи удостоверений аутентифицированных пользователей между поставщик удостоверений и поставщик услугили претензии любого другого типа в соответствии с требованиями бизнес-процессов.[4][5]

JWT полагается на другие стандарты на основе JSON: Веб-подпись JSON и Веб-шифрование JSON.[1][6][7]

Структура

Заголовок
{  "Алг": «HS256»,  "тип": "JWT"}
Определяет, какой алгоритм используется для создания подписи

HS256 указывает, что этот токен подписан с использованием HMAC-SHA256.

Типичные используемые криптографические алгоритмы: HMAC с SHA-256 (HS256) и Подпись RSA с SHA-256 (RS256). JWA (веб-алгоритмы JSON) RFC 7518 вводит гораздо больше как для аутентификации, так и для шифрования.[8]

Полезная нагрузка
{  "loggedInAs": "админ",  "я": 1422779638}
Содержит набор требований. Спецификация JWT определяет семь зарегистрированных имен утверждений, которые являются стандартные поля обычно включается в токены.[1] Пользовательские утверждения обычно также включаются в зависимости от назначения токена.

В этом примере используется стандартное утверждение "Выпущено во время" (я) и индивидуальное требование (loggedInAs).

Подпись
HMAC-SHA256(  секрет,  base64urlEncoding(заголовок) + '.' +  base64urlEncoding(полезная нагрузка))
Надежно проверяет токен. Подпись вычисляется путем кодирования заголовка и полезной нагрузки с использованием Кодировка Base64url и объединение их вместе с разделителем периода. Эта строка затем проходит через криптографический алгоритм, указанный в заголовке, в данном случае HMAC-SHA256. В Кодировка Base64url похоже на base64, но использует другие символы, отличные от буквенно-цифровых, и пропускает заполнение.

Три части кодируются отдельно с помощью Кодировка Base64urlи объединены точками для создания JWT:

const жетон = base64urlEncoding(заголовок) + '.' + base64urlEncoding(полезная нагрузка) + '.' + base64urlEncoding(подпись)

Приведенные выше данные и секрет секретного ключа создают токен:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBXLNGCMJCMJSiSiSyxLyCMjCMjSySySySycMyCMjCMjCMjs

Полученный токен можно легко передать в HTML и HTTP.[3]

Использовать

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

POST / oauth2 / токен?Тип содержимого:заявление/x-www-form-urlencodedgrant_type = urn: ietf: params: oauth: grant-type: jwt-bearer & assertion = eyJhb ...

Если клиент передает допустимое утверждение JWT, сервер сгенерирует access_token, действительный для выполнения вызовов в приложение, и вернет его клиенту:

{  "access_token": "eyJhb ...",  "token_type": "Предъявитель",  "истекает": 3600}

Когда клиент хочет получить доступ к защищенному маршруту или ресурсу, пользовательский агент должен отправить JWT, обычно в Авторизация заголовок с использованием Предъявитель схема. Содержание заголовка может выглядеть следующим образом:

Авторизация: предъявитель eyJhbGci... <щелчок> ...yu5CSpyHI

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

Стандартные поля

Интернет-черновики определяют следующие стандартные поля («утверждения»), которые можно использовать в наборе утверждений JWT:

кодимяописание
мксЭмитентОпределяет принципала, выдавшего JWT.
субПредметОпределяет тему JWT.
audАудиторияОпределяет получателей, для которых предназначен JWT. Каждый принципал, предназначенный для обработки JWT должен идентифицировать себя с ценностью в заявлении аудитории. Если принципал, обрабатывающий требование, не идентифицирует себя со значением в aud заявить, когда это утверждение присутствует, то JWT должен быть отклоненным.
expВремя окончания срока действияОпределяет время истечения срока действия, после которого JWT не должен быть принятым в обработку. Значение должно быть NumericDate:[9] целое или десятичное число, представляющее прошедшие секунды 1970-01-01 00: 00: 00Z.
nbfНе раньше, чемОпределяет время, когда JWT начнет приниматься в обработку. Значение должно быть NumericDate.
яВыдано вОпределяет время, когда был выпущен JWT. Значение должно быть NumericDate.
jtiJWT IDУникальный идентификатор токена с учетом регистра даже у разных эмитентов.

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

кодимяописание
типТип токенаЕсли присутствует, рекомендуется установить его на JWT.
ctyТип содержимогоЕсли используется вложенная подпись или шифрование, рекомендуется установить для этого параметра значение JWT; в противном случае пропустите это поле.[1]
algАлгоритм кода аутентификации сообщенияЭмитент может свободно установить алгоритм для проверки подписи на токене. Однако некоторые поддерживаемые алгоритмы небезопасны.[10]
дитяID ключаПодсказка, указывающая, какой ключ клиент использовал для создания подписи токена. Сервер сопоставит это значение с ключом в файле, чтобы убедиться, что подпись действительна и токен подлинен.
x5cx.509 Цепочка сертификатовЦепочка сертификатов в формате RFC4945, соответствующая закрытому ключу, используемому для генерации подписи токена. Сервер будет использовать эту информацию, чтобы убедиться, что подпись действительна, а токен подлинен.
x5uURL-адрес цепочки сертификатов x.509URL-адрес, по которому сервер может получить цепочку сертификатов, соответствующую закрытому ключу, используемому для генерации подписи токена. Сервер получит и использует эту информацию для проверки подлинности подписи.
критКритическийСписок заголовков, которые должны быть поняты сервером, чтобы принять токен как действительный.


Реализации

Реализации JWT существуют для многих языков и фреймворков, включая, помимо прочего:

Уязвимости

Веб-токены JSON могут содержать состояние сеанса. Но если требования проекта допускают аннулирование сеанса до истечения срока действия JWT, службы больше не могут доверять утверждениям токена только по токену. Чтобы убедиться, что сеанс, хранящийся в токене, не отменен, утверждения токена должны быть проверены на соответствие хранилище данных. Это делает токены более не безгражданскими, что подрывает основное преимущество JWT.[36]

Консультант по безопасности Тим Маклин сообщил об уязвимостях в некоторых библиотеках JWT, которые использовали alg поле для неправильной проверки токенов. Пока эти уязвимости были исправлены, Маклин предложил исключить alg поле, чтобы избежать путаницы в реализации.[10]

При правильном проектировании разработчики могут устранить уязвимости алгоритмов, приняв меры предосторожности:[37][38]

  1. Никогда не позволяйте только заголовку JWT управлять проверкой
  2. Знайте алгоритмы
  3. Используйте ключ подходящего размера

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

Рекомендации

  1. ^ а б c d Джонс, Майкл Б .; Брэдли, Брэдли; Сакимура, Сакимура (май 2015 г.). Веб-токен JSON (JWT). IETF. Дои:10.17487 / RFC7519. ISSN 2070-1721. RFC 7519.
  2. ^ Никель, Йохен (2016). Освоение управления идентификацией и доступом с помощью Microsoft Azure. п. 84. ISBN 9781785887888. Получено 20 июля, 2018.
  3. ^ а б «JWT.IO - Введение в веб-токены JSON». jwt.io. Получено 20 июля, 2018.
  4. ^ Севилья, Крис. «Анатомия веб-токена JSON». Получено 8 мая, 2015.
  5. ^ «Документация Atlassian Connect». developer.atlassian.com. Получено 8 мая, 2015.
  6. ^ "draft-ietf-jose-json-web-signature-41 - веб-подпись JSON (JWS)". tools.ietf.org. Получено 8 мая, 2015.
  7. ^ "draft-ietf-jose-json-web-encryption-40 - веб-шифрование JSON (JWE)". tools.ietf.org. Получено 8 мая, 2015.
  8. ^ "draft-ietf-jose-json-web-algorithmms-40 - веб-алгоритмы JSON (JWA)". tools.ietf.org. Получено 8 мая, 2015.
  9. ^ Джонс, Майкл Б .; Брэдли, Брэдли; Сакимура, Сакимура (май 2015 г.). ""exp "(Срок действия) Заявление". Веб-токен JSON (JWT). IETF. сек. 4.1.4. Дои:10.17487 / RFC7519. ISSN 2070-1721. RFC 7519.
  10. ^ а б Маклин, Тим (31 марта 2015 г.). «Критические уязвимости в библиотеках JSON Web Token». Auth0. Получено 29 марта, 2016.
  11. ^ jwt-dotnet на github.com
  12. ^ libjwt на github.com
  13. ^ "liquidz / clj-jwt". GitHub. Получено 7 мая, 2018.
  14. ^ cljwt на github.com
  15. ^ [1] на github.com
  16. ^ "bryanjos / joken". GitHub. Получено 7 мая, 2018.
  17. ^ "dgrijalva / jwt-go". GitHub. Получено 8 января, 2018.
  18. ^ "jwt: декодирование и кодирование веб-токена JSON (JWT)". Взлом. Получено 7 мая, 2018.
  19. ^ auth0 / java-jwt на github.com
  20. ^ "кюр / jsrsasign". GitHub. Получено 7 мая, 2018.
  21. ^ "SkyLothar / lua-resty-jwt". GitHub. Получено 7 мая, 2018.
  22. ^ "jsonwebtoken". npm. Получено 7 мая, 2018.
  23. ^ ocaml-jwt на github.com
  24. ^ Склеп :: JWT на cpan.org
  25. ^ lcobucci / jwt на github.com
  26. ^ Иган, Мортен (7 февраля 2019 г.), GitHub - morten-egan / jwt_ninja: Реализация веб-токенов JSON в PLSQL., получено 14 марта, 2019
  27. ^ "SP3269 / posh-jwt". GitHub. Получено 1 августа, 2018.
  28. ^ "jpadilla / pyjwt". GitHub. Получено Двадцать первое марта, 2017.
  29. ^ net-jwt на pkgs.racket-lang.org
  30. ^ JSON-WebToken на github.com
  31. ^ ruby-jwt на github.com
  32. ^ frank_jwt на github.com
  33. ^ [2] на github.com
  34. ^ jwt-scala на github.com
  35. ^ [3] на github.com
  36. ^ Slootweg, Sven. «Прекратите использовать JWT для сеансов». joepie91 Ramblings. Получено 1 августа, 2018.
  37. ^ «Распространенные уязвимости безопасности JWT и как их избежать». Получено 14 мая, 2018.
  38. ^ Андреас, Хаппе. «JWT: сигнатура против MAC-атак». snikt.net. Получено 27 мая, 2019.
  39. ^ Родармер, Курт (21 июля 2019 г.). "Неизвестные уязвимости безопасности JWT". rodarmer.com. Получено 25 июля, 2019.

внешняя ссылка