Pregunta Comunicación OAuth v2 entre autenticación y servidor de recursos


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

los Especificación de la versión 2 de OAuth lee:

  1. Acceder a los recursos protegidos

    El cliente accede protegido   recursos presentando el acceso
      token al servidor de recursos. los   el servidor de recursos DEBE validar el
      acceso token y asegurarse de que no tiene   expiró y que su alcance cubre
      el recurso solicitado. Los métodos   utilizado por el servidor de recursos para
      validar el token de acceso (así como   cualquier respuesta de error) son más allá de   alcance de esta especificación, pero   en general involucrar una interacción o   coordinación entre el recurso   servidor 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 funciona el servidor de recursos? determinar que un token de acceso lo recibido es válido?
  • Cómo hace el servidor de recursos extraer el permitido 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?

Acceda a los atributos de token y   métodos utilizados para acceder a   los recursos son más allá del alcance de este   especificación y están definidos por   especificaciones del acompañante.

¿Alguien puede dar ejemplos de atributos de tokens?


76
2018-06-06 16:28


origen


Respuestas:


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 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.


77
2018-06-20 18:39



Un ejemplo de API de servidor de autorización de recursos es la de Sitio web de Google Developers.
Sin embargo, no especifica el formato del token de acceso, pero la respuesta parece bastante útil universalmente.


4
2017-12-20 07:59