Estoy a punto de crear un servicio dentro de nuestro servidor de recursos que intercambiaría un token de acceso generado externamente por un token de acceso generado internamente. Sin embargo, esto se siente mal. No he encontrado evidencia de que alguien más necesite este patrón, lo cual es una buena señal de que me estoy perdiendo algo.
Detalles
Estamos ejecutando un SOA basado en REST típico. Delegamos la autenticación a Auth0 para que podamos ayudar a los clientes con diferentes proveedores de identidad. Como es, recibimos solicitudes de API y realizamos autenticación basada en el token de acceso generado por Auth0. Sin embargo, queremos administrar los permisos detallados de la API internamente y queremos un mayor control sobre el ciclo de vida del token (es decir, la revocación forzada del lado del servidor).
Auth0 admite reclamos personalizados, pero eso requeriría un acoplamiento muy estrecho entre nuestro servidor y el de ellos (o nuestras reglas en su servidor). Además, eso tampoco resuelve la necesidad de revocación forzada.
Parece que se puede satisfacer esta necesidad intercambiando el token de acceso generado por Auth0 por un nuevo token de acceso generado por nuestro servidor, que podría inyectar reclamos sobre los permisos configurados del usuario / identidad. Esto nos permitiría controlar, y todo lo que queramos sobre el token, incluida su revocación.
Preocupaciones
Sigo recorriendo las especificaciones de OIDC y OAuth2, y buscando a otros con una necesidad similar. La falta de golpes me preocupa.
¿Existe una mejor manera de administrar la autorización internamente, mientras se sigue delegando la autenticación a un proveedor como Auth0?
¿Hay una mejor manera de admitir la revocación de token que generar y rastrear tokens uno mismo? ¿Es posible mantener tokens sin estado y apoyar la revocación al mismo tiempo? (Si esto es demasiado para una publicación de SE, ignora esta parte).
Actualizar !
Descubrí Token Exchange que se parece a lo que estoy buscando ... una versión basada en OIDC / OAuth2 de un servicio de token seguro que puede intercambiar tokens desde un lado de un entorno heterogéneo federado para tokens administrados por otro lado del entorno.
Entonces, refinaré mi pregunta: de acuerdo con el caso de uso que he descrito, ¿es apropiado el modelo de intercambio de token? Si no, ¿qué?