Los proveedores de recursos a menudo proporcionan acceso de lectura y escritura a los recursos.
Por lo tanto, un proveedor de recursos no solo debe validar el token (¿está vencido? ¿está revocado? ¿es válido? ¿contiene el alcance requerido?), también deben verificar los privilegios del token (¿usa XY tiene suficientes privilegios para recurso de lectura o escritura ZY?).
Hasta ahora he usado el siguiente flujo de trabajo:
- El cliente recibe un token de acceso a través de la concesión del código OAuth2.
- El cliente realiza una solicitud en nombre del usuario para, por ejemplo, %código%
- El Servicio de recursos (llamémoslo Publicaciones de usuarios ) valida el token realizando una solicitud al Servidor de autorización, confirmando que el token es válido. El Servidor de Autorización también pasa metadatos como la fecha de caducidad del token, la audiencia del token, los ámbitos del token y el tema del token (por ejemplo, Usuario XY)
- El Servicio de recursos ahora valida que el sujeto (por ejemplo, el Usuario XY) está autorizado / autorizado para realizar la solicitud. Por ejemplo, marcando una lista de control de acceso o similar. Por ejemplo: Digamos que el usuario XY quiere actualizar la publicación de un usuario por parte del usuario AB. Esto, por ejemplo, sería rechazado por la Lista de control de acceso.
- Si la validación pasa, el servidor de recursos ejecuta la solicitud.
¿Es esta una forma válida de hacer cosas o estoy abriendo vectores de ataque? ¿Es correcto que el servidor de recursos suponga que el sujeto del token es el que debe considerarse la solicitud de autorización? ¿Hay quizás mejores prácticas o estándares para resolver esto?
Actualmente estoy confundido, porque leo que OAuth2 es solo delegación, no autorización ni autenticación y que clientes no debe hacer suposiciones implícitas como "el token XY pertenece al usuario AB, por lo que el usuario AB está autenticado" .
Cualquier ayuda es apreciada con mucho gusto.