Elegir el flujo adecuado de OAuth 2.0 depende de dos roles principales: el cliente (tu aplicación) y el resource server (la API protegida). Si entiendes esa relación, puedes responder una serie de preguntas que te llevan al flujo correcto sin caer en errores de seguridad. Esta guía es para desarrolladores que están implementando autorización y necesitan tomar decisiones técnicas con criterio.

¿Cuándo usar Client Credentials Flow en OAuth 2.0?

La primera pregunta que debes hacerte es si el cliente y el resource owner son la misma entidad. Si tu aplicación es la dueña de los recursos y no hay un usuario humano involucrado, entonces el camino es Client Credentials Flow.

Este flujo aplica muy bien cuando una API externa de tu propia organización necesita consumir otra API tuya, o cuando trabajas con herramientas de línea de comandos que viven dentro de un entorno seguro. Aquí no hay usuario, hay sistemas hablando entre sistemas.

¿Qué es Client Credentials Flow? Es el flujo de OAuth donde la aplicación se autentica directamente con el authorization server usando sus propias credenciales, sin involucrar a un usuario. Se usa para comunicación segura entre servicios. [03:10]

¿Qué flujo elegir si tu cliente es una web app o legacy?

Si descartaste Client Credentials, la siguiente pregunta es si tu cliente es una web app que corre en el servidor. Cuando la respuesta es sí, usa Authorization Code Flow, que es el flujo por excelencia y cubre la mayoría de los casos reales.

¿Cuándo recurrir a Resource Owner Password Flow?

Si tu cliente no es una web app server side, pregúntate si le confías al cliente las credenciales del usuario. Solo en ese caso usarías Resource Owner Password Flow, donde el usuario entrega su usuario y contraseña directamente a la aplicación.

Este flujo es un último recurso. Está pensado para sistemas legados que no soportan redirecciones. Si puedes evitarlo, evítalo. La razón es simple: cualquier flujo donde la aplicación toca las credenciales del usuario abre puertas a problemas de seguridad.

¿Y si trabajas con apps nativas o single page apps?

Cuando el cliente es una app de escritorio, mobile o una single page app, lo ideal es Authorization Code Flow con PKCE (Proof Key for Code Exchange). Estos clientes no pueden almacenar de forma segura un client secret, y PKCE resuelve precisamente eso al añadir un mecanismo dinámico de verificación.

Una alternativa es Implicit Flow con PKCE, pero solamente dentro del contexto de OpenID Connect. No lo uses para autorización pura.

¿Cómo manejar OAuth en single page apps sin morir en el intento?

Las single page apps son el escenario más espinoso de OAuth. Durante años se recomendó Implicit Flow para ellas, pero hoy esa recomendación quedó obsoleta porque su implementación segura no es trivial y arrastra demasiados riesgos.

Estos son los pasos que recomienda la clase, en orden de preferencia:

• Implementa un backend. Muchas SPA ya tienen server side rendering o un backend for frontend, así que aprovéchalo.
• Si no puedes, usa Authorization Code Flow con PKCE.
• Si solo necesitas OpenID Connect, puedes usar Implicit Flow con PKCE, aunque también requiere algo de backend.
• Como último recurso, Implicit Flow puro, asumiendo todos los retos de seguridad.

Entre medias existe el Hybrid Flow, una combinación entre Implicit Flow (idealmente con PKCE) y Authorization Code Flow. Se considera seguro y aparece como salida cuando los flujos anteriores no son viables en tu contexto.

¿Por qué ya no se recomienda Implicit Flow? Porque entrega el access token directamente al navegador, lo que abre la puerta a fugas en logs, historial y scripts de terceros. Hoy se prefiere Authorization Code Flow con PKCE. [05:50]

¿Qué papel juega PKCE en la seguridad de OAuth?

Proof Key for Code Exchange es la pieza que hace seguros los flujos donde no puedes guardar un client secret. Funciona generando un valor dinámico (un code verifier y su code challenge) que el cliente envía al authorization server para demostrar que es el mismo que inició el flujo.

Esto cierra una vulnerabilidad clásica: que alguien intercepte el authorization code y lo intercambie por un token. Con PKCE, sin el verifier original, el código robado no sirve.

¿Qué hace PKCE diferente? Reemplaza el client secret estático por un secreto dinámico generado en cada solicitud, ideal para apps nativas y SPAs. [04:30]

Conceptos clave que aparecen en la decisión del flujo

Para cerrar el mapa mental, vale la pena ubicar los términos que se cruzan a lo largo del proceso:

• Authorization server: la API que emite y valida tokens [00:20].
• Resource server: los endpoints que consumes con el token [00:25].
• Resource owner: el usuario dueño de los recursos [00:23].
• Client: la aplicación que solicita acceso [00:18].
• Client secret: credencial estática que las SPA y apps nativas no pueden proteger [04:35].
• Backend for frontend: capa de servidor pensada para apoyar a una SPA en tareas como manejar tokens [06:40].

La versatilidad de OAuth viene precisamente de tener flujos diseñados para distintas limitantes técnicas. La clave está en hacerte las preguntas correctas en orden y resistir la tentación de saltarte la seguridad por comodidad.

¿Cómo armarías tú un sistema de preguntas para elegir el flujo correcto? Compártelo en los comentarios.