Tema 9
En arquitecturas distribuidas los tokens suelen convertirse en la evidencia práctica de identidad y autorización. Entender qué resuelve OAuth2, qué agrega OpenID Connect y cómo manejar JWT de forma segura es clave para evitar confianza mal delegada, fuga de privilegios y sesiones difíciles de controlar.
En muchos sistemas modernos la identidad ya no se representa mediante sesiones de servidor tradicionales, sino mediante tokens. Esos tokens viajan entre clientes, gateways, APIs y servicios internos como prueba de autenticación o como evidencia de autorización delegada.
El problema es que con frecuencia se usan sin comprender bien qué significan. Se habla de OAuth, JWT y OpenID Connect como si fueran lo mismo, cuando en realidad resuelven problemas diferentes y se combinan con propósitos distintos. Esa confusión lleva a diseños inseguros, claims mal interpretados, privilegios demasiado amplios y dificultades para revocar o controlar acceso.
Este tema busca separar conceptos y establecer prácticas concretas para manejar tokens de forma segura en arquitecturas distribuidas.
OAuth2 es un marco de autorización delegada. Su objetivo principal no es autenticar usuarios, sino permitir que un cliente obtenga acceso limitado a un recurso protegido bajo ciertas condiciones. La pregunta que intenta resolver es: cómo autorizo a este cliente a acceder a este recurso sin entregarle credenciales permanentes del usuario.
Por eso OAuth2 se usa mucho cuando una aplicación necesita acceder a APIs en nombre de un usuario o en nombre propio, siempre bajo permisos definidos y tokens emitidos por una autoridad confiable.
OpenID Connect, u OIDC, se construye sobre OAuth2 y agrega una capa de identidad. Permite que un cliente no solo obtenga autorización, sino también información verificable sobre la autenticación del usuario.
Gracias a OIDC aparece el concepto de ID Token, que representa información sobre la autenticación del usuario y su identidad en el contexto del proveedor. Esto vuelve a OIDC especialmente útil para login federado y para aplicaciones que necesitan saber quién es el usuario autenticado de manera estándar.
JWT, o JSON Web Token, es un formato de token. No es un protocolo de autenticación ni de autorización por sí mismo. Puede usarse en muchos contextos, incluidos OAuth2 y OIDC, para transportar claims firmados digitalmente.
Esto significa que:
| Tipo | Para qué sirve | Riesgo principal |
|---|---|---|
| Access Token | Acceder a recursos protegidos | Si se filtra, habilita uso no autorizado hasta expirar |
| ID Token | Representar autenticación e identidad del usuario | Usarlo como si fuera access token |
| Refresh Token | Obtener nuevos access tokens | Mayor impacto si se compromete por su vida más larga |
Distinguirlos es fundamental. Usar un token para algo distinto de su propósito suele abrir errores de seguridad difíciles de detectar.
Los tokens suelen transportar claims: afirmaciones sobre identidad, audiencia, emisor, alcance, vigencia o atributos del actor. El problema no es solo técnico, sino semántico. Un claim mal interpretado puede abrir accesos indebidos aunque la firma sea válida.
Algunos claims frecuentes son:
iss: quién emitió el token.aud: para quién está destinado.sub: sujeto o identidad principal.exp: fecha de expiración.scope o equivalentes: alcance autorizado.Validar estos claims correctamente es tan importante como validar la firma.
Un token no debería aceptarse solo porque tiene formato correcto o porque parece bien firmado. También debe verificarse que realmente corresponde a ese contexto y a ese recurso.
Un JWT firmado suele ser autoconclusivo: contiene información suficiente para ser validado localmente sin consultar a la autoridad emisora en cada request. Esto mejora performance y desacople, pero también complica revocación inmediata y control fino de cambios de política.
Los tokens de referencia, en cambio, suelen requerir introspección o consulta a un servidor de autorización. Esto mejora control central, pero introduce dependencia y latencia.
| Modelo | Ventaja | Desventaja |
|---|---|---|
| Autoconclusivo | Validación local rápida | Revocación y cambios inmediatos más difíciles |
| Referencia | Control central más directo | Mayor dependencia del servidor de autorización |
La vida útil del token es una decisión de riesgo. Un token muy largo mejora comodidad, pero aumenta impacto si se filtra. Un token muy corto reduce ventana de abuso, pero exige mecanismos adecuados de renovación y puede afectar experiencia o complejidad operativa.
En general conviene:
Los refresh tokens permiten obtener nuevos access tokens sin reautenticar al usuario en cada ocasión. Son útiles, pero sensibles. Como suelen vivir más tiempo, su compromiso puede tener impacto mayor que el de un access token breve.
Por eso es recomendable:
Un token es una credencial. Tratarlo como un dato cualquiera es un error frecuente. El lugar donde se guarda y la forma en que se transporta influyen directamente en el riesgo de robo o abuso.
No siempre conviene reenviar el token original del usuario a todos los microservicios. A veces alcanza con que un servicio derive contexto mínimo o actúe con su propia identidad técnica. Propagar tokens sin criterio tiende a ampliar superficie de ataque y a confundir responsabilidades de autorización.
Antes de propagar un token, conviene preguntarse:
No todos los clientes deberían usar el mismo flujo. El diseño debe considerar si se trata de una aplicación interactiva, un backend confidencial, una integración máquina a máquina o un cliente con distinta capacidad de proteger secretos.
Elegir mal el flujo o tratar todos los clientes igual suele terminar en exposición innecesaria de credenciales, dificultad para revocar y trazabilidad deficiente.
El uso de tokens puede simplificar autenticación y autorización en arquitecturas distribuidas, pero solo cuando se entienden bien sus límites y significados. Separar protocolo, formato y propósito es fundamental para evitar errores de diseño que luego se convierten en privilegios mal otorgados o sesiones imposibles de controlar.
En el próximo tema estudiaremos la gestión de secretos, claves, certificados y rotación segura para profundizar cómo se protege el material sensible que sostiene identidad, cifrado y acceso entre componentes.