Autorización de grano fino con OAuth2

Question

Autorización de grano fino con OAuth2

#1 de Matt Carter (2 votos)
#2 de Bartosz Rosa (0 votos)

0

En mi entendimiento de OAuth2, el alcance se puede usar para especificar el acceso a lo que el propietario del código solicita y otorga.

En la mayoría de los casos, encuentro que la lista de ámbitos está cerrada y especifique "tipos" de cosas a las que se puede acceder, por ejemplo, perfil , correo electrónico , openid de inicio de sesión de Google .

¿Tiene sentido codificar el acceso a recursos específicos dentro del alcance? Me gusta cuenta: {número de cuenta}: rw

Esto es para el caso en el que el usuario tiene múltiples recursos distintos administrados por el servidor de recursos y desea autorizar el acceso de terceros a recursos específicos pero en lugar de "tipo" de recurso. Por ejemplo, la aplicación hipotética administraría carpetas de datos y el usuario U otorgaría acceso de lectura a su carpeta "/ A" pero no a ninguna otra carpeta a la aplicación B

Comprendo que, en tal caso, tanto el Servidor de Autorización como el de Recursos tendrían que analizar y manejar específicamente dichos ámbitos abiertos.

¿Hay otros problemas con ese enfoque?

¿Es OAuth2 la tecnología adecuada para este caso? Si no, ¿qué usar en su lugar?

authorization oauth2

pregunta AGrzes 20.10.2017 - 10:36

fuente

2 respuestas

Lea otras preguntas en las etiquetas authorization oauth2

¿Existe un riesgo de seguridad al tener acceso público a mis marcadores? dispositivo no reconocido en la red

score 2 · Answer 1

Creo que la intención de los ámbitos de OAuth era proporcionar un marco para el consentimiento delegado, que es una forma de autorización discrecional, pero diferente de la autorización basada en políticas, que es lo que parece ser lo que usted está tratando de lograr. El servidor de recursos tiene la responsabilidad de hacer cumplir tanto la delegación como el enfoque basado en políticas. Los ámbitos terminan siendo un reclamo similar, si intenta modelar una autorización basada en políticas y similar al control de acceso basado en roles, crecerá exponencialmente con la matriz de permisos (acción-recurso) (lectura de cuenta, escritura de cuenta, etc.) ) Los desarrolladores de su servidor de recursos deben saber qué significa cada ámbito para hacer cumplir: @PreAuthorize ("# oauth2.hasScope (‘ lectura-cuenta ') ") para que pueda ver la compleja lógica de si-entonces-lo que puede resultar.

Considere la posibilidad de externalizar su decisión de políticas de su servidor de recursos haciendo que use todo el contexto que tiene (atributos id_token, metadatos de recursos, huella del cliente, ámbitos) para realizar una solicitud de un servicio de decisiones de políticas con "can [subject] do [acción] en [recurso] en este [contexto / env]? " El servicio de decisión de políticas es un dominio que contiene su riesgo, contexto y reglas controladas por políticas como "Los clientes externos pueden leer los detalles de la cuenta cuando el propietario del recurso tiene una relación con el propietario de la cuenta cuando se utiliza la autenticación de dos factores". Buscar s

score 0 · Answer 2

TL; DR;

Este es un defecto de diseño. Los ámbitos representan el recurso y en relación con su cliente (aplicación) informa que esta aplicación tiene acceso al recurso. Este nivel de granularidad no es una buena idea. En este caso, terminaría con una lista muy difícil de mantener, diría yo, privilegios para aplicaciones (no usuarios). No es así como se debe hacer.

Los ámbitos en su definición son más bien valores que identifican recursos, no privilegios. Cuando envía un ámbito al Servidor de Autorización, los ámbitos informan a qué recursos desea acceder con su cliente (es decir, la aplicación), no con su usuario. Este es su recurso que debe interpretar si el usuario que presenta el token de acceso (con ámbitos) es legítimo para acceder a él.

Preguntó sobre el alcance en OAuth2, pero recuerde que OAuth2 es solo un marco para la AUTORIZACIÓN, no está definido para la autenticación. Para la autenticación del usuario, debe utilizar, por ejemplo, OpenIDConnect (OIDC) que se basa en OAuth2.

OIDC presenta el token de identidad que es el portador de los datos del usuario. Si obtiene el token de identidad y el token de acceso desde el servidor de autorización, su recurso decidirá si el usuario en particular tiene acceso a los datos que desea.