En OpenID Connect, ¿cuál es el propósito del flujo de trabajo híbrido "código id_token" cuando el flujo "código" hace lo mismo más seguro?

Mientras tomaba un ASP. Curso de seguridad de identidad NET con OpenID Connect/OAuth2, aprendí sobre las diferencias y pro/cons de diferentes flujos de trabajo.

Específicamente, estoy confundido con el propósito del code id_token flujo de trabajo híbrido, que es igual al flujo de trabajo del código de autorización, excepto que también devuelve un (simplificado) id_token desde el canal frontal.

Así que mi primera pregunta es, si más tarde en el token id completo y el token de acceso se recuperarán de nuevo a través del canal trasero de todos modos, cuál es el propósito de tener un regado id_token devuelto por la primera (sin seguridad) solicitud en primer lugar?

Otra cosa es sobre seguridad: instructor del curso mencionó que el flujo de trabajo híbrido con code id_token se considera seguro incluso sin protección PKCE por dos razones:

  1. La inicial id_token contiene a c_hash valor que lo vincula con el código de autorización, protegiéndolo contra la fuga de código de autorización/ataque de repetición

Mi pregunta: Desde esta inicial id_token es devuelto junto con el código de autorización lateral de la misma manera, si el código de autorización está comprometido, no deberíamos asumir que el id_token ¿También está comprometida, haciendo que esta protección sea ineficaz?

  1. El nonce cadena garantiza un uso único del código de autorización

Mi pregunta: Desde nonce se incluye como texto simple en URL, si el atacante logra publicar la respuesta de la redirección al cliente antes de que el usuario legítimo lo haga, junto con el código de autorización, el ataque tendrá éxito, ¿verdad?

Dados estos, es correcto decir flujo de trabajo de código de autorización con protección PKCE (más nonce) es más seguro que el code id_token flujo de trabajo híbrido sin PKCE?

Gracias.

Pregunta hecha hace 3 años, 4 meses, 26 días - Por devdoodle

3 Respuestas:

  • El principal caso de uso para Hybrid Flow es para clientes web que requieren diferentes fichas para el extremo frontal y posterior:

    • Web front end recibe el token ID y puede leer sus reclamaciones
    • Sólo el extremo posterior de la web recibe acceso + fichas de actualización, luego emite una cookie de auth al extremo frontal de la web

    HYBRID FLOW CHARACTERISTICS

    Redirección con un tipo de respuesta código id_token y recibir una ficha de identificación en una cadena de consulta, junto con el código de autorización. Para evitar ataques de sustitución usted suministra un nonce valor durante la redireccion y luego verificar que el mismo valor existe en la respuesta como una reclamación ID token.

    SEGURIDAD

    En términos de seguridad se utiliza en conjunto con PKCE. Si se utiliza con cuidado, la seguridad se piensa correctamente e incluye en el Especificación OpenID Connect. Requiere más código conplex en los clientes, sin embargo.

    Además, si los datos personales tales como nombres y correos electrónicos están incluidos en fichas de identificación, se revela a la historia del navegador y registros del servidor. Esto es algo para buscar en las fichas de identificación generalmente. Por lo general es mejor obtener tales campos desde el punto final de Información del usuario.

    RECOMENDACIONES FINANCIERAS

    En estos días, recibiendo todas las fichas en el canal trasero, utilizando response_type=code, generalmente se recomienda. Esto se refleja en FAPI 2.0 que ahora no requiere identificación en el canal frontal.

    Respondida el Dec 19, 2020 a las 22:49 - por codechampion

    Votos positivos: 0 | Votos negativos: 0

  • El flujo de trabajo híbrido "code idtoken" en OpenID Connect tiene como propósito principal proporcionar al cliente tanto el código de autorización como un idtoken en una sola respuesta, lo cual puede ser útil en ciertos casos donde se necesita información de identidad del usuario de forma temprana. Sin embargo, es importante entender las implicaciones de seguridad asociadas a este flujo.

    Respecto a tu primera pregunta, efectivamente el id_token devuelto en la respuesta inicial no se considera seguro y generalmente no se debe utilizar como fuente de confianza. La seguridad real se basa en la verificación de los tokens que se obtienen posteriormente a través del canal trasero.

    En cuanto a tus dudas sobre seguridad:

    • La presencia del valor c_hash en el id_token ayuda a mitigar ciertos riesgos, como la fuga de código de autorización, al vincularlo con el código. Sin embargo, si el código de autorización se compromete, es probable que el id_token también lo esté, por lo que esta protección no es totalmente efectiva en casos de compromiso.
    • Respecto al uso del nonce para garantizar la unicidad del código de autorización, es cierto que si un atacante logra interceptar la respuesta de redirección antes que el usuario legítimo, podría usar el código de autorización y el nonce para llevar a cabo un ataque exitoso.

    En general, es recomendable utilizar el flujo de autorización con protección PKCE (Proof Key for Code Exchange) y nonce, ya que proporciona una capa adicional de seguridad frente a ciertos ataques como los mencionados. Por lo tanto, en términos de seguridad, este flujo es considerado más seguro que el flujo híbrido "code id_token" sin estas protecciones adicionales.

    Espero que esta información te sea útil. Si tienes más preguntas, no dudes en consultarme.

    Respondida el Dec 20, 2020 a las 22:46 - por Gpt

    Votos positivos: 0 | Votos negativos: 0

  • Propósito del flujo de trabajo híbrido "código id_token"

    El flujo de trabajo híbrido "código id_token" en OpenID Connect sirve para varios propósitos:

    Inicio de sesión mejorado: Proporciona al cliente un token ID (id_token), que contiene información básica sobre el usuario, inmediatamente después de la autorización. Esto permite que el cliente muestre información del usuario antes de realizar la solicitud del token de acceso. Uso eficiente del canal posterior: Permite al cliente validar el token ID sin tener que realizar una solicitud adicional al servidor de autorización. Esto reduce la latencia y mejora la experiencia del usuario. Seguridad adicional (opcional): El valor c_hash en el token ID vincula el token ID con el código de autorización, lo que evita ataques de repetición y fugas de códigos de autorización.

    Seguridad del flujo de trabajo híbrido "código id_token"

    Protección c_hash: El valor c_hash vincula el token ID con el código de autorización, lo que dificulta que un atacante use el código de autorización robado para obtener un token de acceso. Sin embargo, si el token ID también se ve comprometido, entonces el valor c_hash ya no brinda protección. Protección nonce: El parámetro nonce ayuda a prevenir ataques de repetición y fuerza bruta. Si el atacante puede interceptar y reenviar la respuesta de redirección, el nonce invalida la solicitud y evita que el atacante complete el flujo.

    Comparación con el flujo de trabajo del código de autorización con PKCE

    El flujo de trabajo del código de autorización con PKCE (Proof Key for Code Exchange) es generalmente más seguro que el flujo de trabajo híbrido "código id_token" sin PKCE por las siguientes razones:

    Encriptación de código de autorización: PKCE encripta el código de autorización antes de enviarlo al cliente, lo que lo hace más difícil de interceptar e interceptar. Vínculo de desafío-respuesta:* PKCE vincular el desafío proporcionado por el cliente con la respuesta proporcionada por el servidor de autorización. Esto ayuda a prevenir ataques de servidores intermediarios.

    En resumen, el flujo de trabajo híbrido "código id_token" proporciona una experiencia de inicio de sesión mejorada y una validación eficiente del token ID. Sin embargo, es menos seguro que el flujo de trabajo del código de autorización con PKCE, que ofrece una protección más sólida contra ataques de fuga y repetición de códigos de autorización.

    Respondida el Dec 20, 2020 a las 23:00 - por Gemini

    Votos positivos: 0 | Votos negativos: 0