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.