¿Por qué hay un flujo de "Código de autorización" en OAuth2 cuando el flujo "Implícito" funciona tan bien?

Question

¿Por qué hay un flujo de "Código de autorización" en OAuth2 cuando el flujo "Implícito" funciona tan bien?

Con el flujo "Implícito" el cliente (probablemente un navegador) obtendrá un token de acceso, después de que el Propietario del Recurso (es decir, el usuario) haya dado acceso.

Con el flujo de "Código de Autorización", sin embargo, el cliente (generalmente un servidor web) solo obtiene un código de autorización después de que el Propietario del Recurso (es decir, el usuario) haya dado acceso. Con ese código de autorización, el cliente realiza otra llamada a la API pasando client_id y client_secret junto con el código de autorización para obtener el token de acceso. Todo bien descrito aquí.

Ambos flujos tienen exactamente el mismo resultado: un token de acceso. Sin embargo, el flujo "Implícito" es mucho más simple.

La pregunta: ¿Por qué molestarse con el flujo de "Código de autorización", cuando el flujo "Implícito" parece estar bien? ¿Por qué no usar también "Implicit" para el servidor web?

Es más trabajo tanto para el proveedor como para el cliente.

175

authentication oauth oauth-2.0

Author: itsadok, 2012-11-15

Source

3 answers

El Flujo Implícito hace que todo el flujo sea bastante fácil, pero también menos seguro.
Como la aplicación cliente, que normalmente es JavaScript que se ejecuta dentro de un navegador, es menos confiable, no se devuelven tokens de actualización para el acceso de larga duración.
Debe usar este flujo para aplicaciones que necesitan acceso temporal (unas pocas horas) a los datos del usuario.
Devolver un token de acceso a clientes JavaScript también significa que su aplicación basada en navegador debe tener especial cuidado: piense en XSS Ataques que podrían filtrar el token de acceso a otros sistemas.

Https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow

7

Author: lakesare,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-10-02 17:44:04

Del párrafo 4.2 de OAuth spec :

El tipo de concesión implícita se utiliza para obtener tokens de acceso (no admite la emisión de tokens de actualización) y está optimizado para clientes públicos conocidos por operar un URI de redirección particular. Estos clientes generalmente se implementan en un navegador utilizando un lenguaje de scripting como JavaScript.

Como flujo basado en la redirección, el cliente debe ser capaz de interactuar con el agente de usuario del propietario del recurso (normalmente un navegador web) y capaz de recibir solicitudes entrantes (a través de redirección) desde el servidor de autorización.

A diferencia del tipo de concesión de código de autorización en el que el cliente realiza solicitudes separadas de autorización y token de acceso, el cliente recibe el token de acceso como resultado de la solicitud de autorización.

El tipo de concesión implícita no incluye la autenticación del cliente, y se basa en la presencia del propietario del recurso y el registro del URI de redirección. Porque el token de acceso está codificado en el URI de redirección, puede estar expuesto al propietario del recurso y otras aplicaciones que residen en el mismo dispositivo.

Así que lo que podemos pensar:

Esto es para OAuth público, es decir, cuando el cliente no necesita ser registrado y no tiene sus propios secretos de cliente. Pero lo que auth server comprueba url de redirección y esto es realmente suficiente para la seguridad.
El token de acceso se produce en la barra de direcciones del navegador para que el usuario pueda copiar la url y enviar a alguien más y también se registra como el usuario, es decir, es algo así como la fijación de la sesión. Pero el navegador realiza una redirección adicional con la sustitución del historial para eliminar el fragmento de hash de la url. También es posible que un hacker robe el token de acceso olfateando un tráfico HTTP, pero esto puede ser fácilmente protegido por HTTPS. Algunas extensiones de navegador malintencionadas pueden tener acceso a las URL desde la barra de direcciones, pero en última instancia, esta es una mala situación, como el certificado HTTPS roto. E incluso el flujo de código de autenticación no puede ayudar aquí éter. Así que lo que puedo ver es que pasar el token de acceso a través del fragmento de hash de la url es absolutamente seguro.
La separación del token de acceso efímero y el token de actualización son inútiles cuando se usa un HTTPS y, para ser honesto, no es tan útil incluso en HTTP raw. Pero el hecho de que el cliente a través de flujo implícito no pueda recibir el token de actualización también es una tontería.

Por lo tanto, creo que deberíamos introducir un nuevo flujo de concesión "implícito seguro" que funciona estrictamente sobre https, permite actualizar token (o deberíamos deshacernos de ellos en absoluto), y es preferible que Auth Cose grant flow

0

Author: stokito,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-04-24 08:44:34

score 206 · Accepted Answer

Tl; dr: Todo esto se debe a razones de seguridad.

OAuth 2.0 quería cumplir estos dos criterios:

Desea permitir que los desarrolladores utilicen URI de redirección no HTTPS porque no todos los desarrolladores tienen un servidor habilitado para SSL y, si lo hacen, no siempre está configurado correctamente (certificados SSL de confianza no firmados por ellos mismos, reloj del servidor sincronizado)...).
No desea que los hackers puedan robar tokens de acceso/actualización interceptando peticiones.

Detalles a continuación:

El flujo implícito solo es posible en un entorno de navegador por razones de seguridad:

En el flujo implícito el token de acceso se pasa directamente como un fragmento hash (no como un parámetro URL). Una cosa importante sobre hash fragment es que, una vez que sigues un enlace que contiene un fragmento hash, solo el navegador es consciente del fragmento hash. Los navegadores pasarán el fragmento hash directamente a la página web de destino (el URI de redirección / la página web del cliente). Hash fragment tiene las siguientes propiedades:

No son parte de la solicitud HTTP, por lo tanto, no pueden ser leídos por los servidores y por eso no pueden ser interceptados por servidores/routers intermediarios (esto es importante).
Solo existen en el lado del cliente del navegador, por lo que la única forma de leer el fragmento de hash es usando JavaScript que se ejecuta en la página.

Esto hace posible pasar un Token de acceso directamente al cliente sin el riesgo de que sea interceptado por un servidor intermediario. Esto tiene la advertencia de que solo es posible en el lado del cliente y necesita que javascript ejecute el lado del cliente para usar el token de acceso.

En el flujo de código de autorización no es posible pasar un token de acceso directamente en un parámetro de URL porque los parámetros de URL son parte de la Solicitud HTTP, por lo tanto, cualquier servidor intermediario/enrutadores por los que pasaría su solicitud (podrían ser cientos) podría leer el token de acceso si no está utilizando una conexión cifrada en (HTTPS) que permite lo que se conoce como ataques Man-in-the-middle.

Pasar el token de acceso directamente en un parámetro de URL podría en teoría ser posible, pero el servidor de autenticación tendría que asegurarse de que el URI de redirección está utilizando HTTPS con cifrado TLS y un certificado SSL 'de confianza' (normalmente de una Autoridad de Certificación que no es libre) para asegurarse de que el servidor de destino es legítimo y que la solicitud HTTP está completamente encriptada. Hacer que todos los desarrolladores compren un certificado SSL y configuren correctamente SSL en su dominio sería un gran dolor y ralentizaría enormemente la adopción. Esta es la razón por la que un intermediario de un solo uso "código de autorización" se proporciona que solo el receptor legítimo será capaz de intercambiar (porque necesita el secreto del cliente) y que el código será inútil para los piratas informáticos potenciales que intercepten las solicitudes sobre transacciones no cifradas (porque no conocen el secreto del cliente).

Usted también podría argumentar que el flujo implícito es menos seguro, hay vectores de ataque potenciales como la suplantación del dominio al redirigir - por ejemplo, mediante el secuestro de la dirección IP del sitio web del cliente. Esta es una de las razones por las que el flujo implícito solo otorga tokens de acceso (que se supone que tienen un uso de tiempo limitado) y nunca actualiza tokens (que son ilimitados en el tiempo). Para solucionar este problema, le aconsejo que aloje sus páginas web en un servidor habilitado para HTTPS siempre que sea posible.