Tema 7
Las APIs modernas rara vez se limitan a usuarios y contraseñas. Hoy es habitual que participen aplicaciones móviles, SPAs, microservicios, proveedores de identidad y clientes de terceros. En ese escenario, tecnologías como JWT, OAuth 2.0 y OpenID Connect se vuelven centrales, pero también son una fuente común de errores conceptuales e implementaciones inseguras.
En arquitecturas modernas, una API puede ser consumida por múltiples tipos de clientes: aplicaciones web de una sola página, apps móviles, backends internos, microservicios y aplicaciones de terceros. Esto exige mecanismos de identidad más flexibles que una simple contraseña o una API Key fija.
Por eso se volvió común apoyarse en tokens, delegación de acceso e integración con proveedores de identidad. Sin embargo, hay mucha confusión alrededor de estos términos. A menudo se dice “usamos JWT” como si eso describiera un sistema de autenticación completo, cuando en realidad JWT es solo un formato de token. Del mismo modo, se usa OAuth para autenticar sin comprender que su objetivo principal es delegar autorización.
Este tema aclara esas diferencias y explica cómo se conectan JWT, OAuth 2.0 y OpenID Connect dentro del ecosistema de seguridad de APIs.
Una manera útil de evitar confusiones es empezar por la función principal de cada pieza:
JSON Web Token es un formato compacto para representar afirmaciones firmadas digitalmente. Un JWT suele contener un header, un payload y una firma. Su ventaja principal es que el receptor puede verificar integridad y origen sin necesidad de consultar siempre un estado central, siempre que confíe en la clave de firma y en la emisión.
El payload puede incluir claims como:
JWT no es, por sí mismo, sinónimo de seguridad. Es una forma de empaquetar información. La seguridad depende de qué contiene, cómo se firma, cómo se valida y dónde se usa.
Estas ventajas explican su popularidad, especialmente en entornos donde múltiples servicios necesitan verificar identidad de forma rápida y consistente.
La popularidad de JWT también llevó a una falsa sensación de seguridad. Muchos sistemas adoptan JWT sin un modelo claro de validación o con expectativas equivocadas.
Problemas habituales:
Los claims son útiles porque transportan contexto que evita consultas adicionales. Pero cada claim adicional amplía el alcance de la confianza depositada en el token.
Preguntas importantes al diseñar claims:
Un error frecuente es incluir roles, flags internas o atributos sensibles en tokens de larga vida y luego confiar ciegamente en ellos aunque el estado real haya cambiado.
OAuth 2.0 es un marco para delegar acceso. Permite que un cliente obtenga tokens para acceder a recursos protegidos sin que el usuario tenga que entregar su contraseña a cada aplicación consumidora. La idea central es separar al proveedor de identidad y autorización del cliente que consume la API.
Esto es especialmente útil cuando:
Para entender OAuth conviene identificar sus actores principales:
Este modelo desacopla la API de la autenticación primaria y permite centralizar política de identidad y emisión de credenciales.
OAuth suele entregar un access token que la API usará para validar si la llamada está autorizada. Según el flujo y la implementación, también puede existir un refresh token para renovar acceso sin repetir autenticación primaria.
Desde el punto de vista de la API, lo importante es entender que el token representa un contexto de acceso delegado, con alcance, duración y audiencia determinados.
El token puede estar expresado como JWT o como token opaco. OAuth no obliga a uno u otro formato.
Este es uno de los errores conceptuales más comunes. OAuth fue diseñado para autorización delegada, no para autenticar usuarios en el sentido clásico. Puede participar en un proceso de autenticación, pero por sí solo no define identidad del usuario de forma estandarizada para el cliente.
Cuando una aplicación necesita saber quién es el usuario autenticado y obtener atributos estandarizados de identidad, ahí entra OpenID Connect.
OpenID Connect agrega una capa de identidad sobre OAuth 2.0. Su objetivo es permitir que un cliente autentique usuarios de forma estandarizada y reciba información verificable sobre esa identidad.
Para eso introduce conceptos como:
En otras palabras, si OAuth responde “puedes acceder a este recurso”, OpenID Connect ayuda a responder “este es el usuario autenticado”.
Confundir estos dos tokens es un error muy frecuente y potencialmente serio.
| Token | Propósito principal | Error común |
|---|---|---|
| ID Token | Representar identidad autenticada para el cliente | Usarlo como si fuera token de acceso a la API |
| Access Token | Autorizar acceso a recursos protegidos | Asumir que siempre describe identidad de usuario completa |
La API debería validar y aceptar el token apropiado para su rol. Aceptar cualquier token “porque parece válido” es una mala práctica.
OAuth 2.0 y OpenID Connect definen distintos flujos según el tipo de cliente y el contexto. El punto importante para seguridad no es memorizar cada detalle, sino entender que no todos los flujos sirven para todos los escenarios.
El flujo correcto depende de:
Elegir un flujo inadecuado suele abrir problemas de exposición de tokens, dependencia en secretos imposibles de proteger o vulnerabilidad frente a interceptación.
Una gran ventaja de OAuth y OpenID Connect es que permiten modelar contexto de acceso de forma más rica que un simple “logueado / no logueado”. Pero eso exige diseñar bien scopes y audiencias.
Si una API no valida audiencia, podría aceptar tokens emitidos para otro servicio. Si los scopes son demasiado amplios, un cliente obtiene más privilegios de los necesarios.
Los refresh tokens permiten renovar access tokens sin exigir autenticación interactiva constante. Son útiles para experiencia de usuario y continuidad operativa, pero representan credenciales de alto valor.
Si un refresh token se compromete, el atacante puede mantener acceso durante mucho tiempo. Por eso deben protegerse con especial cuidado, rotarse cuando corresponda y limitarse al contexto necesario.
Una mala gestión de refresh tokens puede anular en la práctica el beneficio de tener access tokens cortos.
Una API que consume JWT u otros tokens modernos debe validar algo más que la firma. Según el caso, también puede necesitar verificar:
En entornos de microservicios, estas tecnologías ayudan a propagar identidad y contexto de acceso entre servicios. Pero también pueden amplificar errores si cada servicio interpreta distinto los claims o valida de forma desigual.
En estos entornos conviene prestar atención a:
No todas las APIs necesitan el mismo nivel de sofisticación. Un servicio interno muy acotado puede funcionar con un esquema más simple. Pero cuando hay múltiples clientes, terceros, identidad de usuario, scopes, revocación y delegación, JWT, OAuth 2.0 y OpenID Connect se vuelven opciones naturales.
Se justifican especialmente cuando:
JWT, OAuth 2.0 y OpenID Connect son fundamentales en el ecosistema actual de APIs, pero solo resultan seguros cuando se entienden bien sus responsabilidades. JWT empaqueta claims, OAuth delega acceso y OpenID Connect autentica usuarios de forma estandarizada. Confundir esos roles lleva a decisiones erróneas que luego se traducen en autenticación débil, tokens mal utilizados y validaciones incompletas.
En el próximo tema profundizaremos en autorización segura: roles, permisos, scopes y control de acceso granular, para ver cómo traducir identidad autenticada en decisiones de acceso correctas.