Implementación de flujos OAuth 2.0 con APIs populares

Comprender cómo funciona OAuth 2.0 es fundamental para cualquier persona que trabaje con aplicaciones que necesitan acceder a recursos de terceros de forma segura. Este protocolo es el estándar de la industria para implementar autorización, y conocer sus roles, terminología y canales de comunicación marca la diferencia entre una integración sólida y una vulnerable.

¿Qué es OAuth 2.0 y por qué es el estándar de autorización?

Open Authorization (OAuth) se centra exclusivamente en la autorización, no en la autenticación. Su propósito es permitir que un usuario otorgue permisos a una aplicación de terceros para que acceda a sus recursos, sin necesidad de compartir credenciales directamente [0:42].

El módulo donde se profundiza en este protocolo contempla la implementación de cinco flujos distintos, cada uno con un caso de uso particular:

• Authorization Code Flow usando Spotify.
• Authorization Code Flow con Proof Key for Code Exchange (PKCE) mediante Twitter.
• Implicit Flow usando Twitch.
• Client Credentials mediante Discord.
• Resource Owner Password Flow con Auth0.

¿Cuáles son los cuatro roles fundamentales de OAuth 2.0?

OAuth define cuatro roles que participan en cada flujo de autorización [1:30]:

• Cliente: es la aplicación que solicita acceso. Puede ser una app web, móvil o incluso una aplicación nativa de escritorio.
• Authorization server: una API responsable de firmar y verificar tokens, además de mostrar la pantalla de consent request donde el usuario decide si otorga los permisos solicitados.
• Resource owner: el usuario final. Es quien hace clic en "autorizar" y decide qué permisos conceder.
• Resource server: el servidor que aloja los endpoints con los recursos protegidos, a los que se accede mediante el token.

Un detalle importante: el token que devuelve el authorization server no siempre es un JSON Web Token (JWT). Según la especificación de OAuth, esto es completamente opcional. Sin embargo, para OpenID Connect, sí es obligatorio que sea un JWT [2:38].

¿Qué términos del request necesitas conocer?

Durante la implementación aparecen constantemente estos conceptos asociados a la solicitud de autorización [3:06]:

• URL de redirección: la dirección a la que el authorization server envía la respuesta después de que el usuario autoriza.
• Consent request: la página donde se listan los permisos solicitados y el usuario decide si los aprueba.
• Scopes: los permisos específicos que la aplicación necesita. Es importante leerlos porque podrían otorgar acceso de más al aplicativo.
• Authorization grant: un código temporal que devuelve el authorization server tras la aprobación del usuario. No es un token, es simplemente un código.

¿Qué papel juegan el client ID, client secret y los tokens?

El segundo grupo de términos clave incluye las credenciales del cliente y los tokens [3:40]:

• Client ID y client secret: funcionan como el usuario y contraseña de la aplicación registrada ante el authorization server. El client ID puede exponerse en el frontend sin problema, pero el client secret debe permanecer protegido.
• Access token: el token que permite acceder a los recursos protegidos.
• ID token: un token especial utilizado en el flujo de OpenID Connect.

¿Cómo funciona el flujo completo con un ejemplo real como Discord?

Al hacer clic en "conectar con Discord", se dispara una authorization request que puede ocurrir desde el frontend [4:10]. Esta solicitud incluye la URL de redirección, los scopes y el client ID, ninguno de estos datos es secreto.

El authorization server verifica si existe sesión activa. Si no la hay, solicita login; si la hay, muestra directamente el consent request con los scopes requeridos. Cuando el resource owner hace clic en autorizar, recibe un código (el authorization grant) en la URL de redirección [4:52].

Aquí viene la parte crítica: el cliente envía ese código junto con el client ID y el client secret al authorization server. Este intercambio debe ocurrir exclusivamente en el backend, ya que tanto el código como el client secret son información sensible [5:15].

Una vez validado todo, el authorization server devuelve un access token. A partir de ese momento, la aplicación lo envía en el header como Authorization Bearer para consumir los endpoints del resource server.

Es habitual que el authorization server y el resource server sean la misma entidad, como ocurre con Discord. Sin embargo, el authorization server también podría ser un servicio externo como Auth0, Okta o Amazon Cognito [5:52].

Si ya tienes clara la diferencia entre los canales frontend y backend en este flujo, comparte en los comentarios qué cambió entre OAuth 1.0 y OAuth 2.0, y por qué crees que fue necesaria esa evolución.