stringtranslate.com

Веб-токен JSON

Веб-токен 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] Обычно также включаются пользовательские утверждения, в зависимости от назначения токена.
В этом примере имеется стандартное утверждение «Выдано во время» ( iat) и пользовательское утверждение ( loggedInAs).
{ "loggedInAs" : "admin" , "iat" : 1422779638 }
Подпись
Надежно проверяет токен. Подпись рассчитывается путем кодирования заголовка и полезных данных с использованием кодировки Base64url RFC  4648 и их объединения с помощью разделителя точки. Затем эта строка обрабатывается криптографическим алгоритмом, указанным в заголовке. В этом примере используется HMAC-SHA256 с общим секретом (также определены алгоритмы открытого ключа). Кодировка Base64url аналогична кодировке base64 , но использует другие небуквенно-цифровые символы и не содержит дополнений.
HMAC_SHA256 ( секрет , base64urlEncoding ( заголовок ) + '.' + base64urlEncoding ( полезная нагрузка ) )

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

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

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

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

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

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

POST /oauth2/token Тип контента: приложение / x-www-form-urlencoded Grant_type = urn:ietf:params:oauth:grant-type:jwt-bearer & Assertion = eyJhb...

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

{ "access_token" : "eyJhb..." , "token_type" : "Носитель" , "expires_in" : 3600 }

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

Авторизация: Носитель eyJhbGci ...<snip>... yu5CSpyHI

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

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

Реализации

Реализации 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. ^ abcd Джонс, Майкл Б.; Брэдли, Брэдли; Сакимура, Сакимура (май 2015 г.). Веб-токен JSON (JWT). IETF . дои : 10.17487/RFC7519 . ISSN  2070-1721. РФК 7519.
  2. ^ Никель, Йохен (2016). Освоение управления идентификацией и доступом с помощью Microsoft Azure. п. 84. ИСБН 9781785887888. Проверено 20 июля 2018 г.
  3. ^ ab «JWT.IO — Введение в веб-токены JSON». jwt.io. _ Проверено 20 июля 2018 г.
  4. ^ Севилья, Крис. «Анатомия веб-токена JSON» . Проверено 8 мая 2015 г.
  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. ^ "golang-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/posh-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 г.