Mejor tipo de encabezado de autorización HTTP para JWT


228

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

Respuestas:


295

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.


3
¡Gracias! Es bueno ver el origen de esta Bearerpalabra clave. Pero viene de OAuth. Sin embargo, JWT se puede usar sin OAuth. Es totalmente independiente con las especificaciones de OAuth.
Zag zag ..

2
Sí, proviene del protocolo de marco OAuth2, pero se puede usar en cualquier otro contexto. Su servidor es libre de aceptar JWT usando otros encabezados o formas (por ejemplo, en la solicitud del cuerpo o en la cadena de consulta), pero el Authenticateencabezado es más apropiado y cumple con el RFC7235 que describe un marco de autenticación en un contexto HTTP 1.1
Florent Morselli

1
Estoy de acuerdo con Zag zag, un esquema personalizado como "JWT" ​​parece mucho más apropiado que obligar al esquema OAuth2 Bearer a esto.
l8nite

50
Esta debería ser la respuesta aceptada. Citando jwt.io/introduction : "el agente de usuario debe enviar el JWT, generalmente en el encabezado de Autorización utilizando el esquema de Portador. El contenido del encabezado debe ser similar al siguiente: Autorización: Portador <token>"
wrschneider

3
Si ayuda a alguien - Vine aquí buscando este ejemplo: - Solicitud de curl utilizando el esquema Bearer:curl -H "Authorization: Bearer <TOKEN>" <the rest of your curl cmd>
Kevin Friedheim

76

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"

55
Si. Está relacionado con los osos. De la misma manera que Python está relacionado con las serpientes. Duh
Nicholas Hamilton el

44
Osos .. Eso lo hace. Gracias por hacerme el día.
user2501323

¿Es una vulnerabilidad si: le doy al usuario el token, pero cuando quiere enviarme una solicitud, debe devolver el token en el cuerpo de la solicitud? Entonces lo obtendré desde allí y validaré. Realmente no tengo otras opciones, ya que la forma en que envían la solicitud no está definida por mí, pero me interesaría si eso es malo o si hay una solución para hacerlo más seguro.
Daniel Jeney
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.