✖


Jump to content

Веб-токен JSON

Веб-токен JSON
Аббревиатура JWT
Статус Предлагаемый стандарт
Впервые опубликовано 28 декабря 2010 г. ( 28.12.2010 )
Последняя версия RFC   7519
май 2015 г.
Организация IETF
комитет IEGS
Авторы
Базовые стандарты
Домен Обмен данными
Веб-сайт трекер данных .ietf .org /док /html /rfc7519

Веб-токен JSON ( JWT , предлагаемое произношение / dʒ ɒ t / , то же, что и слово «jot» [1] ) — это предлагаемый Интернет-стандарт для создания данных с необязательной подписью и/или необязательным шифрованием, которых полезная нагрузка содержит JSON , утверждающий некоторое количество утверждений . Токены подписываются либо с использованием закрытого секрета , либо с использованием открытого/закрытого ключа .

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

JWT опирается на другие стандарты на основе JSON: JSON Web Signature и JSON Web Encryption . [1] [6] [7]

Структура

[ редактировать ]
Заголовок
Определяет, какой алгоритм используется для создания подписи. В приведенном ниже примере HS256 указывает, что этот токен подписан с использованием HMAC-SHA256.
Типичными используемыми криптографическими алгоритмами являются HMAC с SHA-256 (HS256) и подпись RSA с SHA-256 (RS256). JWA (Веб-алгоритмы JSON) RFC 7518 представляет множество дополнительных возможностей как для аутентификации, так и для шифрования. [8] 
{
  "alg": "HS256",
  "typ": "JWT"
}
Полезная нагрузка
Содержит набор утверждений. Спецификация JWT определяет семь зарегистрированных имен утверждений, которые являются стандартными полями, обычно включаемыми в токены. [1] Обычно также включаются пользовательские утверждения, в зависимости от назначения токена.
В этом примере используется стандартное утверждение Issued At Time ( iat) и таможенная претензия ( loggedInAs). 
{
  "loggedInAs": "admin",
  "iat": 1422779638
}
Подпись
Надежно проверяет токен. Подпись рассчитывается путем кодирования заголовка и полезных данных с использованием кодировки Base64url. RFC   4648 и объединить их вместе с помощью разделителя точки. Затем эта строка обрабатывается криптографическим алгоритмом, указанным в заголовке. В этом примере используется HMAC-SHA256 с общим секретом (также определены алгоритмы открытого ключа). Кодировка Base64url аналогична base64 , но использует другие небуквенно-цифровые символы и не содержит дополнений. 
HMAC_SHA256(
  secret,
  base64urlEncoding(header) + '.' +
  base64urlEncoding(payload)
)

Эти три части кодируются отдельно с использованием кодировки Base64url. RFC   4648 и объединены с использованием точек для создания JWT: 

const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbk FzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN _oWnFSRgCzcmJmMjLiuyu5CSpyHI=

(Вышеупомянутые строки json отформатированы без перевода строки или пробелов в байтовые массивы utf-8. Это важно, поскольку даже небольшие изменения в данных повлияют на полученный токен)

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

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

[ редактировать ]

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

POST /oauth2/token
Content-type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...

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

{
  "access_token": "eyJhb...",
  "token_type": "Bearer",
  "expires_in": 3600
}

Когда клиент хочет получить доступ к защищенному маршруту или ресурсу, пользовательский агент должен отправить JWT, обычно в формате Authorization HTTP-заголовок с использованием Bearer схема. Содержимое заголовка может выглядеть следующим образом: 

Authorization: Bearer eyJhbGci...<snip>...yu5CSpyHI

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

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

[ редактировать ]
Код Имя Описание
Стандартные поля заявки Интернет-проекты определяют следующие стандартные поля («утверждения»), которые можно использовать внутри набора утверждений JWT.
iss Эмитент Идентифицирует принципала, выдавшего JWT.
sub Предмет Идентифицирует тему JWT.
aud Аудитория Идентифицирует получателей, для которых предназначен JWT. Каждый субъект, предназначенный для обработки JWT, должен идентифицировать себя со значением в утверждении аудитории. Если принципал, обрабатывающий утверждение, не идентифицирует себя со значением в aud Если это утверждение присутствует, то JWT должен быть отклонен.
exp Срок годности Определяет время истечения срока действия, после которого JWT не может быть принят к обработке. Значение должно быть NumericDate: [9] целое или десятичное число, представляющее секунды после 1970-01-01 00:00:00Z .
nbf Не раньше Определяет время, когда JWT начнет приниматься в обработку. Значение должно быть NumericDate.
iat Выпущено в Определяет время выдачи JWT. Значение должно быть NumericDate.
jti JWT-идентификатор Уникальный идентификатор токена, чувствительный к регистру, даже среди разных эмитентов.
Часто используемые поля заголовка Следующие поля обычно используются в заголовке JWT.
typ Тип токена Если он присутствует, он должен быть установлен на зарегистрированный IANA Media Type .
cty Тип контента Если используется вложенная подпись или шифрование, рекомендуется установить для этого параметра значение JWT; в противном случае опустите это поле. [1]
alg Алгоритм кода аутентификации сообщения Эмитент может свободно установить алгоритм проверки подписи на токене. Однако некоторые поддерживаемые алгоритмы небезопасны. [10]
kid Идентификатор ключа Подсказка, указывающая, какой ключ клиент использовал для создания подписи токена. Сервер сопоставит это значение с ключом в файле, чтобы убедиться, что подпись действительна и токен аутентичен.
x5c Цепочка сертификатов x.509 Цепочка сертификатов в формате RFC4945, соответствующая закрытому ключу, используемому для создания подписи токена. Сервер будет использовать эту информацию для проверки правильности подписи и подлинности токена.
x5u URL-адрес цепочки сертификатов x.509 URL-адрес, по которому сервер может получить цепочку сертификатов, соответствующую закрытому ключу, используемому для создания подписи токена. Сервер получит и использует эту информацию для проверки подлинности подписи.
crit Критический Список заголовков, которые должен понимать сервер, чтобы принять токен как действительный.
Код Имя Описание

Реализации

[ редактировать ]

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

Уязвимости

[ редактировать ]

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

Консультант по безопасности Тим Маклин сообщил об уязвимостях в некоторых библиотеках JWT, которые использовали alg поле для неправильной проверки токенов, чаще всего путем принятия alg=none жетон. Хотя эти уязвимости были исправлены, Маклин предложил прекратить поддержку alg поле целиком, чтобы предотвратить подобную путаницу в реализации. [10] Все-таки новый alg=none уязвимости до сих пор обнаруживаются: четыре CVE , имеющих эту причину. в период 2018–2021 годов было зарегистрировано [37] [ нужен лучший источник ]

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

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

В 2017 году было обнаружено, что несколько библиотек JWT уязвимы для недействительной атаки с использованием эллиптической кривой . [40]

Некоторые утверждают, что веб-токены JSON сложно безопасно использовать из-за множества различных алгоритмов и опций шифрования, доступных в стандарте, и что вместо этого следует использовать альтернативные стандарты для обоих веб-интерфейсов. [41] и бэкэнды. [42]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б с д Джонс, Майкл Б.; Брэдли, Брэдли; Сакимура, Сакимура (май 2015 г.). Веб-токен JSON (JWT) . IETF . дои : 10.17487/RFC7519 . ISSN   2070-1721 . РФК 7519 .
  2. ^ Никель, Йохен (2016). Освоение управления идентификацией и доступом с помощью Microsoft Azure . Пакт Паблишинг. п. 84. ИСБН  9781785887888 . Проверено 20 июля 2018 г.
  3. ^ Перейти обратно: а б «JWT.IO — Введение в веб-токены JSON» . jwt.io. ​Проверено 20 июля 2018 г.
  4. ^ Севилья, Крис. «Анатомия веб-токена JSON » Получено мая 8 ,
  5. ^ «Документация Atlassian Connect» . http://developer.atlassian.com . Архивировано из оригинала 18 мая 2015 года . Проверено 8 мая 2015 г.
  6. ^ Джонс, Майкл Б.; Брэдли, Джон; Сакимура, Нат (май 2015 г.). «draft-ietf-jose-json-web-signature-41 — Веб-подпись JSON (JWS)» . www.tools.ietf.org . Проверено 8 мая 2015 г.
  7. ^ Джонс, Майкл Б.; Хильдебранд, Джо (май 2015 г.). «draft-ietf-jose-json-web-encryption-40 — Веб-шифрование JSON (JWE)» . www.tools.ietf.org . Проверено 8 мая 2015 г.
  8. ^ Джонс, Майкл Б. (май 2015 г.). «draft-ietf-jose-json-web-algorithms-40 — Веб-алгоритмы JSON (JWA)» . www.tools.ietf.org . Проверено 8 мая 2015 г.
  9. ^ Джонс, Майкл Б.; Брэдли, Брэдли; Сакимура, Сакимура (май 2015 г.). « Заявление «exp» (время истечения срока действия)» . Веб-токен JSON (JWT) . IETF . сек. 4.1.4. дои : 10.17487/RFC7519 . ISSN   2070-1721 . РФК 7519 .
  10. ^ Перейти обратно: а б Маклин, Тим (31 марта 2015 г.). «Критические уязвимости в библиотеках JSON Web Token» . Аутент0 . Проверено 29 марта 2016 г.
  11. ^ jwt-dotnet на github.com
  12. ^ libjwt на github.com
  13. ^ "liquidz/clj-jwt" . Гитхаб . Проверено 7 мая 2018 г.
  14. ^ cljwt на github.com
  15. ^ JustJWT на github.com
  16. ^ «брианьос/шукен» . Гитхаб . Проверено 7 мая 2018 г.
  17. ^ "голанг-jwt/jwt" . Гитхаб . Проверено 8 января 2018 г.
  18. ^ «jose: библиотека подписи и шифрования объектов JSON (JOSE) и JSON Web Token (JWT)» . Хакадж . Проверено 25 декабря 2022 г.
  19. ^ auth0/java-jwt на github.com
  20. ^ "кьюр/jsrsasign" . Гитхаб . Проверено 7 мая 2018 г.
  21. ^ "SkyLothar/lua-resty-jwt" . Гитхаб . Проверено 7 мая 2018 г.
  22. ^ «jsonwebtoken» . НПМ . Проверено 7 мая 2018 г.
  23. ^ ocaml-jwt на github.com
  24. ^ Crypt::JWT на cpan.org
  25. ^ lcobucci/jwt на github.com
  26. ^ Иган, Мортен (7 февраля 2019 г.), GitHub — morten-egan/jwt_ninja: Реализация PLSQL веб-токенов JSON. , получено 14 марта 2019 г.
  27. ^ "SP3269/пош-jwt" . Гитхаб . Проверено 1 августа 2018 г.
  28. ^ "jpadilla/pyjwt" . Гитхаб . Проверено 21 марта 2017 г.
  29. ^ net-jwt на pkgs.racket-lang.org.
  30. ^ JSON-WebToken на github.com
  31. ^ Ruby-jwt на github.com
  32. ^ jsonwebtoken — github.com
  33. ^ ржавчина-jwt на github.com
  34. ^ jwt-scala на github.com
  35. ^ [1] на github.com
  36. ^ Слотвег, Свен. «Прекратите использовать JWT для сеансов» . joepie91 Рамблингс . Проверено 1 августа 2018 г.
  37. ^ «CVE — Результаты поиска» . cve.mitre.org .
  38. ^ «Распространенные уязвимости безопасности JWT и способы их предотвращения» . Проверено 14 мая 2018 г.
  39. ^ Андреас, Хаппе. «JWT: Сигнатура против MAC-атак» . сникт.нет . Проверено 27 мая 2019 г.
  40. ^ «Критическая уязвимость в веб-шифровании JSON» . Auth0 — Блог . Проверено 14 октября 2023 г.
  41. ^ «Ни за что, ХОЗЕ! Подписание и шифрование объектов Javascript — это плохой стандарт, которого всем следует избегать — блог Paragon Initiative Enterprises» . www.paragonie.com . Проверено 13 октября 2023 г.
  42. ^ «Подводные камни авторизации JWT» . authzed.com . Проверено 16 ноября 2023 г.
  • RFC   7519
  • jwt.io — специализированный сайт о JWT с инструментами и документацией, поддерживаемый Auth0.
Retrieved from "https://en.wikipedia.org/w/index.php?title=JSON_Web_Token&oldid=1235260728"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 8cf6db86f3bec1902c0fbe87346a756e__1721294940
URL1:https://arc.ask3.ru/arc/aa/8c/6e/8cf6db86f3bec1902c0fbe87346a756e.html
Заголовок, (Title) документа по адресу, URL1:
JSON Web Token - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)