Contenido del curso
Qué es el hybrid flow en OpenID Connect
El hybrid flow combina lo mejor de authorization code flow e implicit flow en OpenID Connect. Si tu aplicación necesita acceder rápido al perfil del usuario y, al mismo tiempo, mantener un intercambio seguro de tokens, este flujo te interesa. Aquí entiendes cómo funciona, cuándo conviene y qué necesitas para implementarlo.
Cómo funciona el hybrid flow paso a paso
La lógica del hybrid flow se entiende mejor si lo piensas como dos flujos encadenados que comparten una sola autorización del usuario.
Todo arranca cuando el usuario hace clic en conectar. El cliente envía un authorization request al authorization server, que valida si existe sesión activa. Si no la hay, muestra la pantalla de login y luego el request consent, donde el usuario autoriza el acceso.
Ahí está el giro: en lugar de devolver solo un código, el authorization server responde con tres cosas a la vez.
Con ese ID token y ese access token inicial, tu cliente ya puede mostrar el perfil del usuario sin esperar más. Es como si la autenticación hubiera quedado resuelta en el primer paso.
¿Para qué sirve el ID token en hybrid flow? Sirve para que el cliente identifique al usuario de inmediato y muestre su información, sin esperar al intercambio del código por el access token completo.
Qué pasa en el segundo intercambio
Después, el cliente hace un nuevo request al authorization server, esta vez enviando el client ID, el client secret y el authorization code. El servidor valida que tanto el código como las credenciales del cliente sean correctas.
Si todo cuadra, devuelve de nuevo un ID token y un access token, pero ahora con los permisos actualizados y el alcance completo. Con ese access token tu cliente ya puede consumir la API normalmente, igual que en cualquier otro flujo de OAuth.
Cuándo conviene usar hybrid flow en una aplicación
Este flujo no es para todos los casos. Tiene sentido cuando tu aplicación necesita acceder rápido a la información del usuario y, además, requiere mantener una comunicación segura con el backend para llamadas posteriores a la API.
Un detalle no negociable: el cliente debe poder almacenar secretos. En el segundo paso ocurre un client authentication que exige el client ID y el client secret. Si tu aplicación corre completamente en el navegador o en un dispositivo donde no puedes proteger esas credenciales, hybrid flow no es tu opción.
¿Qué diferencia al hybrid flow del authorization code flow? El hybrid flow entrega un ID token en el primer paso junto al código, mientras que el authorization code flow solo entrega el código y obliga a esperar el intercambio para conocer al usuario.
Cómo implementar hybrid flow con Curity
Para practicar este flujo existe Curity, un servicio que actúa como authorization server y soporta hybrid flow de forma nativa.
La diferencia con plataformas como Auth0, Okta o Amazon Cognito es clave: Curity requiere instalación local. No basta con crear un usuario en una consola web y conectarte. Tienes que seguir un conjunto de instrucciones de instalación y configuración antes de poder probarlo.
Si quieres ensayar por tu cuenta, busca la documentación de Curity en los enlaces del módulo. Ahí encuentras todo lo necesario para levantarlo en tu entorno y disparar un hybrid flow real de principio a fin.
¿Qué es Curity? Es un authorization server de instalación local que soporta OAuth y OpenID Connect, incluido el hybrid flow, y se usa cuando necesitas control total sobre la infraestructura de autenticación.
El reto para cerrar el módulo es que implementes hybrid flow usando Curity o el servicio que prefieras. Cuéntame en los comentarios qué herramienta elegiste y cómo te fue con el primer intercambio de tokens.
