oauth 2.0 - inc - ¿Es compatible OpenID Connect con la concesión de Credenciales de contraseña del propietario del recurso?
oauth2 java (3)
He estado utilizando el flujo de credenciales del propietario del recurso OAuth anteriormente para la autorización.
Sin embargo, ahora me gustaría considerar el uso de openid connect para esto, para autenticación y autorización, y me preguntaba si el flujo de credenciales del propietario del recurso es compatible con openid connect.
La respuesta es sí. No está explícito en la especificación, pero OpenID Connect admite todos los flujos de OAuth 2.0 ya que es una extensión de OAuth 2.0.
La especificación habla sobre los flujos que implican la redirección del navegador, ya que son más comunes, más seguros y menos frágiles, dado que las credenciales del propietario del recurso solo admiten el nombre de usuario y la contraseña, y solo están en la especificación OAuth 2 para la compatibilidad con versiones anteriores.
En los verdaderos sistemas de SSO, querrá abstraerse del método de autenticación del usuario en el OP / IDP. Involucrar a un navegador es una forma de hacerlo. En el flujo de Credenciales de contraseña del Propietario del recurso, el cliente "ve" el nombre de usuario / contraseña del Propietario del recurso, a diferencia de los otros flujos, que anula el propósito principal de un protocolo SSO federado como OpenID Connect donde los mecanismos de autenticación y las credenciales deben ser independientes del cliente / la aplicación Por esa razón, no verá mucho uso de ROPC en OpenID Connect, con una excepción tal vez en casos de uso dentro de la empresa.
Pero su kilometraje puede variar en función de Soporte en software OP / AS específico y bibliotecas cliente.
Sí, OpenID Connect admite todos los tipos de concesión de OAuth 2.0, incluida la concesión de credenciales de contraseña del propietario del recurso y la concesión de credenciales de cliente.
Como sabemos, la concesión de código de autorización y la concesión implícita son flujos típicos de 3 patas que incluyen la interacción entre un cliente, un servidor de autorización y un usuario. Si bien la concesión de credenciales de contraseña del propietario del recurso y la concesión de credenciales de cliente tienen dos patas, lo que significa que el cliente utiliza ámbitos previamente autorizados para que no sea necesaria la interacción con el usuario, eliminando la necesidad de realizar una de las patas en el flujo típico.
Aquí hay una referencia: Configuración de un proveedor de OpenID Connect para habilitar solicitudes de OAuth de dos patas
Sí. También estaba encontrando respuesta para la misma pregunta a veces de vuelta. De acuerdo con la especificación de OpenId Connect, se recomienda utilizar el authorization code y los tipos de concesión implicit para las solicitudes de OpenId Connect. Pero no se menciona que otros tipos de subvención no pueden ser utilizados. Por lo tanto, puede usar cualquier otro tipo de concesión para la solicitud de autenticación de OpenId Connect. Hay un poco de correo del grupo openid connect, que se ha discutido sobre esto. Por favor, encontrarlo desde here . Si su servidor de Autorización OAuth2 lo admite, supongo que está bien usarlo. Como sé, la mayoría de los servidores de Autorización lo admiten, como un ejemplo de here