¿Por qué OpenID Connect usa el token de identificación como un parámetro de cadena de consulta en el cierre de sesión?

3

OpenID Connect, en el flujo implícito, devuelve el token de identificación como un #fragmento en el URI de retorno específicamente para que el token de identificación no se registre en los registros del servidor web.

Sin embargo, el cierre de sesión de OpenID Connect especifica un parámetro de cadena de consulta id_token_hint que sería el token de identificación del usuario que está desconectado.

enlace

  

Cierre de sesión iniciado por RP

     

Un RP puede notificar al OP que el usuario final se ha desconectado del sitio y puede que también desee cerrar la sesión del OP. En este caso, el RP, después de haber cerrado la sesión del usuario final del RP, redirige al agente de usuario del usuario final a la URL del punto final de cierre de sesión del OP. Esta URL normalmente se obtiene a través del elemento end_session_endpoint de la respuesta Discovery del OP, o puede aprenderse a través de otros mecanismos.

     

Esta especificación también define los siguientes parámetros que se pasan como parámetros de consulta en la solicitud de cierre de sesión:

     

id_token_hint

     

RECOMENDADO. El token de ID emitido anteriormente se pasó al punto final de cierre de sesión como una sugerencia sobre la sesión autenticada actual del usuario final con el cliente. Esto se utiliza como una indicación de la identidad del usuario final que el RP está solicitando que el OP cierre la sesión. No es necesario que el OP aparezca como una audiencia del token de ID cuando se utiliza como un valor id_token_hint.

     

post_logout_redirect_uri

     

OPCIONAL. URL a la que el RP solicita que el agente de usuario del usuario final se redirija después de que se haya cerrado la sesión. El valor DEBE haber sido registrado previamente con el OP, ya sea mediante el parámetro de registro post_logout_redirect_uris o mediante otro mecanismo. Si se proporciona, el OP DEBE cumplir con esta solicitud luego de cerrar la sesión.

     

estado

     

OPCIONAL. Valor opaco utilizado por el RP para mantener el estado entre la solicitud de cierre de sesión y la devolución de llamada al punto final especificado por el parámetro de consulta post_logout_redirect_uri. Si se incluye en la solicitud de cierre de sesión, el OP transfiere este valor al RP utilizando el parámetro de consulta de estado al redirigir el Agente de usuario al RP.

     

En el punto final de cierre de sesión, el OP DEBE preguntar al Usuario final si también desea cerrar la sesión del OP. Si el usuario final dice "sí", entonces el OP DEBE cerrar sesión en el usuario final.

Por un lado, puedo entender por qué es conveniente que solo un usuario autenticado cierre la sesión para evitar ciertos ataques de denegación de servicio. Sin embargo, por otro lado, este proceso dejará id_tokens dispersos en los registros de cualquier servidor que registre los parámetros de la cadena de consulta.

¿Puede alguien arrojar alguna luz sobre por qué se considera una buena idea?

Gracias

    
pregunta Alex White 23.11.2016 - 12:02
fuente

1 respuesta

1

La codificación de fragmentos sí ayuda con los escenarios de registros del servidor web, pero no me atrevería a decir que se usa específicamente debido a eso.

No obstante, plantea una pregunta interesante sobre la inclusión de las credenciales del token de ID en una solicitud GET . Creo que algunas cosas pueden permitir que esto sea aceptable:

  • Si el cliente está utilizando el flujo implícito, la especificación también exige el uso de nonce y, además, menciona que debe usarse para evitar ataques de repetición. Si este es el caso, filtrar el token después de que ya se haya utilizado no debería generar un problema importante, ya que el cliente no aceptará ese token para comenzar una nueva sesión.
      

    El valor de la Reclamación de nonce DEBE comprobarse para verificar que es el mismo valor que el que se envió en la Solicitud de autenticación. El cliente DEBE verificar el valor de nonce para los ataques de reproducción . El método preciso para detectar ataques de reproducción es específico del Cliente.

  • Es muy probable que el token ya haya caducado cuando realmente se cierre la sesión, por lo que no sería posible reutilizarlo en el cliente. (el servidor de autorización lo usa solo para el contexto, por lo que no requiere estrictamente un token válido)

En general, creo que tendrá implementaciones seguras para las cuales pasar el token en esa solicitud no causará ningún daño adicional y luego tendrá otras implementaciones donde pueda resultar una amenaza importante.

Sin embargo, este rasgo no se aplica solo a esa parte específica de la especificación, es algo general ... la autenticación y la autorización son temas complejos donde los pequeños detalles causan un gran impacto y el panorama siempre está cambiando. Por eso es tan peligroso rodar tus propios sistemas de autenticación.

    
respondido por el João Angelo 23.11.2016 - 15:19
fuente

Lea otras preguntas en las etiquetas