¿Cómo realizar la autorización basada en roles con OAuth2 / OpenID Connect?

14

Estoy tratando de usar OAuth2 para la autenticación / autorización, pero después de leer mucho, estoy confundido ... Estoy tratando de entender cómo OAuth y OpenIDConnect se relacionan entre sí, y cómo los puedo usar. autorización.

Por lo que entendí hasta ahora :

  • OpenID Connect es la mejor para la autenticación, OAuth es la mejor para la autorización
  • La autorización de OAuth2 se realiza a través de los ámbitos
  • Un ámbito es el permiso otorgado POR el usuario A un cliente, validado en el servidor de recursos

  • OpenID Connect id_token está pensado principalmente para la aplicación cliente, para proporcionar información del usuario, y NO como una forma para que el servidor de recursos valide al usuario

Aquí está mi caso de uso :

  • Necesito proporcionar SSO a un conjunto de servicios web completamente sin estado realizados por nosotros
  • OAuth está restringido a la concesión de propietario de recursos
  • El servidor de identidad se proporciona de nuestro lado y está conectado a un servidor LDAP
  • Solo las aplicaciones de confianza se pueden registrar como proveedores de servicios

Y lo que estoy intentando hacer, lo que me desconcierta :

  • Solo los usuarios autorizados pueden acceder a una API de servicio web determinada

Por lo tanto, necesito alguna forma de verificar el permiso otorgado POR una entidad externa A un usuario, en el servidor de recursos. ¿Cuál, creo que descarta el uso de OAuth para la autorización?

No estoy seguro de cómo lograr esto con OAuth / OpenID connect, o incluso SI se ajusta a mi caso de uso.

  1. ¿Se puede hacer que el acceso basado en roles funcione con los ámbitos de OAuth2?
  2. ¿Estaría bien pasar el id_token al servidor de recursos, con un reclamo que contenga los roles del usuario (y descartar el access_token por completo)? Por lo tanto, el id_token se usaría tanto para la autenticación como para la amp; autorización. Dado que el id_token está firmado y contiene hashes, estaría bien, ¿verdad?
  3. ¿Debería simplemente autenticarme con OpenIDConnect, comprobando la presencia de id_token, desechando el access_token por completo y desarrollando mi propio sistema de autorización basado en roles?

Disculpas por la pared de texto, no estoy seguro de si malentiendo el alcance de OAuth / OpenID Connect aquí. ¿Estoy haciendo las suposiciones equivocadas?

Gracias.

    
pregunta lv. 09.05.2016 - 15:32
fuente

1 respuesta

4

El concepto de rol se puede usar con tokens de acceso en OpenID Connect (Oauth2).

Considere que un ámbito es una solicitud de reclamos sobre el usuario que debe incluirse en el token de acceso. La API que solicita acceso sabe que necesita el rol de "empleado" (por ejemplo), incluye el parámetro de consulta " scope=openid roles " en la solicitud.

El servidor de autenticación (AS) tiene acceso a la información de rol sobre el usuario (por ejemplo, en un directorio LDAP). Luego puede buscar las funciones del usuario e incluirlas en el reclamo de "funciones" en el token de acceso.

También puede limitar el alcance solicitando el rol en sí ( scope=openid employee ), en cuyo caso el AS podría incluirlo si el usuario es miembro de ese grupo. Esto es un poco menos escalable, ya que requiere un conocimiento detallado de los roles necesarios, pero reduce la cantidad de PII en el token y reduce su tamaño. Además, si el usuario no es miembro del grupo especificado (es decir, el alcance no puede incluirse en el token), el AS debe informar a la API sobre esto según OAuth2.

El uso de roles es bastante común, y algunos ejemplos se pueden encontrar en:

Así como para las preguntas 2) y 3): No hagas esto :)

    
respondido por el Geir Emblemsvag 15.08.2018 - 09:09
fuente

Lea otras preguntas en las etiquetas