oauth 2.0 - rails - OAuth2.0 Flujo de subvención implícita. ¿Por qué usar url hash fragmentos?
omniauth rails 5 (2)
Añadiendo mis 2 centavos ..
El fragmento URI se utiliza en lugar del parámetro de consulta, desde el punto de vista de la seguridad. El segmento URI nunca se enviará a través de la red a la URL de redireccionamiento. Por ejemplo, después de iniciar sesión en el servidor de Autorización de Oauth, el encabezado de ubicación tendrá "ur url de redireccionamiento" # access_token = uraccesstoken y el código de respuesta será 302. Cuando el navegador vea el 302, redireccionará el valor del encabezado de ubicación automáticamente (el el agente de usuario lo hace automáticamente y el javascript no puede detener esto (afaik)).
Dado que es un fragmento de URI, solo el url de redireccionamiento se envía a través de la red, el fragmento de uri no lo es.
Si era un parámetro de consulta, el parámetro de consulta también se enviará a través de la red. Incluso con TLS, el parámetro de consulta será visible en sus registros de proxy, haciendo que nuestro token de acceso sea conocido por personas no intencionadas, lo que provocará una fuga del token de acceso.
Al analizar las nuevas especificaciones de OAuth2.0 (rfc 6749), veo que el flujo de trabajo del protocolo de concesión implícita utiliza fragmentos de hash de URL para intercambiar el ''access_token'' entre el servidor de autorización y el cliente público.
Ver especificaciones: http://tools.ietf.org/html/rfc6749#section-4.2
¿No se puede enviar la respuesta de concesión de autorización como ''Parámetros de consulta'' en lugar del fragmento de URL, manteniendo las otras partes del flujo como están?
¿Básicamente no puedo entender la limitación que hizo que los autores de especificaciones de OAuth2 eligieran los fragmentos de hash url para la autorización de flujo de concesión implícita?
El flujo de subvención implícita se realiza para clientes de scripts java y creo que están usando ''#'' en lugar de ''?'' para no enviar el token de acceso al lado del servidor de su URL de redireccionamiento, pero todavía es posible acceder a javascript, que en nuestro caso puede ser el cliente por razones de seguridad "no compartir su token de acceso a través de la red puede no ser seguro, como el que se usa para redirigir la URL"