Contenido del curso
Flujos de autorización en OAuth 2.0
OAuth 2.0 define varios flujos de autorización y cada uno responde a un contexto técnico distinto: si tu cliente tiene backend, si corre en el navegador, si no hay usuario o si la app es legacy. Entender estos flujos te permite elegir el correcto para proteger tokens y datos sensibles.
¿Qué roles intervienen en los flujos de OAuth 2.0?
Antes de mirar cada flujo, conviene recordar quién hace qué. En OAuth 2.0 cada acción la emite un actor específico y los colores de los diagramas suelen seguir esa lógica [1:00].
En muchas implementaciones el authorization server y el resource server pertenecen a la misma entidad, así que no te confundas si los ves operando juntos.
¿Cómo funciona el authorization code flow?
Es el flujo más común y el que deberías usar por defecto cuando tu aplicación tiene backend [1:30]. Se caracteriza por un intercambio: cambias un código por un token.
El usuario hace clic en conectar (con Discord, Google, Facebook) y el cliente envía un authorization request al authorization server con parámetros como el client ID, el tipo de respuesta y los scopes. Si no hay sesión, aparece la pantalla de login y luego la de request consent, donde el usuario autoriza o deniega.
Cuando autoriza, se genera un authorization grant y el servidor devuelve un authorization code. El cliente entonces hace un client authentication enviando client ID y client secret junto con ese código. Esa petición debe ocurrir en el backend, porque el client secret nunca debe exponerse. El servidor valida y devuelve un access token que el cliente usa para pedir recursos al resource server.
¿Qué es un authorization grant? Es el permiso explícito del usuario tras hacer clic en autorizar. Ese consentimiento desencadena la emisión de un código que luego se intercambia por un token.
¿Cuándo debo usar PKCE en lugar del flujo estándar?
El authorization code flow with proof key for code exchange (PKCE) está diseñado para clientes que no pueden almacenar secretos de forma segura, como una single page app o una aplicación nativa [4:30].
¿Qué hace especial al hashing en PKCE?
PKCE se apoya en el hashing, un proceso que, a diferencia del encoding, no es reversible. Tomas una cadena (el code verifier), aplicas un algoritmo y obtienes un code challenge del que no puedes recuperar el original. Así se almacenan hoy las contraseñas: si alguien hackea la base de datos, no puede revertir el hash.
¿Cómo se integra el code verifier en el flujo?
Antes del authorization request, el cliente genera tres cosas en memoria: un code verifier aleatorio, un método de hashing y el code challenge. Envía el método y el challenge al inicio. Más adelante, en lugar de mandar client ID y client secret, envía el code verifier original junto con el código. El servidor aplica el método al verifier y comprueba que el resultado coincida con el challenge inicial.
Esa verificación garantiza que el cliente siempre fue el mismo y que no hubo un ataque man in the middle. Por eso este intercambio puede ocurrir incluso en un canal menos seguro como el frontend.
¿Por qué el implicit flow ya no se recomienda?
El implicit flow solía ser el favorito de las single page app, pero hoy se considera inseguro [7:30]. No hay intercambio de código: cuando el usuario autoriza, el servidor valida el client ID y devuelve directamente el access token en el fragment de la URL.
La parte protectora es que el fragment no se guarda en el historial y el servidor solo envía el token a una URL previamente registrada. Pero si el cliente tiene cualquier vulnerabilidad, el flujo se rompe y deja de ser seguro. Muchos authorization servers aún lo permiten, así que conócelo, pero evítalo.
¿Qué flujo elijo si no hay un usuario humano?
Ahí entra el client credentials flow, donde el resource owner es el propio cliente [9:00]. No hay pantalla de consentimiento ni redirecciones. El cliente, que corre en un ambiente seguro, envía solo client ID y client secret; el servidor valida y devuelve un access token de inmediato. Es ideal para integraciones servidor a servidor.
¿Y el resource owner password flow cuándo aplica?
Este flujo existe para aplicaciones legacy que no pueden hacer redirecciones [9:50]. El usuario entrega su usuario y contraseña directamente al cliente, que los envía al authorization server por HTTPS. Si valida, el servidor devuelve un access token.
Solo tiene sentido cuando el authorization server es dueño de los usuarios y la app es de confianza absoluta. Compartir credenciales con una app tercera es problemático y por eso este flujo está reservado a casos legacy.
¿Cuál es el flujo más recomendado en OAuth 2.0? El authorization code flow con backend, o su variante PKCE cuando el cliente no puede guardar secretos. Los demás se reservan a casos muy específicos.
¿Cómo decidir rápido entre los flujos de OAuth 2.0?
Una síntesis útil para tener a mano [11:30]:
Deja en los comentarios tu propia analogía de los roles y flujos de OAuth 2.0. ¿Cómo se la explicarías a alguien que nunca ha tocado autenticación?
