OAuth: una rápida visión general - Parte II

La primera parte del contenido introduce OAuth, su propósito, los roles, los tipos de concesión, los tokens portadores y JWT, y un poco del proyecto OAuth 2.1. A continuación, demostraré cómo funcionan los flujos de autorización (tipos de concesión).

Credenciales de los clientes

Las credenciales de cliente se utilizan cuando los clientes (aplicaciones) solicitan un token para acceder a sus propios recursos en su nombre, no en nombre del usuario. Estos clientes suelen ser aplicaciones máquina a máquina (M2M), como CLIs, daemons o servicios que se ejecutan en el backend. Por lo tanto, este flujo sólo debe utilizarse para clientes de confianza. Así es como funciona.

1. La aplicación (m2m app) envía una solicitud (/oauth/token) al servidor OAuth con el ID del cliente + el secreto del cliente.
2. El servidor OAuth valida el ID del cliente + el secreto del cliente.
3. El servidor OAuth responde con el token de acceso.
4. La aplicación utiliza el token para llamar a la API.
5. La API responde con los datos solicitados.

Código de autorización + PKCE

Este flujo se utiliza para obtener un token de acceso a través de un código de autorización. Aquí hablamos tanto de aplicaciones de confianza como de aplicaciones públicas, ya sean web, móviles o nativas. 

A diferencia de las Credenciales de Cliente, en este caso el propietario del recurso es un usuario final, por lo que la aplicación necesita abrir el navegador para iniciar el flujo. Como se trata de aplicaciones públicas, se requieren algunas medidas de seguridad adicionales. Por eso tenemos la Clave de Prueba para el Intercambio de Códigos o PKCE(RFC 7636). Se trata de una extensión del flujo del Código de Autorización que evita los ataques de inyección y CSRF creando una "combinación" con cada solicitud de autorización, y junto con esta combinación y el código de autorización, solicita un token de acceso. Véase la imagen siguiente.

1. El usuario se conecta a la aplicación.
2. La aplicación crea un code_verifier y genera el code_challenge a partir de él.
3. La aplicación envía una solicitud (/authorize) al servidor OAuth utilizando code_challenge.
4. El Servidor OAuth redirige al usuario para que se registre y solicite autorización.
5. El usuario se autentifica/proporciona su consentimiento.
6. El servidor OAuth guarda code_challange y redirige al usuario a la aplicación con un código de autorización.
7. La aplicación envía una solicitud (/oauth/token) con el código de autorización + code_verifier al servidor OAuth.
8. El servidor OAuth valida el code_challenge (enviado en el paso 3) y el code_verifier (enviado en el paso 7).
9. El servidor OAuth responde con el token de acceso.
10. La aplicación utiliza el token para llamar a la API.
11. La API responde con los datos solicitados

El protocolo recomienda el uso de Credenciales de Cliente para aplicaciones M2M y Código de Autorización + PKCE para otros tipos de aplicaciones. Como expliqué en la parte I, mi intención con estos dos artículos era proporcionar una rápida visión general de OAuth. Espero haberlo conseguido. Gracias de nuevo a todos los que han nacido conmigo hasta aquí. Hasta la vista.