Найкращий тип заголовка авторизації HTTP для JWT

Мені цікаво, що найкраще підходить 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

Найкращий заголовок 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 ), тому не застосовуються в цьому контексті.

Коротка відповідь

Схема 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-аутентифікатора

Якщо запит на захищений ресурс не включає в себе облікові дані автентифікації або не містить маркер доступу, який дозволяє отримати доступ до захищеного ресурсу, сервер ресурсів ОБОВ'ЯЗКОВО включає HTTP WWW-Authenticate поле заголовка відповіді [...].

Усі завдання, визначені цією специфікацією, ОБОВ'ЯЗКОВО використовувати значення схеми auth-схеми 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"