OpenID Connect · OAuth 2.0

Los flujos en diagramas

Quién habla con quién, en qué orden. Las líneas continuas son solicitudes, las punteadas son respuestas. Para elegir, empiece por ¿Qué flujo elegir?

Authorization Code + PKCE · Hybrid (code id_token, code token…) · Implicit (id_token, id_token token) · Refresh Token · Client Credentials · Password (ROPC) · Device Code (RFC 8628) · Token exchange (RFC 8693) · Logout (iniciado por el RP y back-channel) · Introspección y revocación · private_key_jwt y JWT Bearer (RFC 7523) · PAR y JAR (RFC 9126 y 9101) · JARM (respuesta de autorización firmada) · DPoP (RFC 9449) · CIBA (Client-Initiated Backchannel)

Authorization Code + PKCE Recomendado

El flujo estándar: el navegador solo ve un código de un solo uso; los tokens van de servidor a servidor.

NavegadorApplicationProveedor (OP)API1. Genera code_verifier,state, nonce2. 302 a /authorize(challenge, state, nonce)3. GET /authorize4. Página de inicio de sesión y consentimiento5. Credenciales y consentimiento de la persona6. 302 redirect_uri?code=…&state=…7. GET /callback?code=…&state=…8. POST /token (code,code_verifier, secret)9. ID token + access token (+refresh token)10. Verifica la firma, iss,aud, nonce11. Authorization: Bearer access_token12. Datos solicitados
Versión en texto del diagrama
  1. Aplicación: Genera code_verifier, state, nonce
  2. Aplicación → Navegador : 302 a /authorize (challenge, state, nonce)
  3. Navegador → Proveedor (OP) : GET /authorize
  4. Proveedor (OP) → Navegador: Página de inicio de sesión y consentimiento
  5. Navegador → Proveedor (OP): Credenciales y consentimiento de la persona
  6. Proveedor (OP) → Navegador : 302 redirect_uri?code=…&state=…
  7. Navegador → Aplicación : GET /callback?code=…&state=…
  8. Aplicación → Proveedor (OP) : POST /token (code, code_verifier, secret)
  9. Proveedor (OP) → Aplicación : ID token + access token (+ refresh token)
  10. Aplicación: Verifica la firma, iss, aud, nonce
  11. Application → API : Authorization: Bearer access_token
  12. API → Aplicación: Datos solicitados

Úselo cuando: Cualquier sitio web, aplicación móvil, SPA o aplicación de escritorio donde una persona inicia sesión.

Lo que lo distingue: Es la base. Todos los demás flujos son una variante o un caso particular de este.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Hybrid (code id_token, code token…) Casos específicos

La identidad se recibe de inmediato en el navegador, y el código para obtener los tokens de forma segura.

NavegadorApplicationProveedor (OP)1. 302 a /authorize(response_type=code id_token)2. GET /authorize y luego inicio de sesión3. 302 redirect_uri#code=…&id_token=…&state=…4. Un script lee el fragmentoy lo reenvía5. POST /callback (code,id_token, state)6. Verifica id_token y c_hash7. POST /token (code,code_verifier)8. access token (+ refreshtoken)
Versión en texto del diagrama
  1. Aplicación → Navegador : 302 a /authorize (response_type=code id_token)
  2. Navegador → Proveedor (OP) : GET /authorize y luego inicio de sesión
  3. Proveedor (OP) → Navegador : 302 redirect_uri#code=…&id_token=…&state=…
  4. Navegador: Un script lee el fragmento y lo reenvía
  5. Navegador → Aplicación : POST /callback (code, id_token, state)
  6. Aplicación: Verifica id_token y c_hash
  7. Aplicación → Proveedor (OP) : POST /token (code, code_verifier)
  8. Proveedor (OP) → Aplicación : access token (+ refresh token)

Úselo cuando: Una aplicación que debe conocer a la persona antes de intercambiar el código (validación de sesión en el servidor, bibliotecas antiguas).

Lo que lo distingue: Como el flujo de código, pero el ID token llega directamente en la redirección (con c_hash que lo vincula al código).

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Implicit (id_token, id_token token) Desaconsejado

Los tokens llegan directamente en la dirección: más sencillo, pero expuesto.

Navegador (SPA)Proveedor (OP)API1. Genera state y nonce2. GET /authorize(response_type=id_token token)3. 302redirect_uri#id_token=…&access_token=…4. Lee el fragmento, verifica eltoken5. Authorization: Bearer access_token
Versión en texto del diagrama
  1. Navegador (SPA): Genera state y nonce
  2. Navegador (SPA) → Proveedor (OP) : GET /authorize (response_type=id_token token)
  3. Proveedor (OP) → Navegador (SPA) : 302 redirect_uri#id_token=…&access_token=…
  4. Navegador (SPA): Lee el fragmento, verifica el token
  5. Navegador (SPA) → API : Authorization: Bearer access_token

Úselo cuando: Casi nunca. Solo para SPA antiguas o para comprobar que una aplicación lo prohíbe correctamente.

Lo que lo distingue: Sin intercambio de código: sin canal trasero, sin refresh token, tokens visibles en el historial del navegador.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Refresh Token Complemento

Renovar un access token de corta duración sin volver a preguntar a la persona.

ApplicationProveedor (OP)API1. Authorization: Bearer access_token2. 401 invalid_token (caducado)3. POST /token(grant_type=refresh_token)4. Revoca el refresh antiguotoken (rotation)5. Nuevo access token + nuevorefresh token6. Authorization: Bearer nuevo access_tokenSi el refresh token antiguo sereutilizado, toda la familia de tokensse revoca.
Versión en texto del diagrama
  1. Application → API : Authorization: Bearer access_token
  2. API → Aplicación: 401 invalid_token (caducado)
  3. Aplicación → Proveedor (OP) : POST /token (grant_type=refresh_token)
  4. Proveedor (OP): Revoca el refresh token antiguo (rotación)
  5. Proveedor (OP) → Aplicación : Nuevo access token + nuevo refresh token
  6. Aplicación → API : Authorization: Bearer nuevo access_token

Úselo cuando: En cuanto quiera access tokens de corta duración manteniendo a la persona conectada mucho tiempo (scope offline_access).

Lo que lo distingue: No es un flujo de inicio de sesión: prolonga una sesión obtenida con otro flujo.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Client Credentials Máquina a máquina

Sin persona: el servicio se autentica con su secreto.

ServiceProveedor (OP)API1. POST /token(grant_type=client_credentials,scope)2. Verifica el secreto del cliente3. access token4. Authorization: Bearer access_token5. Datos
Versión en texto del diagrama
  1. Servicio → Proveedor (OP) : POST /token (grant_type=client_credentials, scope)
  2. Proveedor (OP): Verifica el secreto del cliente
  3. Proveedor (OP) → Servicio : access token
  4. Service → API : Authorization: Bearer access_token
  5. API → Servicio: Datos

Úselo cuando: Un servicio, una tarea programada o un demonio que llama a una API en su propio nombre.

Lo que lo distingue: Sin navegador, sin ID token, sin refresh token: solo un access token limitado a los scopes del cliente.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Password (ROPC) Evitar

La propia aplicación recoge la contraseña y la envía al proveedor.

PersonaApplicationProveedor (OP)1. Introduce el usuario y lasuperado2. POST /token(grant_type=password, username,password)3. access token (+ refreshtoken) o error
Versión en texto del diagrama
  1. Persona → Aplicación: Introduce usuario y contraseña
  2. Aplicación → Proveedor (OP) : POST /token (grant_type=password, username, password)
  3. Proveedor (OP) → Aplicación: access token (+ refresh token) o error

Úselo cuando: Evitar. Solo para migrar desde un sistema antiguo o para pruebas automatizadas.

Lo que lo distingue: Se salta la página del proveedor: sin MFA, sin SSO, phishing más fácil.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Device Code (RFC 8628) Dispositivos sin navegador

El dispositivo muestra un código corto; la persona lo valida en su teléfono.

DispositivoProveedor (OP)Teléfono / ordenador1. POST /device_authorization2. device_code, user_code,dirección3. Muestra «vaya a … eintroduzca ABCD-EFGH»4. Abre la dirección, introduce elcódigo, inicia sesión5. POST /token (device_code) enbucle6. authorization_pending y luegolos tokens
Versión en texto del diagrama
  1. Dispositivo → Proveedor (OP) : POST /device_authorization
  2. Proveedor (OP) → Dispositivo : device_code, user_code, URL
  3. Dispositivo: Muestra «vaya a … e introduzca ABCD-EFGH»
  4. Teléfono / ordenador → Proveedor (OP): Abre la dirección, introduce el código, inicia sesión
  5. Dispositivo → Proveedor (OP) : POST /token (device_code) en bucle
  6. Proveedor (OP) → Dispositivo: authorization_pending y luego los tokens

Úselo cuando: Televisión, consola, objeto conectado, herramienta de línea de comandos.

Lo que lo distingue: El inicio de sesión se hace en otro dispositivo. El dispositivo consulta al proveedor hasta la validación.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Token exchange (RFC 8693) Casos específicos

Intercambiar un token por otro, para un destinatario distinto.

API AProveedor (OP)API B1. POST /token(grant_type=token-exchange,subject_token, audience=B)2. Comprueba los derechos y la audiencia3. access token para la API B4. Authorization: Bearer nuevo token
Versión en texto del diagrama
  1. API A → Proveedor (OP) : POST /token (grant_type=token-exchange, subject_token, audience=B)
  2. Proveedor (OP): Comprueba los derechos y la audiencia
  3. Proveedor (OP) → API A: access token para la API B
  4. API A → API B : Authorization: Bearer nuevo token

Úselo cuando: Una API que debe llamar a otra en nombre de la persona, o microservicios que propagan la identidad.

Lo que lo distingue: Parte de un token ya obtenido, sin nuevo inicio de sesión. Puede reducir los derechos o cambiar la audiencia.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Logout (iniciado por el RP y back-channel) Session

Cerrar la sesión en el proveedor y avisar a las demás aplicaciones.

NavegadorApplication AProveedor (OP)Application B1. Hace clic en «Cerrar sesión»2. 302 a /logout(id_token_hint,post_logout_redirect_uri)3. GET /logout4. Cierra laproveedor5. POST logout_token(back-channel)6. 302 a post_logout_redirect_uri
Versión en texto del diagrama
  1. Navegador → Aplicación A: Hace clic en «Cerrar sesión»
  2. Aplicación A → Navegador : 302 a /logout (id_token_hint, post_logout_redirect_uri)
  3. Navegador → Proveedor (OP) : GET /logout
  4. Proveedor (OP): Cierra la sesión del proveedor
  5. Proveedor (OP) → Aplicación B : POST logout_token (back-channel)
  6. Proveedor (OP) → Navegador : 302 a post_logout_redirect_uri

Úselo cuando: Cualquier aplicación con inicio de sesión único (SSO): el cierre de sesión debe propagarse.

Lo que lo distingue: El canal trasero notifica de servidor a servidor, sin pasar por el navegador (por tanto es fiable).

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

Introspección y revocación Comprobar

Pregunte al proveedor si un token sigue siendo válido, o invalídelo.

APIProveedor (OP)1. POST /introspect (token)2. { "active": true, scope, exp,sub }3. POST /revoke (token)4. 200 : el token no es válido
Versión en texto del diagrama
  1. API → Proveedor (OP) : POST /introspect (token)
  2. Proveedor (OP) → API : { "active": true, scope, exp, sub }
  3. API → Proveedor (OP) : POST /revoke (token)
  4. Proveedor (OP) → API: 200 : el token no es válido

Úselo cuando: Una API que recibe un token opaco, o que quiere revocación inmediata.

Lo que lo distingue: Un JWT puede verificarse por sí solo con su firma; un token opaco requiere esta llamada.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

private_key_jwt y JWT Bearer (RFC 7523) En ID-Kit: proveedor de pruebas

El cliente prueba su identidad con un JWT firmado por su clave privada, en lugar de con un secreto compartido.

ServiceProveedor (OP)1. Firma un JWT (iss, sub,aud, exp, jti)2. POST /token(client_assertion,client_assertion_type)3. Verifica la firma conla clave pública del cliente4. access token
Versión en texto del diagrama
  1. Servicio: Firma un JWT (iss, sub, aud, exp, jti)
  2. Servicio → Proveedor (OP) : POST /token (client_assertion, client_assertion_type)
  3. Proveedor (OP): Verifica la firma con la clave pública del cliente
  4. Proveedor (OP) → Servicio : access token

Úselo cuando: Banca, sanidad, API sensibles, integraciones empresariales: ningún secreto que almacenar ni rotar.

Lo que lo distingue: El mismo intercambio que client credentials, pero la autenticación es una aserción firmada (client_assertion).

ID-Kit puede hacerlo en el lado del proveedor de pruebas (declare la clave pública de su cliente, tipo «Confidencial por clave»). Todavía no del lado de la aplicación de pruebas.

PAR y JAR (RFC 9126 y 9101) En ID-Kit

La solicitud de autorización se envía de servidor a servidor, en lugar de pasar en claro por la dirección.

NavegadorApplicationProveedor (OP)1. POST /par (todos losparámetros, firmados)2. request_uri (válido unossegundos)3. 302 a/authorize?request_uri=…4. GET /authorize?request_uri=…5. Inicio de sesión y redirección con el código
Versión en texto del diagrama
  1. Aplicación → Proveedor (OP): POST /par (todos los parámetros, firmados)
  2. Proveedor (OP) → Aplicación : request_uri (válido unos segundos)
  3. Aplicación → Navegador : 302 a /authorize?request_uri=…
  4. Navegador → Proveedor (OP) : GET /authorize?request_uri=…
  5. Proveedor (OP) → Navegador: Inicio de sesión y luego redirección con el código

Úselo cuando: Exigencias de FAPI: impedir que un parámetro se modifique o se lea en el navegador.

Lo que lo distingue: El navegador solo transporta un request_uri opaco.

ID-Kit puede hacerlo: proveedor de pruebas (su aplicación frente a ID-Kit) y aplicación de pruebas (su proveedor frente a ID-Kit).

JARM (respuesta de autorización firmada) En ID-Kit (proveedor de pruebas)

El proveedor también firma su respuesta: el código llega en un JWT, no en claro en la dirección.

NavegadorApplicationProveedor (OP)1. 302 a/authorize?response_mode=jwt2. GET /authorize y luego inicio de sesión3. Firma un JWT { iss, aud,code, state }4. Redirección a la aplicación ?response=JWT5. Reenvía la respuesta6. Verifica la firma, iss,aud y luego lee el código
Versión en texto del diagrama
  1. Aplicación → Navegador : 302 a /authorize?response_mode=jwt
  2. Navegador → Proveedor (OP) : GET /authorize y luego inicio de sesión
  3. Proveedor (OP): Firma un JWT { iss, aud, code, state }
  4. Proveedor (OP) → Navegador : Redirección a la aplicación ?response=JWT
  5. Navegador → Aplicación : Reenvía la respuesta
  6. Aplicación: Verifica la firma, iss, aud y luego lee el código

Úselo cuando: FAPI 2.0, sectores regulados, protección contra los ataques mix-up entre proveedores.

Lo que lo distingue: Un único parámetro «response» (JWT firmado con iss, aud, exp, code, state) sustituye a los parámetros simples.

ID-Kit puede hacerlo en el lado del proveedor de pruebas (declare la clave pública de su cliente, tipo «Confidencial por clave»). Todavía no del lado de la aplicación de pruebas.

DPoP (RFC 9449) En ID-Kit (proveedor de pruebas)

El token está vinculado a una clave que solo posee el cliente: un token robado es inutilizable.

ApplicationProveedor (OP)API1. Crea un par de claves2. POST /token + cabecera DPoP(prueba firmada)3. access token vinculado a la clave(cnf.jkt)4. Authorization: DPoP token + nueva prueba DPoP5. Verifica la prueba y elvínculo con la clave
Versión en texto del diagrama
  1. Aplicación: Crea un par de claves
  2. Aplicación → Proveedor (OP): POST /token + cabecera DPoP (prueba firmada)
  3. Proveedor (OP) → Aplicación: access token vinculado a una clave (cnf.jkt)
  4. Aplicación → API : Authorization: DPoP token + nueva prueba DPoP
  5. API: Verifica la prueba y el vínculo con la clave

Úselo cuando: Alta seguridad, SPA expuestas, API sensibles.

Lo que lo distingue: Cada llamada va acompañada de una prueba firmada (cabecera DPoP) que demuestra la posesión de la clave.

ID-Kit puede hacerlo en el lado del proveedor de pruebas (declare la clave pública de su cliente, tipo «Confidencial por clave»). Todavía no del lado de la aplicación de pruebas.

CIBA (Client-Initiated Backchannel) En ID-Kit (proveedor de pruebas)

La autenticación se realiza en el dispositivo de la persona, iniciada por el servidor.

ApplicationProveedor (OP)Teléfono1. POST /bc-authorize(login_hint, binding_message)2. auth_req_id3. Notificación: «¿Autoriza este¿pago?»4. La persona acepta5. POST /token (auth_req_id) enbucle, o callback6. Tokens
Versión en texto del diagrama
  1. Aplicación → Proveedor (OP) : POST /bc-authorize (login_hint, binding_message)
  2. Proveedor (OP) → Aplicación : auth_req_id
  3. Proveedor (OP) → Teléfono: Notificación: «¿Autoriza este pago?»
  4. Teléfono → Proveedor (OP): La persona acepta
  5. Aplicación → Proveedor (OP): POST /token (auth_req_id) en bucle, o callback
  6. Proveedor (OP) → Aplicación : Tokens

Úselo cuando: Centros de llamadas, bancos, confirmación de pagos por notificación.

Lo que lo distingue: Sin redirección del navegador: el proveedor contacta directamente con la persona.

ID-Kit puede hacerlo en el lado del proveedor de pruebas (declare la clave pública de su cliente, tipo «Confidencial por clave»). Todavía no del lado de la aplicación de pruebas.