OpenID Connect: ¿Por qué usar el flujo de código de autorización?

3

Tengo una pregunta sobre la implementación de OpenID Connect en la que esperaba poder obtener ayuda. Comprendo los diferentes flujos y entiendo que el flujo del código de autorización es bueno porque permite que las credenciales del cliente y la comunicación de servidor a servidor sean más seguras que la comunicación a través del agente de usuario. Pero aun así, el uso del código intermediario parece innecesario si el cliente y el OP utilizaran el cifrado autenticado en su correspondencia a través del agente del usuario. Los ataques al Día de la Marmota se podrían restringir mediante el uso de un tiempo de caducidad muy breve especificado en el mensaje o eliminarse con una solicitud preliminar al OP para un nonce. Suponiendo un cifrado suficientemente sólido, es decir, AES-256, creo que incluso los tokens de actualización podrían enviarse a través del agente de usuario con una disminución insignificante en la seguridad. ¿Hay otras consideraciones o razones por las que esto podría o no debería hacerse que pueda haber pasado por alto?

    
pregunta k0mrade_kangaroo 25.03.2015 - 13:08
fuente

3 respuestas

1

Aunque la conexión entre el agente de usuario y los servidores es segura, es posible que el agente de usuario no esté completamente protegido. Dado que el flujo de código de autorización garantiza que el agente de usuario no está al tanto de los tokens, la seguridad se mejora al reducir la exposición de tokens solo entre servidores.

    
respondido por el HTLee 28.06.2016 - 03:14
fuente
1

Hay algún nivel adicional de seguridad. Cuando se realiza una solicitud al punto final del token para intercambiar el código recibido desde el punto final autorizado, permite que la aplicación cliente se autentique al servidor de autorización. Cuando realiza una solicitud al punto final de Token, envía más datos sobre el cliente. Para clientes confidenciales (aplicaciones que son capaces de almacenar de forma segura un secreto de cliente), el punto final de token requiere que el cliente se autentique a sí mismo por medio de un ID de cliente y un secreto de cliente. Consulte esta sección de la especificación OAuth 2.0 y esta sección de la Especificación de conexión de OpenID . Para resumir, la aplicación cliente puede enviar la identificación del cliente y el secreto del cliente de dos maneras. Una forma es usar el par como una combinación de nombre de usuario / contraseña a través de la autenticación HTTP básica y la otra enviando las credenciales en el cuerpo de POST de la solicitud del punto final del token. Debo agregar que solo se requieren tipos de clientes confidenciales para enviar el par de ID de cliente / secreto de cliente. Por lo general, los tipos de clientes públicos no llaman al punto final del token *** Por ejemplo, el flujo implícito solo usa el punto final Autorizar. Una de las razones por las que el flujo implícito se considera menos seguro es porque la aplicación cliente nunca se autentica con el servidor de autorización. El flujo implícito solo envía un ID de cliente y se envía al punto final de Autorización que no admite un secreto de cliente o ninguna forma para que el cliente se autentique. Tenga en cuenta que enviar solo la identificación del cliente no es autenticar al cliente. Solo es identificarlo.

El resultado final: cuando usa el flujo de código de autorización, está autentificando a su cliente y, por lo tanto, agregando otra capa de seguridad.

*** Puede ejecutarse en un escenario en el que un cliente público utiliza el punto final de token. Si tiene una aplicación de JavaScript que utiliza el flujo del propietario del recurso y está enviando credenciales directamente al punto final del token, NO enviaría un secreto de cliente porque el secreto de un cliente no se puede almacenar de forma segura en una aplicación de JavaScript.

    
respondido por el Rob L 25.11.2017 - 12:40
fuente
0

En la concesión implícita, que parece estar bajo consideración, los tokens se devuelven desde el punto final de la autorización en la URL de redireccionamiento y se registrarán en el historial del navegador.

La concesión del código de autorización es beneficiosa para clientes públicos (sobre flujo implícito) porque los tokens se obtienen a través de una solicitud POST para el punto final del token . La subvención también permite emplear PKCE .

Para los clientes confidenciales, los tokens pueden viajar a través de un canal de respaldo seguro y no tienen que estar expuestos al agente de usuario en el flujo de código de autorización.

    
respondido por el ko la 28.09.2018 - 09:21
fuente

Lea otras preguntas en las etiquetas