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.

¿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:

• Dado que la Concesión Implicit generalmente no proporciona tokens de actualización, cuando un token de acceso expira, podrías necesitar iniciar el flujo OAuth nuevamente 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: Típicamente, la Concesión Implicit no proporciona tokens de actualización. Por lo tanto, cuando un token de acceso expira, todo el flujo podría necesitar repetirse.

• Deprecación: Debido a sus preocupaciones inherentes de seguridad, el documento de Mejores Prácticas de Seguridad de OAuth 2.0 recomienda evitar la Concesión Implicit en favor del Authorization Code con PKCE (Proof Key for Code Exchange) para clientes públicos, como SPAs.

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.