¿Hay algún inconveniente en el uso de la "pseudoautentificación" de OAuth en lugar de OpenID?

OAuth se diseñó para casos en los que la Aplicación X necesita acceso a recursos (por ejemplo, "mis fotos" o "mi dirección de correo electrónico" o "mi calendario") controlados por la Aplicación Y y que pertenecen al Usuario A: el Usuario A puede querer conceder acceso a esos recursos en la Aplicación Y, pero él no quiere dar a la Aplicación X sus credenciales de nombre de usuario / contraseña reales. Por lo tanto, un token de acceso se usa como una credencial alternativa para un recurso en la Aplicación Y. Los tokens de acceso pueden ser revocados independientemente de las credenciales de nombre de usuario / contraseña y, idealmente, tienen un ámbito estricto para permitir solo el acceso a recursos específicos.

El uso de OAuth 2 para las sobrecargas de autenticación que modelan de manera que puede ser riesgoso. Mire el ejemplo anterior e imagine que se usa para la autenticación. Si la Aplicación X usa ese token de acceso para la autenticación, entonces toma un token que otorga acceso a los recursos en la Aplicación Y y lo usa para otorgar acceso a sus propios recursos. Tal vez sea la división de los pelos, porque lo importante es que sabemos que el hecho de otorgar un token de acceso a través de OAuth 2 implica que el usuario se ha autenticado correctamente. El problema es que el token de acceso no dice nada sobre la aplicación que el usuario final autenticó para . Entonces, ¿qué sucede si la aplicación Z también tiene un token de acceso para los recursos del usuario A en la aplicación Y? Si la Aplicación Z puede obtener la Aplicación X para usar este token de acceso, entonces tiene acceso a los recursos del Usuario A en la Aplicación X . Eso es malo. El Usuario A puede haber confiado en la Aplicación Z para acceder a sus recursos en la Aplicación Y, pero el Usuario A ciertamente nunca otorgó el consentimiento para que la Aplicación Z acceda a sus recursos en la Aplicación X.

OpenID y OpenID Connect están diseñados específicamente para la autenticación. OpenID Connect se construye sobre OAuth 2 para poder aprovechar las interacciones y flujos existentes, pero agrega una entidad llamada un token de identificación, que es un objeto que contiene un conjunto de notificaciones sobre un evento de autenticación. Esas reclamaciones incluyen un identificador para el usuario que realizó la autenticación, un identificador para el servidor que manejó la autenticación y un identificador de la audiencia de la autenticación. Esto le da a la aplicación la información que necesita para validar que un usuario está autenticado en su nombre.

Cada vez que comparo los dos, considero que son la diferencia entre un modelo de autenticación / identificación activo y pasivo con el OpenID pasivo, OAuth activo.

Pasivo le dice a la aplicación que solicita qué hacer, como un redireccionamiento del navegador web del proveedor de identidad a la aplicación, y el navegador es un cliente simple y tonto porque solo hace lo que se le ha dicho que haga. Activo requiere que la aplicación solicitante sepa qué hacer cuando entrega los datos, y hace lo que quiera con los datos, por ejemplo. el token.

Los modelos activos permiten que la aplicación realice una solicitud directa a una API con el token de usuarios porque tiene el token almacenado localmente. Los modelos pasivos requieren que el usuario se autentique con una redirección al proveedor y vuelva a la aplicación con un token temporal. (No es técnicamente temporal, pero se ajusta a la explicación)

Dependiendo de lo que intente hacer con su aplicación, cualquiera de los modelos podría funcionar.

• OAuth es un protocolo de autorización, en lugar de un protocolo de autenticación. El uso de OAuth por sí solo como un método de autenticación puede denominarse pseudo-autenticación.
• OpenID está diseñado específicamente como un protocolo de autenticación.

La diferencia crucial es que en el caso de uso de autenticación de OpenID , la respuesta del proveedor de identidad es una afirmación de identidad; mientras que en el caso de uso de autorización de OAuth , el proveedor de identidad también es un proveedor de API, y la respuesta del proveedor de identidad es un token de acceso que puede otorgar acceso continuo a la aplicación a algunas de las API del proveedor de identidad. en nombre del usuario. El token de acceso actúa como un tipo de "clave de valet" que la aplicación puede incluir con sus solicitudes al proveedor de identidad, lo que demuestra que tiene permiso del usuario para acceder a esas API.

Debido a que el proveedor de identidades generalmente (pero no siempre) autentica al usuario como parte del proceso de otorgar un token de acceso OAuth, es tentador ver una solicitud exitosa de token de acceso OAuth como un método de autenticación en sí mismo. Sin embargo, dado que OAuth no se diseñó teniendo en cuenta este caso de uso, esta suposición puede dar lugar a fallas de seguridad importantes

Fuente