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


171

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.


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? Los tokens de acceso se emiten a través de puntos finales OAuth 2.0 de Auth0: / authorize y / oauth / token. Puede usar cualquier biblioteca compatible con OAuth 2.0 para obtener tokens de acceso. Si aún no tiene una biblioteca OAuth 2.0 preferida, Auth0 proporciona bibliotecas para muchos idiomas y marcos.
Bharathkumar V

Respuestas:


146

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 noreply@example.com, 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.


2
El token @ Xavier Egea Bearer es básicamente su token de actualización y no el token de acceso.
Akhil Nambiar

13
El token de portador no significa que sea un token de actualización @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1
Suman Kundu

9
El primer párrafo implica que un token de portador es un token de actualización y no un token de acceso. Este no es el caso. De la especificación de token de portador "Esta especificación describe cómo realizar solicitudes de recursos protegidos cuando el token de acceso OAuth es un token de portador". RFC6750
Daniel

8
Después de leer la respuesta, también pensé que el token de portador y los tokens de actualización son lo mismo. La respuesta debe actualizarse para aclarar esto.
KurioZ7

2
Esta respuesta es muy engañosa. Los tokens de portador NO son tokens de actualización, como dice la declaración inicial de esta respuesta. Por favor corrige.
think01

67

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.


2
No entiendo esta parte: "Una vez que el Servidor de autorización reciba 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". ¿No es el servidor de autorización el que otorga el token de acceso, no lo recibe? Estoy tratando de entender este tema y muchos ejemplos hacen una clara distinción entre el servidor de autorización y el servidor de recursos. Lo que he entendido es que obtienes el token de acceso del servidor de autorización y luego lo pasas junto con cada solicitud que haces al servidor de recursos.
kivikall

1
@kivikall Tienes razón. Lo he cambiado en la respuesta. El servidor de recursos recibe el token (el token que el servidor de autorización ha cifrado en el proceso de creación del token) en cada solicitud y lo descifra.
Xavier Egea

1
@kivikall En realidad, descifrar un token debe ser algo relacionado con la autorización, por lo que debe pertenecer al Servidor de autorización. Es por eso que lo escribió en la respuesta. Pero en la práctica, esto significaría que en cada solicitud debe validar con el Servidor de autorización el token recibido (tal vez realizar otra solicitud). Por lo tanto, para evitar la pérdida de rendimiento, es mejor dar algunas de las funcionalidades para descifrar el token en el servidor de recursos. Consulte el siguiente enlace: stackoverflow.com/questions/12296017/…
Xavier Egea

Pero en cada solicitud, el servidor de recursos debe verificar si el AccessToken proporcionado es válido en el servidor de autorización. Entonces, si un rol cambia, el cambio puede ser reflejado inmediatamente por el servidor de autenticación, ¿verdad? Además, ¿por qué eliminaríamos el RefreshToken si el AccessToken estuviera comprometido? RefreshToken no se puede calcular en función de AccessToken, por lo que cuando caduca, el pirata informático se bloquea nuevamente.
mandarín

Como dije, el token de acceso contiene información del usuario, como el rol. Si un rol de usuario cambia, este cambio se reflejará en el siguiente token cuando caduque el token actual. Esto significa que en un corto período de tiempo (hasta el vencimiento del token de acceso) el usuario mantendrá la misma función y el servidor de autenticación lo permitirá porque el token aún es válido. Con respecto a la segunda pregunta, eliminar un token de actualización hace que el usuario vuelva a insertar sus credenciales. Esto es lo que queremos si se compila un token de acceso. En otro caso, se puede autorizar a un pirata informático hasta el vencimiento de la actualización (por ejemplo, 1 mes)
Xavier Egea

8

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


No estás explicando en absoluto el propósito de las fichas de portador.
Jaime Hablutzel
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.