ID Token frente a Access Token: la diferencia crucial de OpenID Connect

By Mirko Peters · 2026-10-28

Descubre las diferencias clave entre los ID tokens y los access tokens en OpenID Connect, y aprende por qué confundirlos puede provocar graves fallos de seguridad.

Automatically translated with AI from the original post. Read the English original

Entender la diferencia entre un ID token y un access token es fundamental para desarrolladores y administradores de TI que trabajan con autenticación moderna. Mientras que OAuth 2.0 gestiona los permisos, OpenID Connect introduce el ID token para confirmar la identidad del usuario. Confundir estos dos tokens distintos provoca vulnerabilidades de seguridad críticas en las aplicaciones en la nube.

Puntos clave

• Los ID tokens demuestran la identidad de un usuario, mientras que los access tokens otorgan autorización y permisos.
• Confundir estos dos tokens es un error habitual en la seguridad de las aplicaciones desarrolladas internamente.
• OpenID Connect añade la confirmación de identidad sobre el marco de OAuth 2.0.
• Los access tokens se pueden revocar, lo que ofrece una postura de seguridad más segura que almacenar contraseñas.
• Las aplicaciones deben verificar criptográficamente los ID tokens entrantes en lugar de confiar en ellos ciegamente.

El dilema central: identidad frente a autorización

En la evolución de las aplicaciones web modernas, los desarrolladores se encuentran con frecuencia con confusiones sobre cómo los usuarios inician sesión y cómo esos mismos usuarios interactúan con los datos subyacentes. Gran parte de esta confusión procede de una terminología solapada en el ámbito de la identidad. Cuando las aplicaciones empezaron a expandirse rápidamente por la web, depender únicamente de combinaciones básicas de nombre de usuario y contraseña creó un enorme cuello de botella de seguridad. Los usuarios se cansaron de gestionar decenas de credenciales distintas, lo que llevó a reutilizar contraseñas débiles en múltiples plataformas.

Para resolver parte de este problema, llegó OAuth 2.0. Sin embargo, OAuth 2.0 nunca se diseñó para responder a la pregunta de quién es una persona. Su único propósito es proporcionar «permisos de acceso», conocidos como access tokens, que permiten a una aplicación acceder a puntos de datos específicos en nombre de un usuario. Un access token detalla lo que una aplicación puede hacer, pero no dice nada sobre la identidad de la persona que lo posee. Esta brecha fundamental obligó a las empresas que querían crear experiencias de inicio de sesión único a añadir sus propias comprobaciones de identidad a OAuth, lo que dio lugar a implementaciones fragmentadas que rara vez coincidían entre sí.

OpenID Connect cubrió exactamente esta brecha al introducir una capa estandarizada diseñada específicamente para la autenticación. Al utilizar un segundo token junto al access token tradicional, OpenID Connect separa con claridad la cuestión de la identidad de la de los permisos. Mantener estos dos conceptos separados es el cambio de mentalidad más importante para cualquiera que desarrolle o audite aplicaciones en la nube hoy en día.

Anatomía del ID token: qué contiene

Cuando un usuario hace clic en el botón «Iniciar sesión con Microsoft», el proveedor de identidad procesa las credenciales, gestiona los requisitos de autenticación multifactor y, finalmente, devuelve al usuario a la aplicación acompañado de un ID token. Este token se empaqueta como un JSON Web Token, abreviado habitualmente como JWT y pronunciado «yot». A primera vista, un JWT parece una cadena de caracteres impenetrable y difícil de interpretar, separada por puntos. Sin embargo, su estructura interna es sorprendentemente sencilla una vez decodificada.

Dentro de un ID token encontrarás un conjunto de declaraciones estándar, cada una con un propósito muy concreto:

• Issuer: identifica al proveedor de identidad concreto (como Microsoft Entra ID) que generó y firmó el token.
• Subject (sub): Sirve como identificador único e inmutable del usuario. Lo fundamental es que está diseñado para no cambiar aunque el usuario actualice su nombre para mostrar o su dirección de correo electrónico.
• Audience (aud): Indica la aplicación exacta para la que se creó el token, lo que garantiza que un token destinado a una aplicación no pueda ser interceptado de forma malintencionada y reutilizado por otra.
• Marcas de tiempo: Detallan cuándo se emitió el token, cuándo caduca y el momento exacto en que el usuario se autenticó.
• Nonce: Funciona como un número de recibo seguro que vincula el token resultante con la sesión de inicio de sesión concreta que originó la solicitud, bloqueando de forma efectiva los ataques de repetición.

Lo fundamental es que todo el paquete se firma con la clave privada del proveedor. La aplicación receptora valida esta firma con la clave pública correspondiente que publica el proveedor. Sin esta verificación criptográfica, un token de ID no es más que una nota no verificada que pasa entre las partes.

El peligro de tratar la identidad como acceso

Uno de los antipatrones más peligrosos en el desarrollo de aplicaciones es tratar un token de ID como una llave de permisos. Como un token de ID confirma que un usuario es John Doe de una organización concreta, los desarrolladores novatos a veces cometen el error de usar esa confirmación para conceder derechos administrativos o acceso sin restricciones a la base de datos. Esto malinterpreta fundamentalmente la arquitectura.

Un token de ID simplemente indica quién está en la puerta principal; no dice nada sobre si esa persona puede entrar en todas las habitaciones interiores ni pulsar un botón administrativo concreto. La lógica de autorización debe gestionarla la aplicación por separado, mediante control de acceso basado en roles u otros mecanismos similares, tomando la identidad verificada como punto de partida y no como decisión final de autorización.

Además, las aplicaciones cometen con frecuencia el error de aceptar tokens de ID entrantes sin realizar las comprobaciones de validación adecuadas. Confiar en un token a ciegas solo porque una biblioteca lo procesó entre bastidores deja los sistemas expuestos a datos falsificados. Validar la firma, comprobar las marcas de tiempo de caducidad y verificar la notificación de audiencia son pasos imprescindibles para mantener una postura de seguridad sólida.

Conclusión

Dominar la frontera entre identidad y autorización ayuda a desmitificar la arquitectura de la nube moderna. Si los tokens de ID se limitan estrictamente a demostrar quién está frente al teclado, y dejas que los tokens de acceso determinen qué acciones están permitidas, los desarrolladores pueden crear integraciones robustas y seguras con plataformas como Microsoft Entra ID. Para escuchar un análisis completo de estos conceptos y descubrir cómo funcionan los flujos de inicio de sesión modernos en el ecosistema de Microsoft, consulta la conversación completa. Escucha el episodio completo y profundiza hoy mismo en la mecánica de la identidad en la nube.

Preguntas frecuentes

¿Se puede usar un token de ID para llamar a API o acceder a recursos protegidos?

No. Un token de ID solo contiene notificaciones de identidad sobre quién es el usuario. Para llamar a API o acceder a recursos protegidos, una aplicación debe usar un token de acceso emitido mediante OAuth 2.0.

¿Por qué OpenID Connect y OAuth 2.0 usan tokens independientes?

Separar la identidad de la autorización permite a las aplicaciones verificar quién inicia sesión sin concederles permiso ilimitado para manipular los datos o recursos subyacentes del usuario.

¿Qué ocurre si una aplicación acepta un token de ID sin comprobar su firma?

Omitir la verificación de la firma deja la aplicación expuesta a tokens falsificados, ya que cualquiera podría generar una cadena personalizada que se haga pasar por un usuario válido.

¿Dónde encaja el valor «nonce» en el intercambio de tokens?

El nonce es una cadena aleatoria que se genera al inicio del flujo de inicio de sesión y que se incrusta dentro del token de ID, lo que permite a la aplicación prevenir ataques de repetición.