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

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

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

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

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

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

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

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Спасибо.

Edit:

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

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Ответ 1

A токен JWT может использоваться без OAuth.

Таким образом, проще "Authorization: JWT <your_token>".

Пример:

curl -H "Authorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" https://api.domain.tld/me/account

Ответ 2

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

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

Пример:

GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ

Если вам нужна более надежная защита, вы можете также рассмотреть следующий проект 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), поэтому неприменимо в этом контексте.

Ответ 3

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

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

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

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

Ошибаешься... нет :)

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

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

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

Человек, который представляет чек или другой приказ, чтобы заплатить деньги.

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

А вот определение токена на предъявителя согласно 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"