Clase 06 · OAuth, OpenID Connect y autorización financiera

← 05 · Consentimiento: creación, vigencia, renovación y revocación · Índice de la parte · 07 · Financial-grade APIs, certificados y firma de mensajes →

Parte 17 — Finanzas abiertas, APIs y economía de datos · Nivel: Profesional — perfil bancario · Duración: 90 minutos

🎯 Propósito

Entender qué resuelve OAuth 2.x, qué no resuelve, dónde entra OpenID Connect y por qué el perfil por defecto de ambos es insuficiente para dinero. La clase separa autorización de autenticación, que es la confusión más cara del área.

El consentimiento de la clase anterior necesita un mecanismo técnico que lo ejecute sin que el cliente entregue su clave a nadie. Esta clase es ese mecanismo, y su idea central es una delegación: el tercero recibe un permiso acotado y nunca la credencial.

📚 Objetivos

Al finalizar podrás:

1. Distinguir autenticación de autorización y decir qué estándar resuelve cada una.
2. Explicar el flujo de código de autorización paso a paso, con sus parámetros y su razón de ser.
3. Justificar PKCE describiendo el ataque concreto que corta.
4. Identificar qué añade OpenID Connect sobre OAuth y cuándo hace falta.
5. Detectar los siete errores de implementación que aparecen en auditoría.

Agenda de 90 minutos

La clase dura noventa minutos y se recorre en cinco tramos. No es un horario rígido: es el orden en que los bloques de esta página se sostienen unos a otros, y por eso conviene respetarlo aunque cambien los tiempos.

Los diez primeros minutos se dedican a recuperar la clase anterior, porque casi todo lo que aquí se explica supone algo que ya se vio. Los veinticinco siguientes desarrollan los conceptos con la fuente oficial a la vista: las referencias del final de la página no son un adorno bibliográfico, se consultan mientras se estudia. Del minuto 35 al 55 se resuelve el ejemplo guiado paso a paso, sin saltarse ninguno, porque el error típico vive precisamente en el paso que parece obvio. Los veinticinco minutos siguientes son de práctica con datos propios o sintéticos —nunca reales de terceros—, que es cuando se comprueba si se entendió. Los diez últimos cierran con las preguntas de comprobación y el registro del entregable.

Si el tiempo aprieta, lo que se recorta es la práctica y se traslada al laboratorio de la parte; lo que no se recorta nunca es el ejemplo guiado.

🧩 Conceptos centrales

Los tres primeros términos separan autenticar de autorizar, que es la distinción que ordena toda la clase; los cinco siguientes son los elementos del protocolo. El PKCE es la protección que impide que un tercero intercepte el código de autorización, y en un contexto financiero no es opcional.

🧠 Modelo mental

El modelo mental es una delegación con tres partes: el titular autoriza al banco a entregar un token, y el tercero usa ese token en vez de las credenciales. La credencial nunca sale del banco, y ese es todo el punto del protocolo.

LA PREGUNTA QUE ORDENA TODO

  «¿QUIÉN ERES?»          → autenticación → OpenID Connect
  «¿QUÉ PUEDES HACER?»    → autorización  → OAuth 2.x

OAUTH NO ES UN PROTOCOLO DE AUTENTICACIÓN
  usarlo como tal es el error clásico:
  un token de acceso demuestra que ALGUIEN autorizó algo,
  no demuestra QUIÉN está delante

EL ACTO CENTRAL DE OAUTH
  el cliente nunca ve la credencial del usuario.
  El usuario se autentica ANTE SU PROPIA INSTITUCIÓN
  y esta emite una autorización acotada.

📖 Desarrollo

1. Los cuatro papeles

OAuth reparte la conversación entre cuatro papeles, y buena parte de la confusión inicial viene de uno de sus nombres. El bloque los enumera y aclara enseguida cuál es el malentendido habitual.

PROPIETARIO DEL RECURSO     el cliente, dueño de los datos
CLIENTE                     la aplicación que quiere acceder
SERVIDOR DE AUTORIZACIÓN    quien autentica y emite tokens
SERVIDOR DE RECURSOS        la API que expone los datos

CONFUSIÓN FRECUENTE
  «cliente» en OAuth es la APLICACIÓN, no la persona.
  La persona es el propietario del recurso.

2. El flujo de código, paso a paso

El flujo de código autorización es el único aceptable para finanzas abiertas. Conviene leerlo entero una vez, con sus parámetros, porque cada uno de ellos existe para cerrar un ataque concreto que se comenta después.

1. El cliente redirige el navegador al servidor de autorización con:
     response_type=code
     client_id=<público>
     redirect_uri=<registrada, exacta>
     scope=<alcances solicitados>
     state=<aleatorio, del cliente>
     code_challenge=<S256(code_verifier)>
     code_challenge_method=S256

2. El servidor autentica al usuario y le presenta los alcances.

3. El usuario aprueba (o rechaza alcances concretos).

4. El servidor redirige a redirect_uri con:
     code=<un solo uso, vida corta>
     state=<el mismo que llegó>

5. El cliente verifica que state coincide con el que envió.

6. El cliente llama al endpoint de token, POR CANAL DIRECTO:
     grant_type=authorization_code
     code=<el recibido>
     code_verifier=<el original, sin transformar>
     + autenticación del cliente

7. El servidor verifica que S256(code_verifier) == code_challenge
   y emite access_token acotado a los alcances CONCEDIDOS.

POR QUÉ DOS ETAPAS
  la etapa 1-4 viaja por el NAVEGADOR: es observable
  la etapa 6-7 viaja por el CANAL DIRECTO: no lo es

  el código puede filtrarse (historial, referer, aplicación
  maliciosa registrada en el mismo esquema).
  El token nunca pasa por el navegador.

3. PKCE: el ataque que corta

PKCE parece un añadido técnico menor hasta que se ve el ataque que impide. El bloque reconstruye el robo del código de autorización paso a paso y muestra después dónde exactamente se rompe la cadena cuando PKCE está presente.

SIN PKCE, EN UN CLIENTE PÚBLICO

  1. la aplicación legítima no puede guardar un secreto:
     está instalada en el dispositivo del usuario
  2. una aplicación maliciosa registra el mismo esquema
     de redirección (myapp://callback)
  3. el sistema operativo entrega el código a la maliciosa
  4. la maliciosa canjea el código por un token:
     solo necesita client_id, que es público por definición
  5. obtiene acceso a los datos del cliente

CON PKCE
  el canje exige code_verifier, que la aplicación legítima
  generó y nunca envió por el navegador.
  El código robado no sirve para nada.

REGLA
  PKCE es obligatorio en clientes públicos
  y RECOMENDADO en todos, incluidos los confidenciales:
  también corta la inyección de código en clientes con secreto.

4. Qué añade OpenID Connect

OAuth autoriza y OpenID Connect identifica: son preguntas distintas y se responden con tokens distintos. El bloque contrasta ambas respuestas y detalla los campos del token de identidad, que se validan uno a uno en la sección siguiente.

OAUTH DEVUELVE          un token de acceso: «puede leer X»
OPENID CONNECT AÑADE    un token de identidad: «el usuario es Y,
                        autenticado con el método M, a la hora H»

EL TOKEN DE IDENTIDAD ES UN JWT FIRMADO CON
  iss   quién lo emitió
  sub   identificador estable del usuario ANTE ESE EMISOR
  aud   para qué cliente se emitió
  exp   cuándo expira
  iat   cuándo se emitió
  nonce  liga el token a ESTA petición concreta
  acr / amr  nivel y método de autenticación

CUÁNDO HACE FALTA
  · cuando el producto necesita saber quién es el usuario
  · cuando debe comprobar QUÉ MÉTODO de autenticación se usó
    (relevante para autenticación reforzada, clase 11)

CUÁNDO NO
  · si solo necesitas leer datos consentidos, el token de acceso basta

5. Validación del token de identidad

Recibir un token de identidad y creérselo es equivalente a no tener autenticación. El bloque enumera las seis comprobaciones obligatorias y señala cuál de ellas se omite con más frecuencia, junto con lo que esa omisión permite.

UN TOKEN DE IDENTIDAD SIN VALIDAR ES UN TEXTO CUALQUIERA

  1. verificar la firma con la clave pública del emisor,
     obtenida de su conjunto de claves publicado
  2. comprobar iss contra el emisor esperado
  3. comprobar aud contra el propio client_id
  4. comprobar exp y iat con margen de reloj acotado
  5. comprobar nonce contra el enviado en la petición
  6. si hay acr, comprobar que cumple el nivel exigido

OMITIR EL PASO 3 ES EL DEFECTO MÁS COMÚN
  sin verificar aud, un token emitido para OTRO cliente
  del mismo emisor se acepta como propio

6. Los siete defectos que aparecen en auditoría

🧮 Ejemplo guiado

El ejemplo recorre un flujo de autorización completo con sus parámetros. Conviene seguir dónde está la credencial en cada paso: nunca pasa por el tercero.

Situación. Auditas la implementación de un proveedor de información. Estos son los hallazgos de la revisión de código y de tráfico.

HALLAZGO 1
  la aplicación móvil usa flujo de código sin code_challenge

HALLAZGO 2
  el servidor acepta redirect_uri que empiece por
  https://app.cuentasclaras.cl

HALLAZGO 3
  el token de acceso vive 24 horas

HALLAZGO 4
  el registro de aplicación contiene la línea:
  "token emitido: eyJ<...847 caracteres redactados en este material...>"

HALLAZGO 5
  el token de identidad se decodifica sin verificar firma
  «porque viene del servidor de autorización»

Paso 1 — clasifica por explotabilidad.

EXPLOTABLE HOY, SIN CONDICIONES PREVIAS
  H2 · redirección abierta
  H5 · token de identidad sin verificar

EXPLOTABLE CON UNA CONDICIÓN
  H1 · requiere aplicación maliciosa en el dispositivo
  H4 · requiere acceso al sistema de registro

AGRAVANTE, NO VULNERABILIDAD POR SÍ SOLO
  H3 · amplía la ventana de cualquier robo de token

Paso 2 — construye el ataque de H2.

URI REGISTRADA:  https://app.cuentasclaras.cl/callback
FILTRO:          startswith("https://app.cuentasclaras.cl")

URIs QUE PASAN EL FILTRO Y NO DEBERÍAN
  https://app.cuentasclaras.cl.atacante.io/callback
  https://app.cuentasclaras.cl@atacante.io/callback
  https://app.cuentasclaras.cl.evil/cb

LA PRIMERA ES UN DOMINIO DISTINTO
  el prefijo coincide; el registro de nombres, no.
  El código de autorización se entrega al atacante.

Paso 3 — construye el ataque de H5.

SIN VERIFICAR FIRMA, UN TOKEN DE IDENTIDAD ES TEXTO EDITABLE

  el atacante construye:
    { "iss": "...", "sub": "cliente_victima", "aud": "...",
      "exp": <futuro> }
  lo codifica en base64url, pone cualquier firma
  y lo presenta.

  si el cliente solo decodifica, acepta la identidad
  de cualquier usuario que el atacante escriba.

  ESTO NO ES TEÓRICO: es el defecto que produce
  la suplantación completa de cuenta.

Paso 4 — cuantifica el efecto de H3.

VENTANA DE UN TOKEN ROBADO

  con 24 h:      hasta 1 440 minutos de acceso
  con 10 min:    hasta 10 minutos

  con 158 llamadas por cliente y trimestre,
  y un historial de 24 meses accesible,
  10 minutos bastan para extraer el historial completo
  de una cuenta.

  → reducir la vida del token limita el DAÑO,
    no evita la EXTRACCIÓN
  → por eso H3 es agravante y no control suficiente:
    hace falta además límite de tasa (clase 8)

Paso 5 — prioriza la remediación.

BLOQUEANTE, ANTES DE CUALQUIER OTRA COSA
  H5 · verificar firma, iss, aud, exp y nonce
  H2 · coincidencia exacta contra el conjunto registrado

URGENTE (mismo ciclo)
  H1 · PKCE obligatorio, con S256 y sin admitir "plain"
  H4 · dejar de registrar tokens; purgar el histórico

PLANIFICADO
  H3 · token de acceso a 10 minutos, refresco a 12 horas,
       con rotación del token de refresco

PRUEBA DE NO REGRESIÓN
  una prueba negativa por hallazgo, en la batería
  de conformidad del laboratorio 6

Paso 6 — estima el coste de no hacerlo.

SUPUESTO: 380 000 clientes con consentimiento vigente

SI H5 SE EXPLOTA
  el atacante elige a qué cliente suplantar
  → no hay límite natural al alcance del incidente
  → el peor caso es «todos»

NO HAY CÁLCULO DE COSTE-BENEFICIO QUE APLICAR AQUÍ
  H5 no es un riesgo que se acepta con una reserva:
  es un defecto que se corrige antes de operar.

  Ese es el punto de la clase: hay controles que se
  evalúan por coste y controles que son condición de entrada.

Interpreta: cinco hallazgos, dos de ellos con el mismo patrón —se confió en que algo venía del sitio correcto sin comprobarlo—. La firma y la coincidencia exacta existen precisamente porque «viene del servidor de autorización» no es una verificación.

🧭 Perspectivas

El flujo de autorización se ve distinto desde cada actor. La tabla lo recoge.

🏦 Del cliente al banco

El cliente introduce su clave en la pantalla del banco y el tercero recibe un token con alcance limitado. La tabla enfrenta las dos lecturas.

⚖️ Riesgos y controles

Los riesgos del protocolo están en su implementación y en la gestión de los tokens. La tabla los recoge con su control.

🧪 Práctica

El laboratorio pide recorrer un flujo completo y detectar dónde fallaría sin PKCE. El punto de intercepción es el objetivo del ejercicio.

En labs/lab-02.md:

1. Implementa el flujo completo con PKCE.
2. Escribe una prueba negativa por cada uno de los siete defectos.
3. Construye el ataque de redirección abierta y demuestra que tu filtro lo corta.
4. Valida un token de identidad con los seis pasos, y falla uno a propósito.

⚠️ Errores frecuentes

Los síntomas de la tabla describen implementaciones inseguras del protocolo. Las causas son flujos obsoletos y tokens sin acotar.

❓ Preguntas de comprobación

1. ¿Por qué OAuth no es un protocolo de autenticación y qué se rompe si se usa como tal?
2. Describe el ataque que PKCE corta, con los cinco pasos.
3. ¿Qué URI pasa un filtro por prefijo y no debería? Explica por qué.
4. ¿Cuáles son los seis pasos de validación de un token de identidad y cuál se omite con más frecuencia?
5. ¿Por qué reducir la vida del token limita el daño pero no evita la extracción?

📥 Entregable

Guarda en portfolio/parte-17/clase-06/:

• el diagrama del flujo de código con los siete parámetros y su función;
• la descripción del ataque sin PKCE, paso a paso;
• tres URIs que pasarían un filtro por prefijo, con su explicación;
• los seis pasos de validación del token de identidad, con la prueba que escribiste para cada uno.

🔗 Referencias cruzadas

• Viene de: clase 5 (consentimiento); Parte 14, clase 8 (fraude digital).
• Continúa en: clase 7 (perfil financiero y firma), clase 11 (autenticación reforzada).
• Se aplica en: Parte 21, clase 11 (identidad en mercados tokenizados); Parte 23, clase 5 (identidad del banco digital).

🔐 Seguridad, ética y límites

Trabaja siempre con datos sintéticos o propios: nunca uses datos reales de terceros, números de cuenta, documentos de identidad ni antecedentes crediticios ajenos. Este material es formativo y no constituye asesoría financiera, tributaria ni legal; las tasas, comisiones, límites y normas citados cambian y deben verificarse en la fuente oficial vigente del país donde se aplique. Cuando un cálculo alimente una decisión que afecte a otra persona, registra los supuestos y quién los aprobó.

📗 Fuentes y verificación

• Internet Engineering Task Force. RFC 6749 — The OAuth 2.0 Authorization Framework. IETF. Flujos de autorización sobre los que se construye el acceso. https://www.rfc-editor.org/rfc/rfc6749
• Internet Engineering Task Force. RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients. IETF. Protección del código de autorización en clientes públicos. https://www.rfc-editor.org/rfc/rfc7636
• Internet Engineering Task Force. RFC 9700 — Best Current Practice for OAuth 2.0 Security. IETF. Prácticas de seguridad vigentes que corrigen el perfil original. https://www.rfc-editor.org/rfc/rfc9700
• OpenID Foundation. OpenID Connect Core 1.0. Capa de autenticación que OAuth por sí solo no provee. https://openid.net/specs/openid-connect-core-1_0.html
• Internet Engineering Task Force. RFC 7519 — JSON Web Token (JWT). IETF. Formato del testigo que transporta las afirmaciones de identidad. https://www.rfc-editor.org/rfc/rfc7519
• Verificación local: comprueba qué versión de cada especificación exige el anexo técnico vigente en tu jurisdicción; los perfiles se actualizan y los identificadores de RFC cambian al obsoletarse. Fecha de verificación de esta clase: 2026-08-20.