web-services - implementar - oauth2 spring
Comunicación OAuth v2 entre autenticación y servidor de recursos (2)
Tengo algunos problemas para entender cómo funciona OAUTH-v2.
La especificación de la versión 2 de OAuth dice:
Acceder a los recursos protegidos
El cliente accede a recursos protegidos presentando el acceso
token al servidor de recursos. El servidor de recursos DEBE validar el
token de acceso y asegúrese de que no ha expirado y que su alcance cubre
el recurso solicitado. Los métodos utilizados por el servidor de recursos para
validar el token de acceso (así como cualquier respuesta de error) están fuera del alcance de esta especificación , pero generalmente implican una interacción o coordinación entre el servidor de recursos y la autorización
servidor .
¿Cómo funciona esta interacción entre el servidor de recursos y el servidor de autorización en la práctica?
- ¿Cómo determina el servidor de recursos que un token de acceso que recibió es válido?
- ¿Cómo extrae el servidor de recursos el alcance permitido del token para ver si se debe otorgar acceso a un recurso en particular? ¿Está el alcance codificado en el token de acceso o el servidor de recursos primero debe ponerse en contacto con el servidor de autorizaciones?
- ¿Cómo se establece la confianza entre el servidor de recursos y el servidor de autorizaciones?
Los atributos token de acceso y los métodos utilizados para acceder a los recursos protegidos están fuera del alcance de esta especificación y están definidos por las especificaciones complementarias.
¿Alguien puede dar ejemplos de atributos de tokens?
La razón por la cual esto está fuera del alcance de la especificación es la amplia gama de formas de lograr esta conexión entre las dos entidades. La pregunta principal es cuán compleja es su implementación.
Por ejemplo, ¿tiene un servidor que gestiona la autenticación y el acceso, y un conjunto de servicios discretos, cada uno con sus propios servidores al servicio de las llamadas API? O bien, ¿tiene solo una caja con un servidor web que maneje la autenticación / autorización y las llamadas API?
En el caso de una caja única, no se necesita mucho ya que la entidad emisora de tokens es la misma que la que los valida. Puede implementar tokens para usar una clave de tabla de base de datos y buscar el registro en la base de datos (o caché de memoria) en cada solicitud, o puede codificar el alcance, identificación de usuario y otra información directamente en el token y cifrarlo utilizando una simétrica o asimétrica algoritmo.
Las cosas se vuelven un poco más complejas cuando se trata de un entorno distribuido, pero no mucho. Todavía emite tokens en el servidor de autorización, pero el servidor de recursos necesita una forma de validarlos. Puede hacerlo poniendo una API interna a disposición del servidor de recursos para pedirle al servidor de autorización que "resuelva" el token (que puede ser rápido en un entorno local), o los dos pueden establecer un par de claves público / privado o un secreto simétrico y usar eso para encriptar todo lo que el servidor de recursos necesita en el token.
Los tokens autónomos son más largos pero ofrecen un rendimiento mucho mejor por solicitud. Sin embargo, tienen un precio; no se puede revocar realmente mientras aún son válidos (no caducados). Por esta razón, los tokens autónomos deben ser de muy corta vida (lo que sea aceptable para usted dejar abierto el acceso después de que fue revocado, por ejemplo, muchos sitios usan una hora), con un token de actualización bueno durante un año o más para obtener nuevos tokens.
Un ejemplo de API de servidor de autorización de recursos es la que se encuentra en el sitio web de Google Developers .
Sin embargo, no especifica el formato del token de acceso, pero la respuesta parece bastante útil universalmente.