¿Qué es exactamente el token de portador de OAuth 2.0?
Según RFC6750 - Marco de autorización de OAuth 2.0: uso del token de portador, el token de portador es:
Un token de seguridad con la propiedad de que cualquier parte en posesión del token (un "portador") puede utilizar el token de cualquier manera que cualquier otra parte en posesión del mismo pueda hacerlo.
Para mí esta definición es vaga y no encuentro ninguna especificación.
- Supongamos que estoy implementando un proveedor de autorización, ¿puedo proporcionar algún tipo de cadena para el token al 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?
Token de portador
Un token de seguridad con la propiedad de que cualquier parte en posesión del token (un "portador") puede utilizar el token de cualquier manera que cualquier otra parte en posesión del mismo pueda hacerlo. El uso de un token al portador no requiere que el portador demuestre la posesión de material de clave criptográfica (prueba de posesión).
El token de portador lo crea el servidor de autenticación. Cuando un usuario autentica su aplicación (cliente), el servidor de autenticación 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 al portador normalmente es algún tipo de valor opaco creado por el servidor de autenticación. No es aleatorio; se crea en función del usuario que le otorga acceso y del cliente que obtiene acceso a su aplicación.
Para acceder a una API, por ejemplo, necesita utilizar un token de acceso. Los tokens de acceso duran poco (alrededor de una hora). Utiliza el token de 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 identificación de cliente. De esta manera, 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 parece a esto: 1/mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM
Copiado del comentario: No creo que haya restricciones sobre los tokens al portador que proporciona. 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 portador antiguos 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, por lo que el formato depende de usted.
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"del ejemplo anterior es el token de autorización del 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 del remitente como una URL con el formato 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 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, intenté sin éxito buscar en Internet cómo se cifran o firman los tokens de portador. Supongo que los tokens de portador no tienen hash (tal vez parcialmente, pero no completamente) porque, en ese caso, no será posible descifrarlos y recuperar las propiedades de los usuarios.
Pero su pregunta parece intentar encontrar respuestas sobre la funcionalidad del token de portador:
Supongamos que estoy implementando un proveedor de autorización, ¿puedo proporcionar algún tipo de cadena para el token al portador? ¿Puede ser una cadena aleatoria? ¿Tiene que ser una codificación base64 de algunos atributos? ¿Debería ser hash?
Entonces, 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 usuario y 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 cifrada con todas las propiedades, reclamos y roles de usuario que desee. (Puedes comprobar que el tamaño de un token aumenta si agregas más roles o reclamos). Una vez que el servidor de recursos reciba un token de acceso, podrá descifrarlo y leer estas propiedades de usuario. De esta forma, el usuario quedará validado y otorgado junto con toda la solicitud.
Los tokens de acceso tienen una caducidad corta (es decir, 30 minutos). Si los tokens de acceso tuvieran una caducidad larga sería un problema, porque teóricamente no hay posibilidad de revocarlos. Imaginemos un usuario con un rol = "Administrador" que cambia a "Usuario". Si un usuario conserva el token anterior con el rol="Admin", podrá acceder hasta que expire el token con derechos de administrador. Es por eso que los tokens de acceso tienen una caducidad corta.
Pero me viene a la mente una cuestión. Si un token de acceso tiene una caducidad corta, debemos enviar cada breve período el usuario y la contraseña. ¿Es esto seguro? No, no lo es. Deberíamos evitarlo. Ahí es cuando aparecen los tokens de actualización para resolver este problema.
Los tokens de actualización se almacenan en la base de datos y tendrán una caducidad prolongada (ejemplo: 1 mes).
Un usuario puede obtener un nuevo token de acceso (cuando caduque, cada 30 minutos, por ejemplo) utilizando un token de actualización que el usuario recibió en la primera solicitud de un token. Cuando un token de acceso caduca, 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 uno nuevo).
En caso de que el token de acceso de un 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 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.
El token al portador es una o más repeticiones del 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 según ¿Debería el token en el encabezado estar codificado en base64? , No lo es.
Sin embargo, al profundizar un poco más en "HTTP/1.1, parte 7: Autenticación"**, veo que b64token es solo una definición de sintaxis ABNF que permite caracteres utilizados normalmente en base64, base64url, etc. Por lo tanto, 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.
Esto aborda completamente los primeros 3 elementos de la lista de preguntas OP. Así que estoy ampliando esta respuesta para abordar la cuarta pregunta, sobre si el token debe validarse, por lo que @mon no dude en eliminarlo o editarlo:
El autorizador es responsable de aceptar o rechazar la solicitud http. Si el autorizador dice que el token es válido, usted decide qué significa:
- ¿Tiene el autorizador una forma de inspeccionar la URL, identificar la operación y buscar alguna base de datos de control de acceso basada en roles para ver si está permitida? En caso afirmativo y la solicitud llega, el servicio puede asumir que está permitido y no necesita verificarlo.
- ¿Es el token un todo o nada, por lo que si el token es correcto, se permiten todas las operaciones? Entonces el servicio no necesita verificar.
- ¿El token significa "esta solicitud está permitida, pero aquí está el UUID del rol; usted verifica si la operación está permitida"? Luego, depende del servicio buscar ese rol y ver si la operación está permitida.
Referencias
- RFC 5234 3.6. Repetición de variables: *Regla
- RFC 2616 2.1 BNF aumentada
Lea primero el ejemplo en rfc6749 sec 7.1 .
El token de portador es un tipo de token de acceso que NO requiere un mecanismo PoP (prueba de posesión).
PoP significa un tipo de autenticación multifactor para hacer que el token de acceso sea más seguro. árbitro
La prueba de posesión se refiere a métodos criptográficos que mitigan el riesgo de que un atacante robe y utilice tokens de seguridad. A diferencia de los 'tokens portadores', donde la mera posesión del token de seguridad permite al atacante usarlo, un token de seguridad PoP no se puede usar tan fácilmente: el atacante DEBE tener tanto el token como el acceso a alguna clave asociada con el token ( por lo que a veces se les conoce como tokens "titulares de la clave" (HoK).
Tal vez no sea el caso, pero yo diría,
- token de acceso = métodos de pago
- token al portador = efectivo
- token de acceso con mecanismo PoP, por ejemplo, token MAC = tarjeta de crédito (se verificará la firma o contraseña, a veces será necesario mostrar su identificación para que coincida con el nombre de la tarjeta)
Sobre el término "Portador"
"Cheque al portador (cheque)" se refiere a un tipo de cheque que no está nombrado ni endosado. Puede ser cobrado o depositado por cualquier persona que posea físicamente el cheque, ya que no requiere ninguna identificación o autorización específica. Mientras que "verificación de nombre", también conocido como verificación de pedido, se refiere a un tipo de cheque que se hace específicamente a nombre de una persona u organización determinada. Para cobrar o depositar un cheque a nombre, el beneficiario debe presentar una identificación adecuada y endosar el cheque firmando el reverso. El endoso del beneficiario sirve como autorización para que el banco procese el cheque y transfiera los fondos a la persona u organización designada.
