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

228

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

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

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

Кроме того, я слышал о типе носителя , например:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

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

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Спасибо.

Редактировать:

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

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Заг заг ..
источник

Ответы:

295

Лучшим 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схемы вы упоминаете в своем вопросе, один зарегистрирован в IANA .Bearer

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

Флоран Морселли
источник
3
Спасибо! Приятно видеть происхождение этого Bearerключевого слова. Но это исходит от OAuth. Однако JWT можно использовать без OAuth. Он полностью независим от спецификаций OAuth.
Заг заг ..
2
Да, он взят из протоколя OAuth2, но может использоваться в любом другом контексте. Ваш сервер может принимать JWT, используя другие заголовки или способы (например, в запросе тела или в строке запроса), но Authenticateзаголовок более уместен и соответствует RFC7235, который описывает структуру аутентификации в контексте HTTP 1.1
Florent Morselli
1
Я согласен с Zag Zag, пользовательская схема, такая как "JWT", кажется более подходящей, чем принуждение схемы OAuth2 Bearer к этому.
18
50
Это должен быть принятый ответ. Цитата jwt.io/introduction : «пользовательский агент должен отправлять JWT, обычно в заголовке авторизации, используя схему Bearer. Содержимое заголовка должно выглядеть следующим образом: Authorization: Bearer <token>»
wrschneider
3
Если это кому-то поможет - я пришел сюда в поисках этого примера: - запрос завитка по схеме Bearer:curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd>
Кевин Фридхайм
76

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

Схема 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

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

Все вызовы, определенные в этой спецификации, ДОЛЖНЫ использовать значение схемы аутентификации 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"
cassiomolin
источник
5
Да. Это связано с медведями. Точно так же, как питон относится к змеям. Duh.
Николас Гамильтон
4
Медведи .. Это делает это. Спасибо, что сделали мой день.
user2501323
Является ли это уязвимостью, если: я даю пользователю токен, но когда он хочет отправить мне запрос, он должен отправить токен обратно в теле запроса? Я тогда получу это оттуда и проверим? У меня действительно нет других вариантов, так как способ отправки запроса не определен мной, но мне было бы интересно, если это плохо или если есть решение, чтобы сделать его более безопасным.
Даниэль Джени