bearer - ¿Qué es exactamente el Token de portador OAuth 2.0?
bearer token vs jwt (3)
De acuerdo con RFC6750 -El Marco de Autorización OAuth 2.0: Uso del Token Portador, el token del portador es:
Una ficha de seguridad con la propiedad de que cualquier parte en posesión del token (un "portador") puede usar el token de cualquier forma que pueda hacerlo cualquier otra parte en posesión del mismo.
Para mí, esta definición es vaga y no puedo encontrar ninguna especificación.
- Supongamos que estoy implementando un proveedor de autorización, ¿puedo suministrar cualquier tipo de cadena para el token de portador?
- ¿Puede ser una cadena aleatoria?
- ¿Tiene que ser una codificación base64 de algunos atributos?
¿Debería ser hash? - ¿Y el proveedor del servicio necesita consultar al proveedor de autorización para validar este token?
Gracias por cualquier puntero.
Token portador
Una ficha de seguridad con la propiedad de que cualquier parte en posesión del token (un "portador") puede usar el token de cualquier forma que pueda hacerlo cualquier otra parte en posesión del mismo. El uso de un token de portador no requiere que el portador demuestre la posesión de material de clave criptográfica (prueba de posesión).
El token de portador o token de actualización lo ha creado el servidor de autenticación. Cuando un usuario autentica su aplicación (cliente), el servidor de autenticación ejecuta y genera un token de portador (token de actualización) que puede usar para obtener un token de acceso.
El token de portador normalmente es algún tipo de valor secreto creado por el servidor de autenticación. No es aleatorio; se crea en función del usuario que le da acceso y del cliente al que accede la aplicación.
Para acceder a una API, por ejemplo, debe usar un token de acceso. Los tokens de acceso son de corta duración (alrededor de una hora). Utiliza el token de portador para obtener un nuevo token de acceso. Para obtener un token de acceso, envíe el servidor de autenticación este token de portador junto con su ID de cliente. De esta forma, el servidor sabe que la aplicación que utiliza el token de portador es la misma aplicación para la que se creó el token de portador. Ejemplo: No puedo simplemente tomar un token de portador creado para su aplicación y usarlo con mi aplicación; no funcionará porque no se generó para mí.
El token de actualización de Google se ve así: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM
copiado del comentario: no creo que haya ninguna restricción en los tokens portadores que suministra. Lo único que se me ocurre es que es bueno permitir más de uno. Por ejemplo, un usuario puede autenticar la aplicación hasta 30 veces y los tokens del viejo portador seguirán funcionando. Ah, y si uno no se ha utilizado durante, digamos, 6 meses, lo eliminaría de su sistema. Es su servidor de autenticación el que tendrá que generarlos y validarlos, de modo que la forma en que se formatee depende de usted.
Actualizar:
Un token de portador se establece en el encabezado de autorización de cada solicitud HTTP de acción en línea. Por ejemplo:
POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)
rsvpStatus=YES
La cadena "AbCdEf123456" en el ejemplo anterior es el token de autorización de portador. Este es un token criptográfico producido por el servidor de autenticación. Todos los tokens de portador enviados con acciones tienen el campo de problema, y el campo de audiencia especifica el dominio de remitente como una URL del formulario https: //. Por ejemplo, si el correo electrónico es de [email protected], la audiencia es https://example.com .
Si utiliza tokens de portador, verifique que la solicitud provenga del servidor de autenticación y esté destinada al dominio emisor. Si el token no se verifica, el servicio debe responder a la solicitud con un código de respuesta HTTP 401 (no autorizado).
Los tokens de portador son parte del estándar OAuth V2 y son ampliamente adoptados por muchas API.
Mientras leo su pregunta, he intentado sin éxito buscar en Internet cómo se codifican o firman los tokens de portador. Supongo que los tokens de portador no son hash (quizás parcialmente, pero no completamente) porque en ese caso no será posible descifrarlo y recuperar las propiedades de los usuarios.
Pero su pregunta parece estar intentando encontrar respuestas en la funcionalidad del token de portador:
Supongamos que estoy implementando un proveedor de autorización, ¿puedo suministrar cualquier tipo de cadena para el token de portador? ¿Puede ser una cadena aleatoria? ¿Tiene que ser una codificación base64 de algunos atributos? ¿Debería ser hash?
Por lo tanto, intentaré explicar cómo funcionan los tokens de portador y los tokens de actualización:
Cuando el usuario solicita al servidor un token que envía el usuario y la contraseña a través de SSL, el servidor devuelve dos cosas: un token de acceso y un token de actualización .
El token de acceso es un token de portador que deberá agregar en todos los encabezados de solicitud para autenticarse como un usuario concreto.
Authorization: Bearer <access_token>
El token de acceso es una cadena encriptada con todas las propiedades, reclamos y roles del usuario que desee. (Puede verificar que el tamaño de un token aumente si agrega más roles o reclamos). Una vez que el Servidor de Recursos recibe un token de acceso, podrá descifrarlo y leer estas propiedades de usuario. De esta forma, el usuario será validado y otorgado a lo largo de toda la aplicación.
Los tokens de acceso tienen una caducidad corta (es decir, 30 minutos). Si los tokens de acceso tienen una larga caducidad, sería un problema, porque teóricamente no hay posibilidad de revocarlo. Imagine un usuario con un rol = "Administrador" que cambie a "Usuario". Si un usuario conserva el antiguo token con role = "Admin", podrá acceder hasta la caducidad del token con los derechos de administrador. Es por eso que el token de acceso tiene una caducidad corta.
Pero, un problema viene en mente. Si el token de acceso tiene una caducidad breve, debemos enviar cada período corto de usuario y contraseña. ¿Esto es seguro? No, no lo es. Deberíamos evitarlo. Entonces es cuando los tokens de actualización parecen resolver este problema.
Los tokens de actualización se almacenan en DB y tendrán una larga caducidad (ejemplo: 1 mes).
Un usuario puede obtener un nuevo token de acceso (cuando caduca, cada 30 minutos, por ejemplo) utilizando un token de actualización, que el usuario había recibido en la primera solicitud de token. Cuando un token de acceso caduca, el cliente debe enviar un token de actualización. Si este token de actualización existe en DB, el servidor devolverá al cliente un nuevo token de acceso y otro token de actualización (y reemplazará el token de actualización anterior por el nuevo).
En caso de que un token de acceso del usuario haya sido comprometido, el token de actualización de ese usuario debe eliminarse de DB. De esta forma, el token solo será válido hasta que caduque el token de acceso, porque cuando el pirata informático intente obtener un nuevo token de acceso enviando el token de actualización, esta acción será denegada.
Token de portador es una o más repeticiones de alfabeto, dígito, "-", "." , "_", "~", "+", "/" seguidos por 0 o más "=".
RFC 6750 2.1. Campo de encabezado de solicitud de autorización (el formato es ABNF (BNF aumentado))
The syntax for Bearer credentials is as follows:
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
Se parece a Base64 pero de acuerdo con ¿Debería el token del encabezado estar codificado en base64? , no lo es.
Profundizando un poco más en "HTTP / 1.1, parte 7: Autenticación" **, sin embargo, veo que b64token es solo una definición de sintaxis ABNF que permite caracteres normalmente utilizados en base64, base64url, etc. Así que el b64token no define cualquier codificación o descodificación, sino que simplemente define qué caracteres se pueden usar en la parte del encabezado Authorization que contendrá el token de acceso.