http-headers - cabecera - jwt token header
El mejor tipo de encabezado de autorización HTTP para JWT (2)
Respuesta corta
El esquema de autenticación de
Bearer
es lo que está 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
Una persona o cosa que lleva o sostiene algo.
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 RFC6750 :
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 esquema de autenticación de
Bearer
está
registrado en IANA
y se definió originalmente en el
RFC6750
para el marco de autorización de OAuth 2.0, pero nada le impide usar el esquema de
Bearer
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 encabezado de solicitud de
Authorization
utilizando el esquema de autenticación de
Bearer
:
2.1. Campo de encabezado de solicitud de autorización
Al enviar el token de acceso en el campo de encabezado de solicitud de
Authorizationdefinido por HTTP / 1.1, el cliente utiliza el esquema de autenticación deBearerpara 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 DEBEN realizar solicitudes autenticadas con un token de portador utilizando el campo de encabezado de solicitud de
Authorizationcon el esquema de autorización HTTP deBearer. [...]
En caso de token no válido o faltante, el esquema de
Bearer
debe incluirse en el encabezado de la respuesta de
WWW-Authenticate
3. El campo de encabezado de respuesta WWW-Authenticate
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 campo de encabezado de respuesta HTTP
WWW-Authenticate[...].Todos los desafíos definidos por esta especificación DEBEN usar el
Bearervalor del esquema de autenticación. 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"
Me pregunto cuál es el tipo de encabezado HTTP de
Authorization
más adecuado para los
tokens JWT
.
Uno de los tipos probablemente más populares 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 encabezado de
Authorization
HTTP?
¿Deberíamos usar
Bearer
, o deberíamos simplificar y simplemente usar:
Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Gracias.
Editar:
O tal vez, solo un encabezado
JWT
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 encabezado de
Authorization
con el esquema de autenticación de
Bearer
.
Este esquema es descrito por el RFC6750 .
Ejemplo:
GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ
Si necesita una protección de seguridad más fuerte, 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 esquema
JWT
personalizado que menciona en su pregunta,
el
Bearer
está registrado en la IANA
.
Con respecto a los esquemas de autenticación
Basic
y
Digest
, están dedicados a la autenticación utilizando un nombre de usuario y un secreto (ver
RFC7616
y
RFC7617
), por lo que no son aplicables en ese contexto.