Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Структура [ править ]

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

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

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

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

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

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

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

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

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLyCMjCMjSraSYS8EXBxLNgCMjCMjcMySySySiSiCMyCMjCMjCMjs

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

Используйте [ редактировать ]

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

POST / oauth2 / токен? Тип содержимого: приложение / 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заголовке с использованием 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.
jtiJWT IDУникальный идентификатор токена с учетом регистра даже среди разных эмитентов.

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

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

Реализации [ править ]

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

  • .NET (C # VB.Net и т. Д.) [11]
  • C [12]
  • Clojure [13]
  • Общий Лисп [14]
  • Дротик [15]
  • Эликсир [16]
  • Erlang
  • Вперед [17]
  • Haskell [18]
  • Java [19]
  • JavaScript [20]
  • Lua [21]
  • Node.js [22]
  • OCaml [23]
  • Perl [24]
  • PHP [25]
  • PL / SQL [26]
  • PowerShell [27]
  • Python [28]
  • Ракетка [29]
  • Раку [30]
  • Рубин [31]
  • Ржавчина [32] [33]
  • Скала [34]
  • Свифт [35]

Уязвимости [ править ]

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

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

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

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

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

См. Также [ править ]

  • Токен доступа

Ссылки [ править ]

  1. ^ a b c d Джонс, Майкл Б.; Брэдли, Брэдли; Сакимура, Сакимура (май 2015 г.). Веб-токен JSON (JWT) . IETF . DOI : 10,17487 / RFC7519 . ISSN 2070-1721 . RFC 7519 . 
  2. ^ Никель, Йохен (2016). Освоение управления идентификацией и доступом с помощью Microsoft Azure . п. 84. ISBN 9781785887888. Проверено 20 июля 2018 года . CS1 maint: обескураженный параметр ( ссылка )
  3. ^ a b «JWT.IO - Введение в веб-токены JSON» . jwt.io . Проверено 20 июля 2018 года . CS1 maint: обескураженный параметр ( ссылка )
  4. ^ Севилья, Крис. «Анатомия веб-токена JSON» . Проверено 8 мая 2015 года . CS1 maint: обескураженный параметр ( ссылка )
  5. ^ «Документация Atlassian Connect» . developer.atlassian.com . Проверено 8 мая 2015 года . CS1 maint: обескураженный параметр ( ссылка )
  6. ^ "draft-ietf-jose-json-web-signature-41 - веб-подпись JSON (JWS)" . tools.ietf.org . Проверено 8 мая 2015 года . CS1 maint: обескураженный параметр ( ссылка )
  7. ^ "draft-ietf-jose-json-web-encryption-40 - веб-шифрование JSON (JWE)" . tools.ietf.org . Проверено 8 мая 2015 года . CS1 maint: обескураженный параметр ( ссылка )
  8. ^ "draft-ietf-jose-json-web-algorithmms-40 - веб-алгоритмы JSON (JWA)" . tools.ietf.org . Проверено 8 мая 2015 года . CS1 maint: обескураженный параметр ( ссылка )
  9. ^ Джонс, Майкл Б.; Брэдли, Брэдли; Сакимура, Сакимура (май 2015 г.). « » Ехр «(Истечение времени) претензии» . Веб-токен JSON (JWT) . IETF . сек. 4.1.4. DOI : 10,17487 / RFC7519 . ISSN 2070-1721 . RFC 7519 . 
  10. ^ a b Маклин, Тим (31 марта 2015 г.). «Критические уязвимости в библиотеках JSON Web Token» . Auth0 . Проверено 29 марта 2016 года . CS1 maint: обескураженный параметр ( ссылка )
  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. ^ "kjur / jsrsasign" . GitHub . Проверено 7 мая 2018 года .
  21. ^ "SkyLothar / lua-resty-jwt" . GitHub . Проверено 7 мая 2018 года .
  22. ^ "jsonwebtoken" . npm . Проверено 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: Реализация веб-токенов JSON в PLSQL. , получено 14 марта 2019 г.
  27. ^ "SP3269 / posh-jwt" . GitHub . Проверено 1 августа 2018 года .
  28. ^ "jpadilla / pyjwt" . GitHub . Проверено 21 марта 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 Бродяги . Проверено 1 августа 2018 года . CS1 maint: обескураженный параметр ( ссылка )
  37. ^ «Распространенные уязвимости безопасности JWT и способы их избежать» . Проверено 14 мая 2018 года .
  38. ^ Андреас, Хаппе. «JWT: Подпись против MAC-атак» . snikt.net . Проверено 27 мая 2019 года . CS1 maint: обескураженный параметр ( ссылка )
  39. ^ Rodarmer, Курт (21 июля 2019). «Неизвестные уязвимости безопасности JWT» . rodarmer.com . Проверено 25 июля 2019 года . CS1 maint: обескураженный параметр ( ссылка )

Внешние ссылки [ править ]

  • RFC  7519
  • jwt.io - специализированный сайт о JWT с инструментами и документацией, поддерживаемый Auth0
  • Spring Boot JWT Auth - интеграция аутентификации JWT с фреймворком Spring
  • JWT Security - электронная книга по безопасности JWT в формате PDF (на польском языке)
  • Зачем нам нужен JWT в современном Интернете - подробная статья по теме с некоторыми историческими соображениями