Tema 15
Las APIs son uno de los lugares donde identidad y acceso dejan de ser una abstracción y se convierten en decisiones concretas de seguridad. Una API necesita reconocer quién o qué la invoca, validar si el token presentado es confiable, interpretar el alcance concedido y decidir si una operación específica está permitida. En ese recorrido aparecen conceptos como scopes, claims, JWT, tokens opacos e introspección.
En una aplicación web tradicional, gran parte del control de acceso puede estar concentrado en el servidor y en la sesión del usuario. En una arquitectura basada en APIs, en cambio, el acceso suele estar mediado por tokens emitidos por un sistema externo o por un componente especializado. Eso hace que la API deba tomar decisiones de seguridad a partir de información transportada en cada solicitud.
El problema no se reduce a aceptar o rechazar un token. La API debe responder varias preguntas: quién invoca, con qué identidad, bajo qué emisor, para qué audiencia, con qué alcance y si la operación concreta solicitada está permitida en el contexto del recurso afectado.
Este tema muestra cómo se relacionan esos elementos y por qué tener un token válido no significa automáticamente tener autorización suficiente.
Las APIs suelen ser consumidas por aplicaciones web, móviles, integraciones backend, procesos automatizados y servicios internos. No todos esos consumidores representan directamente a un usuario humano, y no todos usan el mismo tipo de credencial. Por eso el diseño de autenticación y autorización en APIs necesita distinguir claramente entre identidad del cliente, identidad del usuario y permisos efectivos sobre recursos.
Además, una API no puede confiar en supuestos del frontend. Si una interfaz muestra u oculta botones, eso no reemplaza la obligación del backend de verificar cada operación. En seguridad de APIs, la decisión final vive en el servidor que protege el recurso.
En este contexto conviene separar tres preguntas:
Una integración máquina a máquina puede tener cliente autenticado sin usuario final. Una aplicación delegada puede actuar en nombre de un usuario. Y en ambos casos sigue siendo necesario decidir si la acción pedida está autorizada. Mezclar estas capas lleva a controles incompletos o demasiado permisivos.
Un scope representa un alcance concedido al token. Suele expresar, de forma relativamente gruesa, para qué conjunto de acciones o recursos puede usarse ese token. Por ejemplo, un token podría incluir scopes de lectura, de escritura o de acceso a cierto dominio funcional.
Los scopes son útiles porque permiten limitar el poder de un token sin entregar acceso global. También ayudan a estructurar consentimiento, delegación y separación entre aplicaciones consumidoras.
Sin embargo, un scope no reemplaza toda la lógica de autorización. Decir que un token tiene alcance para “leer pedidos” no necesariamente significa que pueda leer cualquier pedido del sistema.
Los claims son declaraciones sobre una identidad, un contexto o un token. Pueden describir al usuario, al cliente, al emisor, la audiencia, el tiempo de vigencia o atributos adicionales relevantes para una decisión.
En la práctica, los claims sirven para transportar contexto verificable entre el emisor del token y la API que lo consume. Pero es importante entender su semántica: no todo claim debe ser usado como permiso, ni toda información presente en un token tiene el mismo nivel de confianza o el mismo propósito.
Un error frecuente es transformar cualquier atributo presente en un token en una autorización automática. La API debe saber qué claims fueron emitidos por una autoridad confiable y cómo encajan en su modelo de acceso.
JWT, o JSON Web Token, es un formato de token que puede transportar información firmada digitalmente. Se popularizó en APIs porque permite enviar, de forma compacta, datos verificables sin requerir necesariamente una consulta al emisor en cada solicitud.
Eso lo vuelve atractivo en arquitecturas distribuidas, donde múltiples servicios necesitan validar tokens con baja latencia. Pero su popularidad también generó simplificaciones peligrosas, como asumir que por ser un JWT ya está “todo resuelto”.
Conceptualmente, un JWT suele contener tres partes:
Esto no implica que el contenido sea secreto. En muchos casos, un JWT firmado puede ser leído por quien lo recibe, aunque no pueda modificarlo sin invalidar la firma. Por eso no conviene tratarlo como un contenedor apto para cualquier dato sensible.
Tener un JWT no significa automáticamente que:
El token es solo una pieza del mecanismo. La seguridad real depende de cómo fue emitido, qué representa, qué valida la API y qué controles adicionales aplica sobre el recurso y la operación.
En ecosistemas basados en OpenID Connect es común encontrar tanto access tokens como ID tokens. No son intercambiables.
El access token está pensado para que una API determine si acepta una llamada y bajo qué alcance. El ID token, en cambio, representa autenticación e identidad del usuario para el cliente que inició el flujo. Una API no debería asumir que un ID token sirve como sustituto general de un access token.
Usar el token incorrecto suele producir diseños frágiles, dependencias implícitas y validaciones inconsistentes.
Cuando una API recibe un token, al menos debe comprobar:
Estas comprobaciones son la base, no el final del proceso. Después viene la autorización real sobre la operación y el recurso concreto.
La introspección consiste en consultar a un servidor de autorización o componente confiable para saber si un token está activo y qué significado tiene. En lugar de depender solo de información auto-contenida, la API pregunta a la autoridad emisora por el estado actual del token.
Este enfoque resulta útil cuando se necesita control más centralizado, revocación más inmediata o cuando se trabaja con tokens opacos cuyo contenido no está destinado a ser interpretado directamente por la API.
La contracara es que agrega dependencia de red, latencia y necesidad de alta disponibilidad del servicio de introspección.
| Tipo de token | Ventaja principal | Límite principal |
|---|---|---|
| Auto-contenido, como muchos JWT | Validación local rápida y menor dependencia por llamada | Revocación y cambios de estado menos inmediatos |
| Opaco con introspección | Mayor control centralizado y mejor reacción ante revocación | Más latencia y dependencia operativa del servidor emisor |
No hay una respuesta universal. La elección depende del equilibrio entre autonomía de validación, rendimiento, sensibilidad del acceso y necesidad de control en tiempo cercano al real.
Uno de los errores más comunes en APIs es creer que el scope agota la decisión de autorización. En realidad, el scope suele responder a una pregunta amplia: “este token fue emitido para hacer este tipo de cosas”. Pero la autorización de negocio exige preguntas más específicas, por ejemplo:
Eso requiere evaluar reglas de dominio, relaciones con el recurso, pertenencia a tenant, estado del objeto, contexto organizacional y otras condiciones que rara vez quedan completamente modeladas solo con scopes.
La seguridad de una API no depende de adoptar una sigla de moda, sino de encadenar correctamente autenticación técnica, validación de tokens y autorización real sobre recursos y acciones. Scopes, claims, JWT e introspección son herramientas útiles, pero solo producen buen resultado cuando se entienden sus límites y se integran dentro de un modelo de acceso coherente.
En el próximo tema analizaremos los identity providers, los authorization servers y la arquitectura general de una solución IAM, para ver dónde encajan todos estos componentes dentro de un sistema más amplio.