OAuth v2 comunicación entre autenticación y servidor de recursos

Question

Tengo algunos problemas para entender cómo funciona OAUTH-v2.

El OAuth version 2 spec lee:

7. acceso a los recursos protegidos

   El cliente tiene acceso a los recursos protegidos presentando el acceso
   contadores al servidor de recursos. El servidor de recursos DEBE validar el token de acceso
   y asegurarse de que no ha caducado y que su alcance cubre
   el recurso solicitado. Los métodos utilizados por el servidor de recursos a
   validar el testigo de acceso (así como cualquier respuesta de error) son más allá 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 trabajo servidor de autorización en la práctica?

• ¿Cómo el servidor de recursos determinar que un token de acceso que recibida es válida?
• ¿Cómo el servidor de recursos extrae el alcance 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?

atributos token de acceso y los métodos utilizados para acceso protegido recursos son más allá del alcance de esta especificación y se definen por especificaciones de compañía.

¿Alguien puede dar ejemplos de atributos de tokens?

Answer 1

La razón de que 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 sola caja, 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 por 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 es 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.

Answer 2

Un ejemplo de recurso a la API de servidor de autorización es el de Google Developers Website.
No especifica el formato del token de acceso, pero la respuesta parece bastante útil universalmente.