¿Por qué no puedo usar el Modo de respuesta de consulta con el Tipo de respuesta id_token (flujo "implícito")?

Question

¿Por qué no puedo usar el Modo de respuesta de consulta con el Tipo de respuesta id_token (flujo "implícito")?

#1 de HTLee (1 votos)

9

Aunque creo que OpenID 2.0 es un protocolo de autenticación más limpio y mejor que OpenID Connect, tengo que implementar un IdP de OpenID Connect.

Un punto que me gusta en OpenID 2.0 es que el IdP puede devolver una identidad firmada a la parte que confía (a través del agente del usuario) y no hay un viaje de ida y vuelta adicional entre el RP y el IdP.

A primera vista, OpenID Connect define un flujo "Implícito" que me parece bien. Pero cuando veo los detalles, parece que está diseñado solo para ser usado con "Clientes implementados en un navegador usando un lenguaje de scripting".

Pensé que de todos modos podría usar el flujo "Implícito" con un RP del lado del servidor, usando el Modo de respuesta de "consulta", pero el " OAuth 2.0 Prácticas de codificación de tipos de respuesta múltiple "documento prohíbe explícitamente el uso del modo de respuesta" consulta "con el tipo de respuesta id_token ...

¿Por qué está prohibido? Y de manera más general, ¿por qué el flujo "Implícito" está mal visto?

Tal como lo entiendo, siempre que los tokens de ID estén firmados y los RP no utilicen (y verifiquen) los puntos de acceso, el flujo "Implícito" debe ser seguro.

openid-connect

pregunta user2233709 15.03.2017 - 14:17

fuente

1 respuesta

Lea otras preguntas en las etiquetas openid-connect

¿Cómo operar un honeypot en la nube? ¿Qué esquema LDAP se recomienda para PKI?

score 1 · Answer 1

Y, en términos más generales, ¿por qué el flujo "Implícito" está mal visto?

Porque el token de acceso está expuesto al agente de usuario (navegador). Consulte Diagrama de flujo implícito en la especificación OAuth 2 , luego compárelo con el flujo del Código de Autorización que no expone el token al agente de usuario.

... prohíbe explícitamente el uso del modo de respuesta "consulta" con el tipo de respuesta id_token ... ¿Por qué está prohibido?

Definición rápida:

scheme://host:port/path?query#fragment

La parte de "consulta" de una URL es fácilmente inspeccionada por muchas partes: puede ser registrada por el agente de usuario (por ejemplo, el historial del navegador), y se encuentra a menudo en los registros de solicitud del servidor web. La regla de oro es nunca enviar información confidencial (por ejemplo, tokens, códigos de autorización, contraseñas) a través del parámetro "consulta".

Sin embargo, la parte del "fragmento" nunca se envía en solicitudes HTTP, ni aparecerá en los encabezados de los remitentes. Solo el JavaScript que se ejecuta en el agente de usuario (navegador) tendrá acceso a él.

Por ejemplo, un cliente (navegador) podría realizar una solicitud como esta:

GET /authorize?
  response_type=id_token%20token
  &client_id=s6BhdRkqt3
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &state=af0ifjsldkj HTTP/1.1
Host: server.example.com

El servidor de autenticación respondería con (observe el "fragmento" denotado por "#"):

HTTP/1.1 302 Found
Location: https://client.example.org/cb#
  access_token=SlAV32hkKG
  &token_type=bearer
  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3600
  &state=af0ifjsldkj

El navegador luego excluiría el "fragmento" cuando se redirige a la ubicación de destino. Se espera que el código JavaScript en el navegador envíe los token (s) relevantes mediante un mecanismo más seguro (por ejemplo, cuerpo de POST).

Hay peculiaridades entre los distintos navegadores, Pero nada aparente que derrote el supuesto de seguridad.