Tipo de concesión Implicit en OAuth 2.0

El Tipo de Concesión Implicit, también conocido como el método "token", fue diseñado principalmente para aplicaciones del lado del cliente donde el cliente no puede almacenar de forma segura un secreto de cliente. Tales aplicaciones incluyen aplicaciones de página única (SPA) u otras aplicaciones basadas en navegador. En lugar de recibir un código de autorización que necesita ser intercambiado por un token de acceso, la aplicación obtiene el token de acceso directamente.

Las recomendaciones de seguridad actuales (RFC 9700) dicen que NO se DEBERÍA usar la concesión implicit. Prefiere la concesión Authorization Code con PKCE.

Qué introduces en LoadFocus

En una prueba de carga, establece Tipo de autorización en OAuth 2.0 y Grant Type en Implicit. El formulario tiene estos campos:

• Token Name: una etiqueta para ti. No se envía al servidor.
• Callback URL, Auth URL: el URI de redirección registrado para tu cliente y el endpoint de autorización del proveedor.
• Client ID, Client Secret, Scope, State, Audience: tal como los emite o acuerda tu proveedor.

LoadFocus no abre un navegador ni envía a ningún usuario a la Auth URL, por lo que no puede completar el paso de redirección del que depende esta concesión.

¿Cómo Funciona el Tipo de Concesión Implicit?

1. Redirección:

• La aplicación cliente redirige al usuario al endpoint de autorización del servidor de autorización OAuth 2.0. Esta redirección generalmente incluye parámetros de consulta como client_id, response_type (establecido en "token" para la Concesión Implicit), redirect_uri (donde el servidor de autorización redirigirá después de conceder/denegar el acceso), y scope (indicando el nivel de acceso solicitado).

2. Autenticación del Usuario:

• El usuario inicia sesión en el servidor de autorización (si no ha iniciado sesión ya) y revisa la solicitud de acceso de la aplicación cliente.

3. Emisión del Token de Acceso:

• Si el usuario concede el acceso, el servidor de autorización lo redirige de vuelta a la aplicación cliente a través del redirect_uri proporcionado. El URI de redirección incluye el token de acceso (y su expiración) directamente en la parte del fragmento de la URL.

4. Acceder al Recurso Protegido:

• La aplicación cliente extrae el token de acceso del fragmento de la URL y lo almacena (por ejemplo, en almacenamiento local o una sesión). Luego usa este token para hacer solicitudes al servidor de recursos (API) en nombre del usuario.

¿Cómo Configurar el Tipo de Concesión Implicit?

1. Registrar Tu Aplicación:

• Comienza registrando tu aplicación con el proveedor OAuth 2.0. Típicamente recibirás un client_id después del registro exitoso.

2. Configuración del URI de Redirección:

• Proporciona un redirect_uri durante el registro. El servidor de autorización redirigirá a los usuarios a este URI después de que decidan conceder o denegar el acceso. Asegúrate de que este URI sea seguro (típicamente usando HTTPS) y pueda manejar la extracción del token del fragmento de la URL.

3. Iniciar el Flujo OAuth:

• Redirige a los usuarios al endpoint de autorización del servidor de autorización con los parámetros necesarios. Usa bibliotecas o SDKs adecuados al lenguaje o framework de tu aplicación para facilitar esto.

4. Extraer y Almacenar el Token:

• Una vez redirigido de vuelta, extrae el token de acceso del fragmento de la URL. Almacena el token de forma segura, considerando opciones de almacenamiento del lado del cliente como Web Storage (localStorage o sessionStorage) o cookies. Asegúrate de que esté protegido contra ataques de cross-site scripting (XSS).

5. Usar el Token:

• Adjunta el token de acceso a las solicitudes de API hechas al servidor de recursos.

6. Manejar la Expiración del Token:

• La Concesión Implicit nunca devuelve un token de actualización (RFC 6749, sección 4.2.2), así que cuando un token de acceso expira tienes que ejecutar de nuevo el flujo OAuth para obtener uno nuevo.

Consideraciones:

• Seguridad: El Tipo de Concesión Implicit se considera menos seguro que el Tipo de Concesión Authorization Code, especialmente porque el token de acceso está expuesto en la URL. Esto podría ser un riesgo en entornos donde las URLs pueden ser registradas o accedidas por terceros.

• Sin Refresh Token: el servidor de autorización no debe emitir ninguno para esta concesión, así que todo el flujo se repite cuando el token de acceso expira.

• Evítala: Por estas preocupaciones de seguridad, el documento de Mejores Prácticas de Seguridad de OAuth 2.0 (RFC 9700) dice que NO se DEBERÍA usar la Concesión Implicit, y recomienda la concesión Authorization Code con PKCE (Proof Key for Code Exchange) para clientes públicos, como las SPA.

Conclusión:

Aunque el Tipo de Concesión Implicit ofrece un flujo más simple para aplicaciones del lado del cliente, sus preocupaciones de seguridad han llevado a recomendaciones en contra de su uso en aplicaciones modernas. Si estás construyendo nuevas aplicaciones, especialmente SPAs, considera usar la Concesión Authorization Code con PKCE para un enfoque más seguro.