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


81

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

La especificación de la versión 2 de OAuth dice:

  1. Acceder a recursos protegidos

    El cliente accede a los recursos protegidos presentando el
    token de acceso al servidor de recursos. El servidor de recursos DEBE validar el
    token de acceso y asegurarse de que no haya expirado y que su alcance cubra
    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 el
    servidor de autorización
    .

¿Cómo funciona en la práctica esta interacción entre el servidor de recursos y el servidor de autorización?

  • ¿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? ¿El Scope está codificado en el token de acceso o el servidor de recursos primero tiene que ponerse en contacto con el servidor de autorización?
  • ¿Cómo se establece la confianza entre el servidor de recursos y el servidor de autorización?

Los atributos del 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 especificaciones complementarias.

¿Alguien puede dar ejemplos de atributos de token?


1
Esta es realmente una pregunta que estoy buscando desde hace unos días
Uttam

Respuestas:


79

La razón por la 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 qué tan compleja es su implementación.

Por ejemplo, ¿tiene un servidor que administra la autenticación y el acceso, y un conjunto de servicios discretos, cada uno con sus propios servidores que atienden las llamadas API? ¿O tiene solo una caja con un servidor web que maneja tanto la autenticación / autorización como las llamadas a la API?

En el caso de una sola caja, no se necesita mucho ya que la entidad que emite los tokens es la misma 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, la identificación de usuario y otra información directamente en el token y cifrarlo usando un simétrico o asimétrico 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ública / privada o un secreto simétrico. y utilícelo para cifrar todo lo que necesita el servidor de recursos en el token.

Los tokens autónomos son más largos pero ofrecen un rendimiento mucho mejor por solicitud. Sin embargo, tienen un precio: realmente no puede revocarlos mientras aún sean válidos (no vencidos). Por esta razón, los tokens autónomos deben durar muy poco (lo que sea aceptable para dejar el acceso abierto después de que se revocó, por ejemplo, muchos sitios usan una hora), con un token de actualización válido durante un año o más para obtener nuevos tokens.


¿Es cierto que si la entidad que emite y valida tokens no tiene una IP blanca / pública estática, las devoluciones de llamada del proveedor de servicios al cliente / propietario del recurso no se pueden realizar a través de HTTP (s), por lo que se requieren implementaciones más elaboradas?
Denys S.

Las devoluciones de llamada no las realiza el proveedor de servicios, sino el navegador del usuario. No estoy seguro de lo que está preguntando.
Eran Hammer

¿Qué sucede si agrega algunas apis que usa el servidor de recursos (las apis que le pertenecen), entonces debería usar la autenticación oath2 (client_credentials) para establecer una comunicación segura de máquina a máquina con el servidor de recursos? En ese caso, ¿eso significa que todas las apis tienen que compartir el mismo par de claves con el servidor de autenticación?
Dionisis K

4

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


OIDC e id_tokens es algo diferente de los tokens de acceso obaque.
machete
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.