¿Qué es exactamente el token de portador de OAuth 2.0?

De acuerdo con RFC6750 -El marco de autorización de OAuth 2.0: uso de token de portador, el token de portador es:

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.

Para mí, esta definición es vaga y no puedo encontrar ninguna especificación.

• Supongamos que estoy implementando un proveedor de autorización, ¿puedo proporcionar algún 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 de servicios necesita consultar al proveedor de autorización para validar este token?

Gracias por cualquier puntero.

Token de portador
Un token de seguridad con la propiedad de que cualquier parte en posesión del token (un "portador") puede usar el token de cualquier manera que cualquier otra parte que lo posea 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 servidor de autenticación crea el token de portador para usted. Cuando un usuario autentica su aplicación (cliente), el servidor de autenticación va y genera un Token para usted. Los tokens de portador son el tipo predominante de token de acceso utilizado con OAuth 2.0. Un token de portador básicamente dice "Dar acceso al portador de este token".

El token de portador es normalmente algún tipo de valor opaco creado por el servidor de autenticación. No es al azar; se crea según el usuario que le da acceso y el cliente al que accede su 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 portador para obtener un nuevo token de acceso. Para obtener un token de acceso, envíe al servidor de autenticación este token de portador junto con su ID de cliente. De esta manera, el servidor sabe que la aplicación que usa 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 parece a esto: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

copiado del comentario: no creo que haya ninguna restricción en las fichas de portador que proporcione. 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 de soporte antiguos seguirán funcionando. Ah, y si uno no se ha utilizado durante unos 6 meses, lo eliminaría de su sistema. Es su servidor de autenticación el que tendrá que generarlos y validarlos, por lo que depende de usted cómo está formateado.

Actualizar:

Se establece un token de portador 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, con el campo de audiencia que especifica el dominio del 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 usa tokens de portador, verifique que la solicitud provenga del servidor de autenticación y que esté destinada al dominio del remitente. 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 leía su pregunta, he intentado sin éxito buscar en Internet cómo se cifran o firman los tokens de portador. Supongo que los tokens de portador no están codificados (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 tratando de encontrar respuestas sobre la funcionalidad del token Bearer:

Supongamos que estoy implementando un proveedor de autorización, ¿puedo proporcionar algún 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 un usuario y una contraseña a través de SSL, el servidor devuelve dos cosas: un token de acceso y un token de actualización .

Un 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>

Un token de acceso es una cadena encriptada con todas las propiedades de usuario, reclamos y roles que desee. (Puede verificar que el tamaño de un token aumenta 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 del usuario. De esta manera, el usuario será validado y otorgado junto con toda la aplicación.

Los tokens de acceso tienen un vencimiento breve (es decir, 30 minutos). Si los tokens de acceso tuvieran un vencimiento prolongado, sería un problema, porque teóricamente no hay posibilidad de revocarlo. Así que imagine un usuario con un rol = "Administrador" que cambia a "Usuario". Si un usuario mantiene el token anterior con role = "Admin", podrá acceder hasta el vencimiento del token con derechos de administrador. Es por eso que los tokens de acceso tienen una breve caducidad.

Pero, un tema viene a la mente. Si un token de acceso tiene un vencimiento breve, tenemos que enviarle cada usuario y contraseña cada breve período. ¿Es esto seguro? No lo es. Deberíamos evitarlo. Ahí es cuando los tokens de actualización parecen resolver este problema.

Los tokens de actualización se almacenan en la base de datos y tendrán un vencimiento prolongado (por ejemplo, 1 mes).

Un usuario puede obtener un nuevo token de acceso (cuando caduca, por ejemplo, cada 30 minutos) utilizando un token de actualización, que el usuario recibió en la primera solicitud de un token. Cuando caduca un token de acceso, el cliente debe enviar un token de actualización. Si este token de actualización existe en la base de datos, 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 de usuario se haya visto comprometido, el token de actualización de ese usuario debe eliminarse de la base de datos. De esta manera, el token será válido solo hasta que el token de acceso caduque porque cuando el hacker intente obtener un nuevo token de acceso enviando el token de actualización, esta acción será denegada.

El token de portador es una o más repeticiones de alfabeto, dígito, "-", "". , "_", "~", "+", "/" seguido de 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

Parece Base64 pero de acuerdo con ¿Debería el token en el 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 típicamente utilizados en base64, base64url, etc. Así que el b64token no define cualquier codificación o decodificación, sino que simplemente define qué caracteres se pueden usar en la parte del encabezado de Autorización que contendrá el token de acceso.

Referencias

• RFC 5234 3.6. Repetición Variable: * Regla
• RFC 2616 2.1 BNF aumentado