¿Por qué no oAuth for Authentication - AKA lo malo de OpenID Connect [duplicado]

2

Leí muchas preguntas y respuestas en este foro que indican que oAuth es para la autorización, OpenID es para la autenticación y muchos de ellos siguen diciendo que OpenID Connect proporciona autenticación al abusar de la autorización de oAuth.

¿Por qué el tono despectivo? Hay una fuerte implicación de que esto es malo, pero no he encontrado ninguna explicación para esto, y si bien comprendo la diferencia entre la autenticación y la autorización, no entiendo dónde alguien usaría la autorización sin autenticación, o más exactamente, sin atribuibilidad.

En realidad, eso no es cierto. Si lo intento, puedo pensar en situaciones en las que la atribuibilidad no es importante, pero no funcionará para mi situación: estoy trabajando en un servicio en línea que permitirá el registro de usuarios que utilizan FB, Twitter. , Google+ y probablemente LinkedIn para la autenticación. Las aplicaciones de front-end (basadas en web y móviles, potencialmente controladas por terceros) deberían desde mi entendimiento utilizar oAuth para acceder a los servicios de API / back-end en nombre de un usuario.

Por ejemplo, si recibo una solicitud de una aplicación móvil de aplicaciones para usuario o un sitio web para acceder a los mensajes de un usuario, tal como:

enlace

Necesitaría saber que el usuario que inició sesión en la aplicación o el sitio web no solo está autorizado para leer el recurso de mensajes, sino que, de hecho, es el usuario el que puede leer ese buzón específico.

Pero estoy divagando, entonces: ¿Es OpenID Connect malo de alguna manera? He visto el diagrama de Wikipedia ... ¿alguien puede explicar qué hay de malo en esa imagen?

En última instancia, estoy tratando de averiguar cuáles son todas las piezas del rompecabezas para crear una arquitectura donde:

a) Los usuarios se registran en el back-end y se autentican a través de     OpenID / Google / FB / etc
  b) Los usuarios acceden al servicio a través de un front-end independiente, por ejemplo, un     aplicación móvil o sitio web
  c) Los diferentes usuarios tienen diferentes roles (por ejemplo, personal y clientes) y     no pueden acceder a los datos personales o confidenciales de otros usuarios
  d) Es un servicio multiusuario, por lo que el personal de la compañía A podría     En realidad ser clientes de la empresa B y la empresa C!

FWIW: Algunas cosas que he visto, que me ayudan a confundirme / aclararme:

pregunta Johan 22.01.2015 - 09:22
fuente

1 respuesta

1

Diferencia ¿Entre OAUTH, OpenID y OPENID Connect en un término muy simple?

Bueno, esto estaba en la barra de navegación lateral.

Es como esto:

Si está autorizado para realizar la actividad A, posiblemente debe ser el propietario que puede realizar la actividad A. Por lo tanto, debe ser propietario. Autorización = Autenticación. Mientras que usted podría ser autenticado pero no autorizado.

    
respondido por el munchkin 22.01.2015 - 09:57
fuente

Lea otras preguntas en las etiquetas