OAuth 2.0 en Profundidad: Flujos, Tokens y Seguridad

radio_button_uncheckedshort_textPresentación del capítulo

Los capítulos anteriores separaron identidad, autenticación, autorización y credenciales estáticas. Ahora el curso profundiza en el marco OAuth 2.0, creado para permitir a un cliente obtener autoridad limitada para acceder a un recurso protegido. La idea central es reemplazar el intercambio directo de credenciales con artefactos temporales, con audience, scope, duración y contexto controlados.

OAuth 2.0 no es un protocolo único y cerrado. Es una familia de roles, endpoints, grants, tipos de clientes, formatos de tokens y extensiones. La seguridad de un despliegue depende de la correcta composición de estos elementos. Un flujo de authorization code puede ser sólido cuando utiliza PKCE, URI de redireccionamiento estricto y protección de state, pero puede ser vulnerable cuando acepta redirecciones amplias, mezcla issuers o expone códigos y tokens en registros.

La especificación original sigue siendo importante, pero la práctica moderna también se guía por documentos posteriores. Las mejores prácticas actuales de seguridad consolidan experiencias operativas, desaconsejan modos inseguros y refuerzan PKCE, redirect URI exacto, protección contra mix-up, restricción de refresh token y defensa de replay. Extensiones como PAR, JAR, RAR, mTLS, DPoP, metadata de recursos y Token Exchange abordan escenarios de mayor riesgo e integraciones corporativas.

Este capítulo recorre el ciclo completo: registro de cliente, solicitud de autorización, emisión y uso de tokens, renovación, revocación, introspección, delegación entre servicios y aplicación en API Gateway. El objetivo es permitir al lector diseñar y diagnosticar flujos reales sin confundir la autenticación de usuario, la autenticación de cliente, el consentimiento, la autorización de recursos y la validación de tokens.

Estado de la especificación

OAuth 2.1 seguirá siendo un borrador de Internet en 2026. Consolida las prácticas modernas, pero no reemplaza automáticamente los RFC publicados. Para decisiones regulatorias, utilice los RFC actuales y las mejores prácticas actuales de seguridad de OAuth 2.0, consultando la versión preliminar actual solo para obtener orientación adicional.

Objetivos de aprendizaje

• Explique el problema de delegación resuelto por OAuth 2.0 y sus límites.
• Distinga propietario de recursos, cliente, authorization server y resource server.
• Diferenciar endpoint de autorización, endpoint de token, introspección, revocación y metadata.
• Clasifique clientes públicos y confidenciales y elija una autenticación compatible con su capacidad para proteger claves.
• Describir el authorization code con PKCE y los controles de estado, nonce, issuer y URI de redireccionamiento.
• Aplique Client Credentials, Device Authorization Grant y refresh tokens en escenarios apropiados.
• Distinga grants, códigos, access tokens, refresh tokens y tokens de identificación.
• Diseñar scopes, audiences, indicadores de recursos, consentimiento y autorización detallada.
• Comprenda los tokens opacos, los JWT, la introspección, la revocación y los perfiles de access tokens.
• Aplicar PAR, JAR, JARM, RAR, mTLS, DPoP y Token Exchange según riesgo.
• Integre OAuth con API Gateways, Axway API Gateway y Azure API Management.
• Diagnosticar invalid_request, invalid_client, invalid_grant, invalid_token y insufficient_scope.

Estructura del capítulo

• 16.1 El problema que resuelve OAuth 2.0
• 16.2 Roles y límites de confianza
• 16.3 Endpoints, metadata y canales
• 16.4 Registro, tipos de clientes y URI de redireccionamiento
• 16.5 Grants, flujos y tipos de tokens
• 16.6 Authorization Code en profundidad
• 16.7 PKCE y protección de interceptación
• 16.8 State, nonce, issuer y protección contra mix-up
• 16.9 Autenticación de clientes confidenciales
• 16.10 Aplicaciones web, SPA, nativas y BFF
• 16.11 Client Credentials
• 16.12 Device Authorization Grant
• 16.13 Refresh tokens, rotación y reutilización
• 16.14 Access tokens, scopes, audience e indicadores de recursos
• 16.15 Tokens opacos, introspección y revocación
• 16.16 Access tokens y validación de JWT
• 16.17 Consentimiento, least privilege y Rich Authorization Requests
• 16.18 PAR, JAR y JARM
• 16.19 Sender-constrained tokens con mTLS y DPoP
• 16.20 Token Exchange y on-behalf-of
• 16.21 Metadata del authorization server y recurso protegido
• 16.22 OAuth en API Gateways, Axway y Azure
• 16.23 Amenazas y hardening
• 16.24 Troubleshooting basada en evidencia
• 16.25 Estudios de casos y laboratorios
• Resumen, lista de verificación, ejercicios, glosario y referencias.

radio_button_uncheckedshort_text16.1 El problema que resuelve OAuth 2.0

Antes de los marcos de delegación, era común que una aplicación solicitara la contraseña de un usuario para acceder a otro sistema. Esta práctica otorgaba al cliente un poder excesivo, impedía limitar las operaciones, dificultaba la revocación selectiva y exponía las credenciales reutilizables. Si el cliente estuviera comprometido, el atacante podría actuar como usuario en cualquier interfaz que aceptara la misma contraseña.

OAuth reemplaza este intercambio con una concesión de autoridad. El cliente solicita autorización para una finalidad; El authorization server autentica al usuario cuando es necesario, aplica políticas y emite un access token destinado al resource server. El cliente recibe sólo la capacidad representada por el token, no la credencial principal del usuario.

El marco no define por sí solo cómo se autentica el usuario, cómo modela la API los permisos de los objetos o cómo se debe formatear el token. Tampoco transforma un access token en prueba de inicio de sesión para el cliente. OpenID Connect satisface la necesidad de comunicar la autenticación del usuario al cliente, mientras que la API sigue siendo responsable de la autorización detallada y las reglas comerciales.

modelo mental

OAuth responde: "¿cómo obtiene y presenta un cliente una autoridad limitada para un recurso?" No se responde a sí mismo: "¿quién es el usuario de la interfaz?", "¿el usuario es propietario de este objeto?" o "¿esta transacción está permitida por el dominio?".

radio_button_uncheckedshort_text16.2 Roles y límites de confianza

El resource owner es la entidad capaz de otorgar acceso al recurso. En muchos flujos se trata de una persona, pero también puede ser una organización o una política administrativa. El cliente es la aplicación que solicita acceso. No es automáticamente propietario de los datos y no se le debe otorgar más autoridad de la necesaria para su función.

El authorization server autentica al resource owner cuando corresponde, evalúa la solicitud, registra el consentimiento o la política y emite tokens. El resource server es la API que acepta access tokens y decide si se permite la operación. En una plataforma empresarial, API Gateway puede actuar como parte del resource server validando el token y aplicando controles transversales, mientras que el backend conserva las decisiones de dominio.

Los roles lógicos no necesariamente equivalen a procesos separados. El mismo producto puede alojar autorizaciones y recursos, y una API Gateway puede intermediar varias API. Aun así, el issuer, la audience, las claves, los endpoints y las responsabilidades deben ser distintos para evitar que un token emitido para un servicio sea aceptado indebidamente por otro.

radio_button_uncheckedshort_text16.3 Endpoints, metadata y canales

El endpoint de autorización recibe solicitudes a través del agente de usuario y realiza interacción con el resource owner. El cliente accede directamente al token endpoint para intercambiar grants por tokens. Esta separación crea dos canales: front-channel, expuesto al navegador, historial, extensiones y redireccionamientos; y back-channel, protegido por TLS y utilizado para solicitudes directas entre el cliente y el authorization server.

Los endpoints opcionales amplían la operación y la interoperabilidad. La introspección permite al resource server consultar el estado de un token. La revocación le permite invalidar refresh tokens y, según la implementación, access tokens. PAR recibe los parámetros de autorización por adelantado a través del back-channel. Los metadata describen el issuer, los endpoints, los métodos de autenticación, los algoritmos y las capacidades admitidas.

Las URL de los endpoints son datos de seguridad. El cliente no debe construirlos mediante concatenación ni aceptar metadata de una fuente que no sea de confianza. El issuer devuelto debe coincidir con el issuer configurado. TLS, la validación del nombre de host y la resolución DNS confiable siguen siendo esenciales porque OAuth protege la autoridad, no reemplaza la seguridad del canal.

radio_button_uncheckedshort_text16.4 Registro, tipos de clientes y URI de redireccionamiento

El registro asocia client_id, URI de redireccionamiento, tipo de aplicación, contactos, claves, métodos de autenticación y grants permitidos. client_id es un identificador público, no un secreto. La seguridad depende del vínculo correcto entre el identificador y las propiedades registradas, especialmente los URI de redireccionamiento y el material criptográfico.

Los clientes confidenciales pueden mantener las credenciales bajo control, como aplicaciones o servicios web backend. Los clientes públicos se ejecutan en entornos donde el usuario o atacante puede extraer el software y sus valores, como SPA y aplicaciones nativas. Insertar client_secret en un JavaScript, un paquete móvil o una aplicación distribuida no hace que el cliente sea confidencial; el secreto se vuelve copiable.

El URI de redireccionamiento debe compararse mediante una coincidencia exacta, excepto en el caso de reglas muy específicas para el bucle invertido de la aplicación nativa. Los comodines, la coincidencia de prefijos y los redirectores abiertos permiten omitir códigos. Cada entorno debe tener sus propios URI y la aplicación debe validar la ruta de retorno antes de iniciar cualquier sesión local.

Secreto público del cliente

Un valor integrado en un SPA, una aplicación móvil o un binario distribuido debe considerarse público. La protección adecuada proviene de PKCE, URI de redireccionamiento estricto, sistema operativo, BFF cuando corresponda y restricción de token, no de intentar ocultar un client_secret.

radio_button_uncheckedshort_text16.5 Grants, flujos y tipos de tokens

Grant es la representación de una autorización utilizada por el cliente para obtener un access token. El authorization code, el refresh token, las Client Credentials y el código del dispositivo son ejemplos. “Flujo” describe la secuencia completa de interacciones. Confundir concesión con token conduce a registros y políticas inexactas: el authorization code es corto, de un solo uso y está destinado al token endpoint; el access token se presenta a la API.

El access token representa la autoridad para un resource server. El refresh token le permite solicitar nuevos access tokens y debe estar restringido al authorization server. El ID token pertenece a OpenID Connect y comunica datos sobre la autenticación al cliente; no debe utilizarse como access token. Cada artefacto tiene un destinatario, vida útil y protección diferente.

Las antiguas Resource Owner Password Credentials y Implicit Grant no se deben elegir para proyectos nuevos. El primero expone tokens en el front-channel y ha perdido su justificación con PKCE; el segundo entrega las credenciales de usuario al cliente e impide muchos controles modernos. Las migraciones deben priorizar el Authorization Code con PKCE o flujos apropiados de máquina a máquina.

radio_button_uncheckedshort_text16.6 Authorization Code en profundidad

El cliente crea una solicitud de autorización que contiene los parámetros response_type=code, client_id, redirect_uri, scope, estado y PKCE. El navegador se redirige al authorization server, donde se puede autenticar al usuario y evaluar la política. Si tiene éxito, el authorization server devuelve un authorization code para el URI de redireccionamiento registrado.

El cliente recibe el código y lo intercambia en el token endpoint. Esta solicitud directa incluye grant_type=authorization_code, código, redirect_uri y code_verifier. Los clientes confidenciales también se autentican. El servidor verifica el uso único, el plazo, el cliente, el URI de redireccionamiento y PKCE antes de emitir tokens.

El código no debe tener autoridad reutilizable ni enviarse a API. Existe para reducir la exposición del token en el front-channel y permitir validaciones en el canal posterior. Los registros, las herramientas de análisis, las páginas de error y las referencias no deben registrar el valor. Después del cambio, la aplicación debe eliminar los parámetros confidenciales de la URL y establecer su propio estado de sesión de forma segura.

Solicitud de autorización - valores ilustrativos

GET /authorize?response_type=code
  &client_id=portal-pagos
  &redirect_uri=https%3A%2F%2Fapp.example%2Fcallback
  &scope=pagos.read%20pagos.write
  &state=valor-aleatorio
  &code_challenge=base64url-sha256-verifier
  &code_challenge_method=S256

Intercambio de código por tokens

POST /token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=https%3A%2F%2Fapp.example%2Fcallback
&client_id=portal-pagos
&code_verifier=SECRETO_ALEATORIO_DE_LA_INSTANCIA

radio_button_uncheckedshort_text16.7 PKCE y protección de interceptación

PKCE comienza con un code_verifier aleatorio, de alta entropía y exclusivo de prueba. El cliente calcula code_challenge = BASE64URL(SHA256(code_verifier)) y envía el desafío al endpoint de autorización. Al cambiar el código, muestra el verificador original. El authorization server vuelve a calcular el desafío y requiere una coincidencia.

Si un atacante intercepta el authorization code, no podrá intercambiarlo sin el verificador. Se debe utilizar el método S256; Plain existe para una compatibilidad restringida y no ofrece la misma protección contra la observación que la impugnación. PKCE no reemplaza el estado, el URI de redireccionamiento exacto, TLS ni la autenticación de confidential client. Resuelve una amenaza específica: la interceptación e inyección de códigos de autorización.

También se debe exigir PKCE a los clientes confidenciales cuando utilicen el Authorization Code. Además de estandarizar el flujo, protege contra ataques en los que se inyecta código obtenido en otro contexto en la sesión del cliente. El verificador no se debe reutilizar y debe estar asociado con la misma transacción que contiene el URI de estado y de redireccionamiento.

radio_button_uncheckedshort_text16.8 State, nonce, issuer y protección contra mix-up

El estado vincula la respuesta de autorización a la sesión que inició la solicitud y ayuda a prevenir CSRF. Debe ser impredecible, de un solo uso y asociado localmente con el issuer, el URI de redireccionamiento, el PKCE y la intención del usuario. Tratar el estado únicamente como una URL de retorno firmada puede dejar la sesión sin la protección adecuada contra respuestas no solicitadas.

Nonce pertenece a OpenID Connect y vincula el ID token a la solicitud de autenticación. No reemplaza al estado para asegurar el flujo de OAuth. En clientes que usan OIDC, es posible que se requieran ambos: el estado protege la redirección y el nonce se valida dentro del token de ID.

Los ataques de mix-up de authorization server explotan a los clientes que hablan con varios issuers y no vinculan la respuesta al issuer correcto. El cliente debe utilizar metadata confiables, validar el parámetro iss cuando sea compatible y enviar el código solo al token endpoint del issuer asociado con la transacción. Nunca seleccione el token endpoint basándose en datos de respuesta no validados.

Estado transaccional mínimo

Almacene, tentativamente: issuer esperado, client_id, URI de redireccionamiento, estado, code_verifier, nonce cuando hay OIDC, scopes solicitados y tiempo. Consume el registro una vez y caduca rápidamente.

radio_button_uncheckedshort_text16.9 Autenticación de clientes confidenciales

El token endpoint debe distinguir al cliente que presenta la concesión. client_secret_basic es simple, pero se basa en un transporte secreto y seguro simétrico. client_secret_post coloca el secreto en el cuerpo y aumenta el riesgo de registro; debe evitarse cuando se admite el método básico. Los secretos necesitan almacenamiento en bóveda, rotación, propiedad y scope por entorno.

private_key_jwt utiliza una aserción JWT firmada por la clave privada del cliente. El authorization server valida issuer/sujeto, audience, vencimiento, identificador único y firma. La clave privada no se envía y JWKS puede gestionar la rotación. El mecanismo requiere prevención de reproducción jti y una validación estricta de la audience del token endpoint.

La autenticación del cliente mTLS vincula la autenticación al certificado presentado en la conexión TLS. Puede utilizar PKI tradicional o certificado registrado. En entornos con proxies, debe quedar claro dónde termina TLS y cómo se preserva la identidad del certificado. La autenticación sólida del cliente no elimina la necesidad de PKCE en el Authorization Code.

radio_button_uncheckedshort_text16.10 Aplicaciones web, SPA, nativas y BFF

Las aplicaciones web tradicionales mantienen el código y las credenciales en el servidor. El navegador solo recibe una cookie de sesión protegida, mientras que el backend ejecuta el authorization code, almacena tokens y llama a las API. Esta separación reduce la exposición de los tokens a JavaScript, pero requiere protección contra CSRF, fijación, XSS y robo de sesiones.

Las SPA son clientes públicos. El authorization code con PKCE es el flujo moderno, pero los access tokens almacenados en el navegador todavía están expuestos a XSS y extensiones. Un Backend para Frontend puede recibir el código, mantener tokens en el servidor y exponer solo cookies HttpOnly, Secure y SameSite al navegador. BFF agrega estado e infraestructura pero reduce la huella del token.

Las aplicaciones nativas utilizan navegadores externos y redirigen URI según enlaces de aplicaciones, enlaces universales, esquemas personalizados o loopback. Las vistas web integradas degradan la seguridad y la experiencia de SSO. El sistema debe evitar que otra aplicación capture el URI de redireccionamiento y siempre combinar el mecanismo de devolución con PKCE.

radio_button_uncheckedshort_text16.11 Client Credentials

Las Client Credentials se utilizan cuando el cliente actúa por cuenta propia, sin un propietario de recurso humano en la transacción. El cliente se autentica en el token endpoint y recibe un access token asociado con la identidad de la aplicación. Es adecuado para servicios, trabajos y automatizaciones que tengan sus propios permisos.

Grant no debe usarse para simular usuarios ni transportar user_id arbitrario. La autorización debe basarse en el principal de la aplicación, su tenant, propietario y los permisos de la aplicación. Si un servicio necesita preservar el contexto del usuario al llamar a otro, es más adecuado el Token Exchange o on-behalf-of.

Dado que el token puede abrir un acceso amplio, las credenciales estáticas deben reemplazarse con private_key_jwt, mTLS, identidad administrada o federación de cargas de trabajo cuando sea posible. Los scopes de aplicación deben separarse de los scopes delegados para evitar que un token exclusivo de aplicación se confunda con la autoridad del usuario.

Client Credentials: ejemplo conceptual

POST /token
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&scope=liquidaciones.process

Pregunta de revisión

Si la operación necesita saber “¿qué usuario autorizó?”, las Client Credentials por sí solas no proporcionan esa respuesta. Lo principal es la aplicación.

radio_button_uncheckedshort_text16.12 Device Authorization Grant

La Device Authorization Grant admite dispositivos con entrada limitada o sin un navegador conveniente. El cliente solicita device_code y user_code, presenta al usuario un verification_uri y comienza a sondear el token endpoint. El usuario completa la autenticación y autorización en otro dispositivo compatible con navegador.

El cliente debe respetar el intervalo, expires_in y errores como authorization_pending y slow_down. El sondeo agresivo crea carga y puede provocar bloqueos. El user_code debe ser lo suficientemente corto para escribirlo, pero protegido por limitación de velocidad, caducidad y vinculación al device_code de alta entropía.

El flujo no debe usarse como acceso directo para aplicaciones que ya tienen un navegador adecuado. La interfaz debe mostrar claramente qué dispositivo y operación se está autorizando, reduciendo los ataques de phishing en los que la víctima ingresa un código enviado por un tercero.

radio_button_uncheckedshort_text16.13 Refresh tokens, rotación y reutilización

El refresh token es una credencial de alto valor porque le permite obtener nuevos access tokens sin repetir toda la interacción. Solo debe enviarse al token endpoint, protegerse en un almacenamiento adecuado y limitarse al cliente y la autorización original. Los access tokens cortos reducen la exposición; Los refresh tokens mantienen una continuidad controlada.

Para los clientes públicos, BCP recomienda refresh tokens rotados o restringidos por el remitente. En rotación, cada uso produce un nuevo refresh token e invalida el anterior. Si vuelve a aparecer un token antiguo, el servidor detecta un posible robo y revoca la familia o autorización correspondiente. La implementación debe manejar la simultaneidad y las respuestas perdidas sin crear falsos positivos.

Se deberá definir caducidad absoluta, caducidad por inactividad, revocación por cierre de sesión, cambio de contraseña, retirada del consentimiento y riesgo. El “refresh token nunca caduca” transfiere todo el control a la revocación perfecta, algo difícil en los sistemas distribuidos. El cliente debe tratar invalid_grant como una necesidad de reautorización, no como un motivo para repetir indefinidamente.

radio_button_uncheckedshort_text16.14 Access tokens, scopes, audience e indicadores de recursos

El access token solo debe ser aceptado por el resource server para el cual fue emitido. Una amplia audience convierte un token en un pase reutilizable entre API. Los indicadores de recursos permiten al cliente declarar el recurso deseado durante la autorización o la solicitud de token, lo que ayuda al authorization server a emitir tokens específicos.

El scope representa la autoridad solicitada y concedida, pero su semántica debe estar documentada. Los scopes como lectura y escritura son simples, pero pueden resultar ambiguos en plataformas grandes. Los nombres de dominio, operación y recursos ayudan: pagos.read, pagos.create y conciliacao.execute. El scope no reemplaza la autorización de estado de objeto, tenant o dominio.

El resource server valida la audience, el scope y el contexto de la solicitud. Una API no debería aceptar un token porque contiene "admin" sin verificar el issuer, el tipo y el origen del claim. Los claims de autorización deben tener gobernanza: quién las emite, cuándo cambian, cómo se revocan y qué servicio tiene autoridad para interpretarlas.

Indicador de recursos: ejemplo conceptual

GET /authorize?response_type=code
  &client_id=app
  &resource=https%3A%2F%2Fapi.pagos.example
  &scope=pagos.read

radio_button_uncheckedshort_text16.15 Tokens opacos, introspección y revocación

El token opaco no revela la estructura al cliente o al resource server. La API consulta el authorization server mediante introspección o utiliza un estado local distribuido. Este enfoque facilita la revocación inmediata y minimiza la exposición de claims, pero crea dependencias en la disponibilidad, latencia, autenticación de API y política de cache.

La introspección devuelve atributos activos y autorizados para el solicitante. active=false debería ser una respuesta normal para un token no válido, caducado, revocado o desconocido, sin revelar detalles. El endpoint necesita autenticar los servidores de recursos y limitar los datos que cada uno puede consultar. La caché reduce la carga, pero aumenta la ventana entre la revocación y la aplicación.

La revocación permite al cliente solicitar la invalidación. La respuesta exitosa no debería revelar si el token existía. La revocación del refresh token normalmente cancela la capacidad de renovación; Los access tokens ya emitidos pueden continuar hasta que caduquen si son autónomos. Las arquitecturas de alto riesgo combinan eventos TTL cortos, introspección, revocación o lista de denegados.

Introspección - ejemplo simplificado

POST /introspect
Authorization: Basic <credencial-del-resource-server>
Content-Type: application/x-www-form-urlencoded
token=TOKEN_OPACO
HTTP/1.1 200 OK
{
  "active": true,
  "client_id": "portal",
  "scope": "pagos.read",
  "exp": 1770000000
}

radio_button_uncheckedshort_text16.16 Access tokens y validación de JWT

JWT permite que el resource server valide firmas y claims localmente, lo que reduce las llamadas al authorization server. El perfil del access token JWT estandariza las claims y los tipos útiles, pero la API aún necesita conocer el issuer, la audience, los algoritmos y las claves confiables. La decodificación de Base64URL no se valida.

La validación debe corregir los algoritmos permitidos, localizar la clave indicada por kid en JWKS confiable, verificar la firma, el issuer, la audience, el vencimiento, no antes, cuando esté presente y el tipo esperado. El resource server debe rechazar los tokens emitidos para otros usos, incluso si la misma clave firma tokens de identificación. Las reglas de tipo y perfil ayudan a evitar confusiones entre los tipos de JWT.

La rotación de claves requiere cache y actualización controlada. Cuando aparece un kid desconocido, la API Gateway puede actualizar JWKS, pero no debe permitir que el token apunte a una URL de clave arbitraria. La falla temporal de los metadata no debería invalidar inmediatamente todas las claves que aún son confiables; al mismo tiempo, el exceso de caché retrasa la eliminación de la clave comprometida.

Contenido no cifrado

Un JWT firmado normalmente protege la integridad, no la confidencialidad. Evite PII y datos innecesarios. El token pasa por clientes, servidores proxy, API Gateways, herramientas y registros; trátelo como una credencial confidencial.

radio_button_uncheckedshort_text16.17 Consentimiento, least privilege y Rich Authorization Requests

El consentimiento es una interfaz de decisión, no un sustituto de la política. En entornos corporativos, algunos permisos son aprobados por administradores o contratos, mientras que otros dependen del usuario. La pantalla debe identificar cliente, datos, acciones, duración y consecuencias, evitando scopes técnicos incomprensibles.

El privilegio mínimo comienza con la definición de scopes y continúa en el resource server. Solicitar todos los scopes “para evitar nuevos consentimientos” aumenta el impacto de las filtraciones. La autorización incremental le permite solicitar autoridad adicional solo cuando se utiliza la funcionalidad. El authorization server puede otorgar un subconjunto y el cliente debe verificar la respuesta.

Las Rich Authorization Requests representan detalles estructurados como monto, moneda, cuenta y tipo de transacción. Esto permite autorizaciones más precisas que las cadenas de scope, especialmente en pagos y datos financieros. El objeto de autorización debe ser validado, firmado o protegido según el perfil adoptado y no debe ser aceptado como dato gratuito enviado por el cliente a la API.

Rich Authorization Request: ejemplo de enseñanza

{
  "authorization_details": [{
    "type": "payment_initiation",
    "instructedAmount": {"currency": "BRL", "amount": "150.00"},
    "creditorAccount": {"iban": "EJEMPLO"}
  }]
}

radio_button_uncheckedshort_text16.18 PAR, JAR y JARM

Pushed Authorization Requests permiten al cliente enviar parámetros al authorization server a través del back-channel y recibir request_uri de corta duración. El navegador sólo lleva la referencia. Esto reduce la manipulación, la exposición y la longitud de la URL y permite la autenticación del cliente antes de la interacción del usuario.

JWT-Secured Authorization Request representa la solicitud en un JWT firmado y, opcionalmente, cifrado. El authorization server valida la integridad y el origen de los parámetros. PAR y JAR se pueden combinar: el cliente envía un objeto de solicitud firmado al endpoint PAR y utiliza request_uri en el endpoint de autorización.

JARM protege la respuesta de autorización en un JWT firmado o cifrado. En lugar de depender únicamente de parámetros vagos en la redirección, el cliente valida el issuer, la audience, la firma y el tiempo. Estos mecanismos aumentan la complejidad y la gestión de claves, por lo que son más comunes en perfiles financieros, ecosistemas regulados e integraciones de alto riesgo.

radio_button_uncheckedshort_text16.19 Sender-constrained tokens con mTLS y DPoP

El token al portador funciona como dinero al portador: quien obtiene el valor puede presentarlo. El token restringido por el remitente vincula el access token a una clave de cliente. El resource server requiere, además del token, la correspondiente proof-of-possession. El objetivo es reducir la replay después de fugas en registros, servidores proxy, memoria o canales laterales.

Con mTLS, el authorization server asocia el token con el certificado del cliente y el resource server verifica el certificado presentado en la conexión. El claim cnf puede cargar la huella digital. La arquitectura debe garantizar que la API observe la identidad TLS correcta incluso cuando haya equilibradores de carga o API Gateways que terminen las conexiones.

DPoP utiliza un JWT de prueba firmado por el cliente en cada solicitud, que contiene el método HTTP, URI, hora, identificador único y enlace al access token. La API valida firma, htm, htu, iat, jti, key y ath. DPoP es una protección de la capa de aplicación y no reemplaza a TLS. El nonce del servidor y el caché jti pueden fortalecer la defensa de replay según el riesgo.

radio_button_uncheckedshort_text16.20 Token Exchange y on-behalf-of

En las arquitecturas de servicios, es posible que el primer backend necesite llamar a otro manteniendo parte de la autoridad original. Reenviar el mismo access token a todos los servicios amplía las audiences y expone la credencial. Token Exchange le permite intercambiar un token sujeto por otro token apropiado para el siguiente recurso.

El nuevo token puede representar al usuario, al servicio del actor o a ambos. Los claims de actor ayudan a registrar la cadena. La política debe limitar qué clientes pueden intercambiar tokens, qué audiences pueden solicitarse y qué scopes pueden conservarse. El intercambio no debe elevar el privilegio más allá del token de entrada y la autoridad del actor.

On-behalf-of es una implementación de delegación en la que un servicio actúa on-behalf-ofl usuario. Los registros deben preservar el usuario, el cliente inicial, el servicio intermedio y la autorización efectiva. Si una llamada pasa por varios dominios de confianza, cada salto debe tratarse como una nueva decisión, no como una simple copia de los headers.

radio_button_uncheckedshort_text16.21 Metadata del authorization server y recurso protegido

Los metadata del authorization server publican issuers, endpoints, métodos de autenticación, grants, scopes y algoritmos. Los clientes deben obtener el documento fuente configurado y validar la coherencia entre el issuer y la URL. Los metadata simplifican la rotación y la interoperabilidad, pero no deberían convertir el descubrimiento en confianza automática.

Los metadata de recursos protegidos permiten que una API publique identificadores de recursos, servidores de autorización relacionados, scopes y métodos de presentación admitidos. Esto ayuda a los clientes y servidores de autorización a comprender cómo obtener tokens para un recurso y mejora los desafíos de WWW-Authenticate.

Los metadata deben ser versionados y monitoreados como parte de la plataforma. Los cambios en el endpoint, el algoritmo o el issuer pueden dañar a todos los clientes. La caché debe respetar la disponibilidad sin congelar la configuración indefinidamente. Los entornos interno, externo y de homologación deben tener documentos separados para evitar la mezcla de confianza.

Metadata del authorization server: extracto ilustrativo

{
  "issuer": "https://id.example",
  "authorization_endpoint": "https://id.example/authorize",
  "token_endpoint": "https://id.example/token",
  "jwks_uri": "https://id.example/jwks.json",
  "code_challenge_methods_supported": ["S256"]
}

radio_button_uncheckedshort_text16.22 OAuth en API Gateways, Axway y Azure

Las API Gateways pueden validar access tokens, consultar introspección, requerir scopes, imponer cuotas por client_id y propagar contexto confiable. Antes de insertar headers internos, la API Gateway debe eliminar las versiones proporcionadas por el cliente. El backend debe aceptar estos headers solo desde una conexión autenticada proveniente de la API Gateway.

En Azure API Management, validate-jwt y validate-azure-ad-token pueden validar tokens antes del backend. Las políticas pueden requerir issuer, audience y claims, mientras que la authentication-managed-identity permite que la API Gateway obtenga un token para un backend compatible. La configuración del portal para desarrolladores para OAuth facilita las pruebas, pero no reemplaza la aplicación de políticas.

En Axway API Gateway, los filtros y servicios de OAuth pueden implementar políticas de authorization server, validación de tokens, autenticación de clientes y servidores de recursos. La topología necesita registrar qué componentes emiten, qué validaciones, dónde se almacenan las claves y cómo se manejan la revocación y la rotación. A medida que cambien las versiones y las licencias, valide la documentación del producto instalado.

Administración de API de Azure: política conceptual

<validate-jwt header-name="Authorization"
              require-expiration-time="true"
              require-signed-tokens="true">
  <openid-config url="https://id.example/.well-known/openid-configuration" />
  <audiences><audience>api://pagos</audience></audiences>
  <required-claims>
    <claim name="scp" match="any"><value>pagos.read</value></claim>
  </required-claims>
</validate-jwt>

División de responsabilidad

El gateway valida issuer, audience, firma, tiempo, scopes y requisitos transversales. El backend continúa verificando el tenant, la propiedad, el estado de la transacción, los límites comerciales y la autorización de objetos.

radio_button_uncheckedshort_text16.23 Amenazas y hardening

PKCE reduce la interceptación del authorization code. CSRF y el inicio de sesión CSRF requieren vínculo de state y transaccional. La confusión requiere asociación al issuer. La manipulación del URI de redireccionamiento requiere una comparación exacta. La fuga de tokens requiere TLS, higiene de registros, headers correctos, almacenamiento seguro y reducción de TTL. El token replay puede requerir una sender constraint.

Los redirectores abiertos en el cliente o en el authorization server aumentan la omisión de código. Referer, el historial y analytics pueden capturar parámetros del front-channel. Los tokens de query string se filtran fácilmente y no deben usarse como forma normal de presentación. Los access tokens deben seguir el header Authorization y las respuestas necesitan un Cache-Control adecuado.

Los servidores de autorización deben proteger los endpoints contra la fuerza bruta, el credential stuffing, la request flooding y el abuso de user_code. Los clientes deben validar todas las respuestas y no mostrar detalles internos. Los servidores de recursos deben limitar los algoritmos, validar audiences y no confiar en claims sin espacio de nombres ni gobernanza. Cada implementación requiere un inventario de clientes, propietarios, grants, URI de redireccionamiento y claves.

Prácticas desaconsejadas

No utilice credenciales de contraseña de propietario de recurso o de Implicit Grant en proyectos nuevos. No almacene client_secret en el public client. No acepte URI de redireccionamiento por prefijo. No trate el ID token como un access token. No acepte JWT sólo porque "decodifica sin errores".

radio_button_uncheckedshort_text16.24 Troubleshooting basada en evidencia

El diagnóstico comienza identificando el endpoint y el paso. El error en el endpoint de autorización implica parámetros, sesión, política y URI de redireccionamiento. El error del token endpoint implica autenticación, código, verificador, concesión y reloj del cliente. El error de API implica presentación, validación y autorización. Combinar estos pasos convierte invalid_grant en "JWT no válido" o 403 en "fallo de inicio de sesión".

Recopile ID de correlación, issuer esperado, client_id, grant_type, URI de redireccionamiento normalizado, scopes, audience, kid, hora y estado sin registrar tokens ni códigos. Compara el reloj de los componentes. Confirme los metadata y JWKS a los que accede el runtime, no solo el cuaderno del operador. En entornos proxy, registre el nombre de host, TLS y el destino real.

Para la intermitencia, investigue la rotación de claves, múltiples nodos con cache divergente, authorization code simultáneo o reutilización de refresh tokens, balanceo sin afinidad de sesión y DNS. Reproduzca con un único flujo controlado y tokens sintéticos. Un token puede funcionar en una API Gateway y fallar en otra debido a una configuración o caché diferente.

Error externo estable; La causa detallada permanece en el registro seguro

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="pagos",
  error="invalid_token"
Content-Type: application/problem+json
{
  "type": "https://errors.example/oauth/invalid-token",
  "status": 401,
  "correlationId": "corr-8f12"
}

radio_button_uncheckedshort_text16.25 Estudios de casos

Caso 1 - SPA con secreto incorporado

Un SPA envía client_secret en el token de solicitud. El valor es visible en el paquete y cualquier usuario puede copiarlo. La solución es registrar el cliente como público, usar el authorization code con PKCE y el URI de redireccionamiento exacto. Si el riesgo de tokens en el navegador es alto, adopte BFF y esté protegido por cookies.

La investigación también verifica CORS, almacenamiento de tokens, XSS, cierre de sesión y renovación. Simplemente eliminar el secreto no resuelve la exposición del refresh token o del access token persistente en localStorage.

Caso 2: token aceptado por una API incorrecta

Dos API confían en el mismo issuer y clave, pero una de ellas no valida la audience. Se acepta para los pagos un token emitido para informes. La solución es requerir una audience específica y scopes separados. En sistemas críticos, los indicadores de recursos y los tokens de recursos reducen la posibilidad de reutilización cruzada.

Las pruebas de contratos de seguridad deben enviar tokens válidos a audiences vecinas y esperar el rechazo. Esta verificación negativa debe existir en la API Gateway y en el backend cuando ambos validan los tokens.

Caso 3: refresh token reutilizado después del tiempo de espera

El cliente utiliza un refresh token, recibe un tiempo de espera y repite la llamada. El primer procesamiento había emitido un nuevo token; la replay parece robo y la familia queda revocada. La solución combina idempotencia operativa, ventana de tolerancia controlada o lógica de cliente que serializa la renovación y maneja las respuestas perdidas.

Una tolerancia amplia debilita la detección de reutilización. La decisión debe considerar el riesgo, la red y la capacidad de correlacionar intentos. Los registros deben registrar la familia, el token predecesor, el cliente y el resultado sin almacenar el valor bruto.

Caso 4: la API Gateway valida, el backend rechaza

La API Gateway acepta el token para su propia audience y lo reenvía al backend, que espera el token destinado a él. La arquitectura debe elegir: el backend confía en el contexto propagado por la API Gateway en un canal autenticado, o la API Gateway obtiene un nuevo token para el backend utilizando una identidad administrada, Client Credentials o Token Exchange.

Reenviar el token original solo es correcto cuando el backend es el resource server para esa audience. La decisión debe documentarse en el contrato de seguridad y probarse con múltiples API.

radio_button_uncheckedshort_textLaboratorios de observación

Laboratorio 1: Authorization Code con PKCE

• Utilice un authorization server de laboratorio o un simulador autorizado.
• Generar verificador aleatorio y desafío S256.
• Ejecute el flujo correcto y registre solo valores sintéticos.
• Repita con el verificador incorrecto, el estado divergente, el código reutilizado y el URI de redireccionamiento modificado.
• Clasifique cada error por paso y endpoint.

Laboratorio 2: validación de audience y scope

• Configure dos API con diferentes audiences.
• Emita el token para la API A e intente usarlo en la API B.
• Falta scope de prueba, caducado y issuer alternativo.
• Compare la respuesta externa y el código de motivo interno.

Laboratorio 3: introspección y caché

• Utilice tokens de endpoint de introspección y laboratorio opacos.
• Mida la latencia sin caché y con caché corto.
• Revocar el token y observar la ventana hasta el rechazo.
• Documente la decisión entre disponibilidad y velocidad de revocación.

Laboratorio 4: rotación de refresh tokens

• Obtenga un refresh token sintético.
• Renovar y confirmar emisión del sucesor.
• Reutilice el predecesor y observe la política familiar.
• Simula dos renovaciones competidoras y analiza el resultado.

Laboratorio 5: política en la puerta de entrada

• Configure el issuer, la audience y el scope en la API Gateway del laboratorio.
• Prueba de kid desconocido y actualización de JWKS.
• Elimine los headers de identidad enviados por el cliente.
• Solo propague claims validados y compárelos con la autorización de backend.

radio_button_uncheckedshort_textResumen del capítulo

OAuth 2.0 es un marco de delegación. El resource owner, el cliente, el authorization server y el resource server tienen diferentes responsabilidades. El endpoint de autorización y el endpoint de token utilizan canales diferentes, y cada artefacto (código, access token, refresh token y token de ID) tiene su propio destinatario y ciclo de vida.

El authorization code con PKCE es la base moderna para aplicaciones basadas en usuarios. PKCE protege contra la interceptación, el estado vincula la transacción, el nonce pertenece al OIDC y el issuer protege a los clientes de múltiples issuers. Los clientes públicos no tienen secretos fiables; Los clientes confidenciales pueden utilizar secret, private_key_jwt o mTLS.

Las Client Credentials representan la aplicación, la autorización del dispositivo cumple con la entrada limitada y los refresh tokens requieren restricciones de rotación o del remitente. Los access tokens necesitan una audience y un scope mínimos. Los tokens opacos favorecen el control central; Los JWT favorecen la validación local, pero requieren una verificación completa y gestión de claves.

PAR, JAR, JARM y RAR fortalecen las solicitudes y respuestas; mTLS y DPoP reducen la replay; Token Exchange controla la delegación entre servicios. Las API Gateways aplican validación cruzada, mientras que los backends conservan la autorización del dominio. La seguridad depende del inventario, el privilegio mínimo, el URI de redireccionamiento exacto, la higiene del registro, la observabilidad y las pruebas negativas.

Siguiente paso del curso

El Capítulo 17 profundizará en OpenID Connect: ID token, información de usuario, nonce, acr, amr, autenticación federada, sesiones, cierre de sesión e integración segura de aplicaciones con proveedores de identidad.

radio_button_uncheckedshort_textLista de verificación de OAuth 2.0

• Cada cliente tiene un propietario, tipo, URI de redireccionamiento y grants registrados explícitamente.
• El authorization code utiliza PKCE S256, incluso para clientes confidenciales.
• El estado es aleatorio, de un solo uso y está vinculado al issuer, al URI de redireccionamiento y al verificador.
• Los clientes públicos no dependen de client_secret.
• Los URI de redireccionamiento utilizan coincidencias exactas y no contienen redirectores abiertos.
• Las grants implícitas y de contraseña no se utilizan en proyectos nuevos.
• Los access tokens tienen una audience y un scope mínimos.
• El ID token no se acepta como access token.
• Los refresh tokens tienen rotación, restricción de remitente o política equivalente.
• Los JWT validan firma, algoritmo, issuer, audience, tipo y hora.
• La introspección está autenticada y tiene cache con reconocimiento de revocación.
• Los tokens no aparecen en URL, registros, análisis o mensajes de error.
• Se considera que mTLS o DPoP tienen un alto riesgo de replay.
• La API Gateway y el backend tienen una división de autorización explícita.
• Se prueba la rotación de JWKS, certificados y Client Credentials.
• Los errores de OAuth se pueden correlacionar sin revelar detalles confidenciales.
• Los clientes, grants, consentimientos y tokens tienen un proceso de terminación.

radio_button_uncheckedshort_textEjercicios

• Explique por qué OAuth 2.0 no es, por sí solo, un protocolo de autenticación de usuarios.
• Diferenciar authorization code, access token, refresh token y ID token.
• Describir las verificaciones del Authorization Code con PKCE.
• Explique por qué el estado y PKCE no se reemplazan entre sí.
• Califica un SPA y justifica por qué su client_secret no es confiable.
• Compare client_secret_basic, private_key_jwt y mTLS.
• Client Credentials modelo para un trabajo sin usuario.
• Explique la detección de reutilización en la rotación de refresh tokens.
• Compare el token opaco con JWT en cuanto a revocación y disponibilidad.
• Enumere las validaciones obligatorias de un access token JWT.
• Explique los indicadores de audience y recursos en una plataforma con múltiples API.
• Compare PAR, JAR y JARM.
• Diferenciar entre token vinculado a mTLS y token vinculado a DPoP.
• Proponer Token Exchange para tres servicios preservando al usuario.
• Cree un script de troubleshooting para invalid_grant intermitente.

radio_button_uncheckedshort_textGlosario

radio_button_uncheckedshort_textAnexo A - Matriz de elección de flujo

radio_button_uncheckedshort_textReferencias técnicas

• IETF. RFC 6749: el marco de autorización de OAuth 2.0. 2012.
• IETF. RFC 6750: uso de tokens de portador de OAuth 2.0. 2012.
• IETF. RFC 7009: Revocación de token de OAuth 2.0. 2013.
• IETF. RFC 7519: token web JSON (JWT). 2015.
• IETF. RFC 7636: clave de prueba para el intercambio de códigos por parte de clientes públicos de OAuth. 2015.
• IETF. RFC 7662: Introspección de tokens OAuth 2.0. 2015.
• IETF. RFC 8252: OAuth 2.0 para aplicaciones nativas. 2017.
• IETF. RFC 8414: Metadata del authorization server OAuth 2.0. 2018.
• IETF. RFC 8628: Device Authorization Grant OAuth 2.0. 2019.
• IETF. RFC 8693: Token Exchange OAuth 2.0. 2020.
• IETF. RFC 8705: access tokens vinculados a certificados y autenticación de cliente Mutual-TLS de OAuth 2.0. 2020.
• IETF. RFC 8725: Mejores prácticas actuales de tokens web JSON. 2020.
• IETF. RFC 9101: Solicitud de autorización asegurada por JWT. 2021.
• IETF. RFC 9126: Pushed Authorization Requests. 2021.
• IETF. RFC 9068: perfil JWT para access tokens OAuth 2.0. 2021.
• IETF. RFC 9207: Identificación del issuer del authorization server OAuth 2.0. 2022.
• IETF. RFC 9396: Rich Authorization Requests de OAuth 2.0. 2023.
• IETF. RFC 9449: OAuth 2.0 que demuestra proof-of-possession. 2023.
• IETF. RFC 9700: mejores prácticas actuales para la seguridad de OAuth 2.0. 2025.
• IETF. RFC 9701: Respuesta de JWT para la introspección de tokens de OAuth. 2025.
• IETF. RFC 9728: Metadata de recursos protegidos de OAuth 2.0. 2025.
• Grupo de trabajo IETF OAuth. El marco de autorización OAuth 2.1 - Internet-Draft, versión consultada en 2026.
• Microsoft aprende. Autenticación de Azure API Management, validate-jwt, validate-azure-ad-token y políticas de identidad administrada.
• Documentación Axway. Servicios OAuth 2.0, autenticación de clientes y validación de tokens en API Gateway.
• Fundación OpenID. Perfil de seguridad API de nivel financiero y especificaciones OpenID Connect, cuando corresponda al ecosistema.

Nota de actualización

OAuth evoluciona a través de RFC, mejores prácticas actuales, perfiles y borradores. Antes de implementar un flujo o una política, valide la especificación actual, la documentación de la versión del producto y el comportamiento en un entorno autorizado. Trate los borradores de Internet como un trabajo en progreso, no como reemplazos automáticos de los RFC.