Mejor tipo de encabezado de autorización HTTP para JWT

Me pregunto cuál es el Authorizationtipo de encabezado HTTP más adecuado para los tokens JWT .

Uno del tipo probablemente más popular es Basic. Por ejemplo:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Maneja dos parámetros, como un inicio de sesión y una contraseña. Por lo tanto, no es relevante para los tokens JWT.

Además, escuché sobre el tipo de portador , por ejemplo:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Sin embargo, no sé su significado. ¿Está relacionado con los osos?

¿Hay alguna forma particular de usar tokens JWT en el Authorizationencabezado HTTP ? ¿Deberíamos usar Bearer, o deberíamos simplificar y simplemente usar:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Gracias.

Editar:

O tal vez, solo un JWTencabezado HTTP:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

El mejor encabezado HTTP para que su cliente envíe un token de acceso (JWT o cualquier otro token) es el Authorizationencabezado con el Beareresquema de autenticación.

Este esquema es descrito por el RFC6750 .

Ejemplo:

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

Si necesita una protección de seguridad más sólida, también puede considerar el siguiente borrador de IETF: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture . Este borrador parece ser una buena alternativa al https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac (¿abandonado?) .

Tenga en cuenta que incluso si este RFC y las especificaciones anteriores están relacionadas con el protocolo OAuth2 Framework, se pueden usar en cualquier otro contexto que requiera un intercambio de tokens entre un cliente y un servidor.

A diferencia del JWTesquema personalizado que menciona en su pregunta, el Bearerque está registrado en la IANA .

En cuanto a los esquemas de autenticación Basicy Digest, están dedicados a la autenticación utilizando un nombre de usuario y un secreto (consulte RFC7616 y RFC7617 ), por lo que no son aplicables en ese contexto.

Respuesta corta

El Beareresquema de autenticación es lo que estás buscando.

Respuesta larga

¿Está relacionado con los osos?

Errr ... No :)

Según los Diccionarios de Oxford , aquí está la definición de portador :

portador _{^{/ ˈbɛːrə /}}
sustantivo

1. Una persona o cosa que lleva o sostiene algo.

2. Una persona que presenta un cheque u otra orden para pagar dinero.

La primera definición incluye los siguientes sinónimos: mensajero , agente , transportador , emisario , transportista , proveedor .

Y aquí está la definición de token de portador de acuerdo con RFC 6750 :

1.2. Terminología

Token al portador

Una ficha de seguridad con la propiedad de que cualquier parte en posesión de la ficha (un "portador") puede usar la ficha de cualquier manera que cualquier otra parte en posesión de ella pueda. El uso de un token de portador no requiere que un portador demuestre la posesión de material de clave criptográfica (prueba de posesión).

El Beareresquema de autenticación está registrado en IANA y se definió originalmente en el RFC 6750 para el marco de autorización de OAuth 2.0, pero nada le impide usar el Beareresquema para tokens de acceso en aplicaciones que no usan OAuth 2.0.

Cumpla con los estándares tanto como pueda y no cree sus propios esquemas de autenticación.

Se debe enviar un token de acceso en el Authorizationencabezado de la solicitud utilizando el Beareresquema de autenticación:

2.1. Campo de encabezado de solicitud de autorización

Al enviar el token de acceso en el Authorizationcampo de encabezado de solicitud definido por HTTP / 1.1, el cliente utiliza el Beareresquema de autenticación para transmitir el token de acceso.

Por ejemplo:

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

[...]

Los clientes DEBERÍAN realizar solicitudes autenticadas con un token de portador utilizando el Authorizationcampo de encabezado de solicitud con el Beareresquema de autorización HTTP. [...]

En caso de token no válido o faltante, el Beareresquema debe incluirse en el WWW-Authenticateencabezado de respuesta:

3. El campo de encabezado de respuesta de autenticación de WWW

Si la solicitud de recurso protegido no incluye credenciales de autenticación o no contiene un token de acceso que permita el acceso al recurso protegido, el servidor de recursos DEBE incluir el WWW-Authenticatecampo de encabezado de respuesta HTTP [...].

Todos los desafíos definidos por esta especificación DEBEN usar el valor del esquema de autenticación Bearer. Este esquema DEBE ser seguido por uno o más valores de auth-param. [...]

Por ejemplo, en respuesta a una solicitud de recurso protegido sin autenticación:

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

Y en respuesta a una solicitud de recurso protegido con un intento de autenticación utilizando un token de acceso caducado:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"