Si te encuentras con alguna parte que te causa duda puedes dejarlo en los comentarios y haremos todo lo necesario de ayudarte lo mas rápido que podamos.
Solución:
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 en posesión de él pueda. El uso de un token de portador no requiere que el portador demuestre la posesión de criptográficos. key material (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 va y genera para usted un Token. Los tokens de portador son el tipo predominante de token de acceso que se usa 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 aleatorio; se crea en función del usuario que le da acceso y del cliente que obtiene acceso a su aplicación.
Para acceder a una API, por ejemplo, debe utilizar un token de acceso. Los tokens de acceso duran poco (alrededor de una hora). Usas 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 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 restricciones sobre los tokens de portador que proporcionas. 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
El string "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 emisión, y el campo de audiencia especifica el dominio del remitente como una URL de la forma 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 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 estar tratando de encontrar respuestas sobre la funcionalidad del token de portador:
Supongamos que estoy implementando un proveedor de autorización, ¿puedo proporcionar algún tipo de string para la ficha al portador? ¿Puede ser al azar? string? ¿Tiene que ser una codificación base64 de alguna attributes? ¿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 un usuario y una contraseña a través de SSL, el servidor devuelve dos cosas: una Token de acceso y un Actualizar token.
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
Un token de acceso es un string con todas las propiedades de usuario, reclamos y roles que desee. (Puede comprobar 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 de usuario. De esta forma, el usuario será validado y otorgado junto con toda la aplicación.
Los tokens de acceso tienen un vencimiento corto (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 imagina un usuario con un rol = “Administrador” que cambia a “Usuario”. Si un usuario conserva el token antiguo con role = “Admin”, podrá acceder hasta el vencimiento del token con derechos de administrador. Es por eso que los tokens de acceso tienen un vencimiento corto.
Pero, me viene a la mente un problema. Si un token de acceso tiene un vencimiento breve, debemos enviar cada período breve 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 un vencimiento prolongado (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 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 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 intenta 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 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
Se parece a Base64 pero de acuerdo con ¿Debería codificarse el token en el encabezado 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 los caracteres que se usan normalmente en base64, base64url, etc. 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 en la lista de preguntas de OP. Entonces, extiendo esta respuesta para abordar la cuarta pregunta, sobre si el token debe ser validado, 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, depende de usted decidir qué significa esto:
- ¿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? Si es así 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 no es necesario verificar el servicio.
- ¿El token significa “esta solicitud está permitida, pero aquí está el UUID para el 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 variable: * Regla
- RFC 2616 2.1 BNF aumentado
Te mostramos las comentarios y valoraciones de los lectores
Nos puedes añadir valor a nuestra información añadiendo tu veteranía en las notas.