Лучший тип заголовка HTTP-авторизации для JWT

Мне интересно, какой тип Authorization HTTP-заголовка лучше всего подходит для токенов JWT.

Один из, вероятно, самых популярных типов - Basic. Например:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Он обрабатывает два параметра, такие как логин и пароль. Так что для токенов JWT это не актуально.

Также я слышал о типе Bearer, например:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Однако я не знаю его значения. Это связано с медведями?

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

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Спасибо.

Изменить:

Или, может быть, просто HTTP-заголовок JWT:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

jwt http-headers
person Zag zag..    schedule 21.10.2015    source источник

Ответы (2)


arrow_upward
347
arrow_downward

Лучшим HTTP-заголовком для вашего клиента для отправки токена доступа (JWT или любого другого токена) является заголовок Authorization со схемой аутентификации Bearer.

Эта схема описана в RFC6750.

Пример:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

Если вам нужна более надежная защита, вы также можете рассмотреть следующий проект IETF: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture. Этот черновик кажется хорошей альтернативой (заброшенному?) https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac.

Обратите внимание, что даже если этот RFC и приведенные выше спецификации относятся к протоколу OAuth2 Framework, их можно использовать в любых других контекстах, требующих обмена токенами между клиентом и сервером.

В отличие от пользовательской схемы JWT, которую вы упомянули в своем вопросе, Bearer зарегистрирована по адресу IANA.

Что касается схем аутентификации Basic и Digest, они предназначены для аутентификации с использованием имени пользователя и секрета (см. RFC7616 и RFC7617), поэтому неприменимо в этом контексте.

person Spomky-Labs    schedule 22.10.2015
comment
Спасибо! Приятно видеть происхождение этого Bearer ключевого слова. Но это исходит от OAuth. Однако JWT можно использовать без OAuth. Это полностью не зависит от спецификаций OAuth. - person Zag zag..; 23.10.2015
comment
Да, это происходит из протоколов фреймворка OAuth2, но может использоваться в любом другом контексте. Ваш сервер может принимать JWT с использованием других заголовков или способов (например, в теле запроса или в строке запроса), но заголовок Authenticate более уместен и соответствует RFC7235, который описывает структуру аутентификации в контексте HTTP 1.1. - person Spomky-Labs; 23.10.2015
comment
Я согласен с Zag zag, настраиваемая схема, такая как JWT, кажется более подходящей, чем принуждение схемы OAuth2 Bearer к этому. - person l8nite; 03.12.2015
comment
Это должен быть принятый ответ. Цитата jwt.io/introduction: пользовательский агент должен отправлять JWT, обычно в заголовке авторизации с использованием Bearer схема. Содержание заголовка должно выглядеть следующим образом: Авторизация: Bearer ‹token› - person wrschneider; 21.07.2016
comment
Если это кому-то поможет - я пришел сюда в поисках этого примера: - запрос curl с использованием схемы Bearer: curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd> - person Kevin Friedheim; 07.06.2017
comment
Это правильный ответ, и он должен быть отмечен как принятый, ответ, отмеченный как принятый, был явно отмечен, поскольку он быстро решил проблему OP, однако с точки зрения JWT это очень и очень плохой совет, однако этот ответ является правильным. - person shawty; 01.09.2017

arrow_upward
97
arrow_downward

Короткий ответ

Схема аутентификации Bearer - это то, что вы ищете.

Длинный ответ

Это связано с медведями?

Эээ ... Нет :)

Согласно Оксфордским словарям, вот определение носителя:

предъявитель / ˈbɛːrə /
существительное

  1. Человек или вещь, которая что-то несет или держит.

  2. Лицо, предъявившее чек или иное распоряжение о выплате денег.

Первое определение включает следующие синонимы: мессенджер, агент, конвейер, посланник, перевозчик , поставщик.

А вот определение токена на предъявителя в соответствии с RFC 6750:

1.2. Терминология

Жетон на предъявителя

Маркер безопасности со свойством, что любая сторона, владеющая токеном («предъявитель»), может использовать токен любым способом, который может использовать любая другая сторона, владеющая им. Использование токена на предъявителя не требует от предъявителя доказательства владения материалом криптографического ключа (доказательство владения).

Bearer Схема аутентификации зарегистрирована в IANA и изначально определена в RFC 6750 для инфраструктуры авторизации OAuth 2.0, но ничто не мешает вам использовать схему Bearer для токенов доступа в приложениях, которые не используют OAuth 2.0.

По возможности придерживайтесь стандартов и не создавайте собственных схем аутентификации.

Маркер доступа должен быть отправлен в заголовке запроса Authorization с использованием схемы аутентификации Bearer:

2.1. Поле заголовка запроса авторизации

При отправке токена доступа в поле заголовка запроса Authorization, определенном HTTP / 1.1, клиент использует схему аутентификации Bearer для передачи токена доступа.

Например:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[...]

Клиенты ДОЛЖНЫ выполнять аутентифицированные запросы с токеном носителя, используя поле заголовка запроса Authorization со схемой авторизации Bearer HTTP. [...]

В случае недействительного или отсутствующего токена схема Bearer должна быть включена в WWW-Authenticate заголовок ответа:

3. Поле заголовка ответа WWW-Authenticate

Если запрос защищенного ресурса не включает учетные данные аутентификации или не содержит токен доступа, который разрешает доступ к защищенному ресурсу, сервер ресурсов ДОЛЖЕН включать поле заголовка HTTP WWW-Authenticate ответа [...].

Все вызовы, определенные в этой спецификации, ДОЛЖНЫ использовать значение схемы аутентификации Bearer. Эта схема ДОЛЖНА сопровождаться одним или несколькими значениями auth-param. [...].

Например, в ответ на запрос защищенного ресурса без аутентификации:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

И в ответ на запрос защищенного ресурса с попыткой аутентификации с использованием просроченного токена доступа:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"
person cassiomolin    schedule 07.11.2017
comment
да. Это связано с медведями. Точно так же питон связан со змеями. Ага. - person Nicholas Hamilton; 13.08.2019
comment
Медведи .. Вот и все. Спасибо, что сделали мой день. - person user2501323; 20.08.2019
comment
Является ли это уязвимостью, если: я даю пользователю токен, но когда он хочет отправить мне запрос, он должен отправить токен обратно в теле запроса? Я получу его оттуда и проверю? У меня действительно нет других вариантов, так как способ отправки запроса не определен мной, но мне было бы интересно, плохо ли это или есть решение, чтобы сделать его более безопасным. - person Daniel Jeney; 04.02.2020
comment
@DanielJeney ты нашел ответ? - person vikrant; 29.07.2020
comment
Медведи. Свекла. Battlestar Galactica. - person Vitor Braga; 25.09.2020