La guía
Un «flujo» (o «grant») es la manera en que una aplicación obtiene sus tokens. Hay varios porque las aplicaciones son muy distintas: un sitio web, una aplicación móvil, una tele, un servicio sin usuario… no tienen las mismas restricciones ni los mismos secretos que proteger.
Vea también: los flujos como diagramas de secuencia · funciones avanzadas explicadas (PAR, JAR, JARM, DPoP, CIBA) · la línea de tiempo de OAuth y OpenID Connect
Todo lo demás existe por razones históricas o necesidades específicas. Refresh Token no es un flujo de inicio de sesión: es un complemento para mantener viva la sesión.
OAuth 2.0 (2012) tenía que servir tanto a servidores capaces de guardar un secreto como a aplicaciones de navegador que no pueden. De ahí implicit para las SPA, password para las aplicaciones «de confianza» y code para los servidores. Con los años quedó claro que los tokens en la URL se filtraban (implicit) y que entregar la contraseña a la aplicación anulaba todo el sentido (password). OAuth 2.1 y las recomendaciones de seguridad actuales han devuelto todo a code + PKCE, conservando client credentials y device para sus casos propios. OIDC añadió el flujo hybrid para obtener la identidad de inmediato.
Úselo cuando: una persona inicia sesión en un sitio web (con o sin servidor), una SPA, una aplicación móvil o de escritorio. Con un servidor capaz de guardar un secreto, añada el client_secret; sin él (SPA, móvil), basta PKCE.
Por qué existe: el navegador solo recibe un código de un solo uso y corta duración; los tokens van directamente del servidor de la aplicación al OP («back channel»). PKCE vincula el código a quien lo pidió, de modo que un código interceptado no sirve a nadie más.
Trampas: olvidar PKCE (ahora obligatorio incluso para clientes confidenciales), no comprobar state y nonce, aceptar redirect_uri demasiado amplios, tokens en localStorage en una SPA.
Guía paso a paso:
code_verifier (un secreto aleatorio), state, nonce, y calcula code_challenge = SHA-256(code_verifier)./authorize?response_type=code&code_challenge=…&state=…&nonce=….redirect_uri?code=…&state=…./token con el código y el code_verifier (y su secreto si lo tiene).iss, aud y nonce.Úselo cuando: la aplicación necesita la identidad de inmediato (antes del intercambio del código), por ejemplo para validar la sesión en el servidor o porque una biblioteca antigua (ASP.NET, Java EE) lo configura por defecto.
Por qué existe: OIDC quería permitir leer la identidad de inmediato sin renunciar al código para obtener los tokens de forma segura. El c_hash y el at_hash del ID token vinculan el código y el access token con esa identidad.
Trampas: tokens en el fragmento de la URL (visibles para el historial y los scripts), c_hash/at_hash sin comprobar y un nonce obligatorio olvidado. Prefiera el flujo de código simple salvo que algo se lo impida.
Guía paso a paso:
/authorize?response_type=code id_token&nonce=… (o code token, code id_token token).#code=…&id_token=…&state=… en el fragmento (response_mode=fragment por defecto) o por POST (form_post).c_hash.Úselo cuando: casi nunca en trabajos nuevos. Se encuentra en SPA antiguas, o para comprobar que una aplicación realmente lo prohíbe.
Por qué existe: antes de que los navegadores gestionaran las llamadas entre orígenes (CORS) y PKCE, una SPA no podía llamar a /token, así que se le entregaban los tokens directamente.
Trampas: el token viaja en la URL: historial, registros de proxy, cabecera Referer, extensiones. Sin refresh token, sin vinculación con quien llama. Eliminado de OAuth 2.1.
Guía paso a paso:
/authorize?response_type=id_token token&nonce=….#id_token=…&access_token=…&state=….Úselo cuando: un servicio, una tarea programada o un demonio llama a una API en su propio nombre: sincronización, tarea nocturna, microservicios que hablan entre sí.
Por qué existe: muchas llamadas a API no tienen ninguna persona detrás. El cliente demuestra su identidad (secreto o, mejor, una aserción firmada) y recibe un access token limitado a sus scopes.
Trampas: sin ID token ni refresh token (es normal). No ponga nunca este secreto en una aplicación distribuida (móvil, SPA). Conceda el mínimo de scopes y rote el secreto.
Guía paso a paso:
POST /token con grant_type=client_credentials, scope=… y la autenticación del cliente (secreto Basic o en el cuerpo).Authorization: Bearer ….Úselo cuando: quiere access tokens de corta duración (unos minutos) manteniendo a la persona conectada mucho tiempo. Se solicita con el scope offline_access.
Por qué existe: cuanto más vive un token, peor es su robo. El refresh token se queda en el lado de la aplicación, lejos de las API, y solo sirve para renovar.
Trampas: un refresh token robado significa acceso prolongado: almacenamiento seguro, rotación (uno nuevo en cada uso, el anterior queda invalidado) y detección de reutilización.
Guía paso a paso:
POST /token con grant_type=refresh_token&refresh_token=….Úselo cuando: televisor, consola, objeto conectado, impresora, herramienta de línea de comandos: el dispositivo no tiene navegador ni teclado cómodo.
Por qué existe: escribir una contraseña con un mando a distancia es penoso y arriesgado. Se muestra un código corto; la persona lo introduce en su teléfono u ordenador, donde se autentica con normalidad.
Trampas: código de corta duración y de un solo uso, sin consultar demasiado rápido (slow_down) y con límites de intentos para que un código no pueda adivinarse. El phishing es posible: muestre claramente lo que la persona está autorizando.
Guía paso a paso:
/device_authorization y recibe device_code, user_code y la dirección de verificación./token con el device_code. Primero authorization_pending y luego los tokens.Úselo cuando: conviene evitarlo. A veces se tolera para una migración desde un sistema antiguo o pruebas automatizadas en un entorno controlado.
Por qué existe: una transición para aplicaciones que ya recogían contraseñas, sin cambiar su interfaz.
Trampas: la aplicación ve la contraseña: exactamente lo que OIDC intenta evitar. Sin autenticación multifactor, sin SSO, phishing más fácil. Eliminado de OAuth 2.1.
Guía paso a paso:
POST /token con grant_type=password&username=…&password=….Todos los detalles en imágenes: diagramas de secuencia.
Pruebe cada flujo. El proveedor de pruebas de ID-Kit puede hacer todos estos flujos, con errores simulados; la aplicación de pruebas los ejecuta contra su proveedor real.