Aprende qué son los tokens portadores, cómo funcionan en OAuth 2.0 y JWT, la diferencia con los tokens de acceso y buenas prácticas.
Detrás de casi cada inicio de sesión moderno en una app o solicitud a una API hay un trabajador silencioso: el token portador. Puede que no lo notes, pero está ahí cada vez que conectas servicios, inicias sesión o buscas datos en la nube.
Esta guía te explica qué hacen los tokens portadores, por qué son importantes y cómo manejarlos de forma segura.
Un token portador es un dato, generalmente una cadena de caracteres, que demuestra que quien lo posee tiene permiso para acceder a un recurso. Lo importante es que quien porta el token puede usarlo, sin necesidad de pruebas adicionales.
Piensa en una tarjeta de embarque de avión. Una vez que la tienes, puedes pasar seguridad y abordar el avión. Nadie te pide de nuevo tu identificación si la tarjeta es válida. De la misma forma, un token portador permite que tu aplicación "aborde la API" sin comprobar tu identidad cada vez.
Por ejemplo, después de iniciar sesión en Spotify en tu teléfono, no necesitas poner tu contraseña cada vez que reproduces una canción. En su lugar, la app almacena un token portador que le indica a los servidores de Spotify: “esta solicitud proviene de un usuario autorizado”.
El flujo de los tokens portadores puede desglosarse en unos pocos pasos:
El usuario inicia sesión
Supongamos que entras a una app bancaria con tu usuario y contraseña.
El proveedor de identidad emite un token
Una vez verificado, el servidor de autenticación devuelve un token portador. Esto podría verse así:
El cliente usa el token
Cada vez que tocas "Consultar saldo" o "Transferir dinero", la app incluye el token en la solicitud HTTP:
La API lo valida
El servidor comprueba que el token siga vigente, no esté caducado y tenga los permisos correctos (como read:balance o write:transfer).
Se concede el acceso
Si todo es correcto, el servidor responde con la información solicitada.
Este modelo es ampliamente utilizado en servicios como las API de GitHub, donde los desarrolladores se autentican con un token portador en vez de introducir credenciales cada vez.
Los tokens portadores ganaron popularidad porque solucionaron problemas comunes de seguridad web. A diferencia de las sesiones basadas en servidor, no requieren almacenar datos para cada usuario autenticado. En su lugar, el propio token contiene la información suficiente para que el servidor valide las solicitudes.
Por ejemplo, en una arquitectura de microservicios, donde docenas de servicios se comunican entre sí, mantener un almacenamiento centralizado de sesión sería complejo e ineficiente. Con tokens portadores, cada servicio puede validar solicitudes de forma independiente, manteniendo el sistema liviano y escalable.
Un ejemplo concreto: las API de Slack dependen mucho de los tokens portadores. Cuando creas un bot de Slack, obtienes un token que permite a tu bot llamar a los puntos finales de Slack sin mantener una sesión por cada usuario.
Muchos tokens portadores se implementan como JWT (JSON Web Tokens). Estos tokens son cadenas codificadas que incluyen información sobre el usuario y sus permisos.
Decodifiquemos un JWT de ejemplo:
Esto significa:
sub: El sujeto o ID único del usuario.name: El nombre del usuario.iat: Fecha de emisión.exp: Hora de expiración (cuando el token deja de ser válido).scope: Los permisos, en este caso permitiendo que la app lea y escriba mensajes.En la práctica, si el token de Jane solo tuviera el scope read:messages, la app podría leer sus mensajes pero no enviar uno nuevo en su nombre.
Es fácil confundir tokens portadores y tokens de acceso, porque a menudo aparecen juntos. De hecho, están relacionados pero no son idénticos.
Un token de acceso es una credencial que representa la autorización de un usuario para acceder a un recurso. Incluye información como:
Piénsalo como un permiso firmado por el director de la escuela. Le dice al maestro (la API) que puedes ir a la excursión (acceder al recurso).
Por ejemplo, cuando entras a un servicio de almacenamiento en la nube, el sistema emite un token de acceso con el scope read:files. Ese token le indica a la API de almacenamiento: “Este usuario puede leer archivos, pero no borrarlos.”
Un token portador es un tipo de token de acceso. La palabra portador describe cómo se usa el token: quien lo presenta puede “portar” el token y acceder a recursos, sin pruebas adicionales de identidad.
En otras palabras:
Hay otros tipos de token, como los holder-of-key tokens (token poseedor de clave), que requieren que el cliente demuestre tener una clave criptográfica además del token. Los tokens portadores omiten ese paso extra, lo que los hace más simples, pero también más riesgosos si se roban.
<token>.Esto significa que cuando veas "token de acceso" en tutoriales de OAuth, casi siempre es un token portador, salvo que se indique lo contrario.
Para aclarar más el panorama, veamos cómo los tokens portadores se comparan con otros tipos de tokens comunes:
Los tokens portadores y los tokens de acceso no son conceptos opuestos: están relacionados en alcance:
Validar un token portador es lo que separa tu API del acceso no autorizado. Si tus tokens son JWT, la validación ocurre localmente y rápido. La API puede comprobar el token sin tener que consultar al emisor cada vez.
Úsala como guía al implementar un gateway API o un middleware.
Firma
Verifica la firma usando el algoritmo del header (por ejemplo RS256). Obtén el endpoint JWKS del emisor, elige la clave que coincide con el kid y almacénala temporalmente.
Issuer (iss)
Compara el iss del token con la URL de tu emisor confiable, exactamente y con el esquema correcto.
Audience (aud)
Asegúrate de que el token esté destinado a tu API. Compáralo con el identificador de tu API como https://api.example.com o un string lógico de audiencia.
Expiration (exp) y Not-Before (nbf)
Rechaza tokens expirados. Respeta nbf para que el token no se use antes de tiempo. Permite un pequeño desajuste horario, normalmente 30 a 60 segundos.
Issued-At (iat)
Útil para debug y para rechazar tokens muy antiguos en configuraciones estrictas.
Tipo de token
Confirma que sea un token de acceso. Algunos proveedores incluyen typ: "at+jwt" o similar. No aceptes ID tokens para acceso a la API.
Scopes / permisos
Lee el scope o claims específicos del proveedor (por ejemplo permisos, roles). Aplica el principio de menor privilegio en cada endpoint.
Subject (sub)
Es el ID estable del usuario o app cliente. Úsalo para asociar recursos y para auditoría.
Repetición y revocación (opcional pero recomendable)
Para endpoints sensibles, consulta una denylist temporal de valores jti, o valida un registro de sesión activa. Esto ayuda tras cerrar sesión o sospechas de compromiso.
Como los tokens portadores funcionan con la lógica “quien lo tenga lo usa”, deben tratarse como llaves de casa. Si alguien roba tu llave, puede abrir la puerta hasta que la cambies.
Algunos riesgos comunes incluyen:
Han ocurrido brechas reales cuando desarrolladores accidentalmente subieron tokens portadores a repositorios públicos de GitHub. Los atacantes pueden buscar estos tokens y explotarlos de inmediato para obtener acceso no autorizado.
Para usar tokens portadores de forma segura, es clave seguir buenas prácticas. Revisémoslas con ejemplos:
Usa siempre HTTPS
Imagina enviar un token por HTTP en un Wi-Fi público de cafetería. Cualquier persona escuchando la red podría copiar el token e iniciar sesión como tú.
Usa tokens de acceso de corta duración
La mayoría de plataformas emiten tokens que caducan en una hora. Por ejemplo, los tokens OAuth de Google suelen durar una hora antes de requerir refresco.
Gestiona con cuidado los refresh tokens
Un refresh token puede pedir nuevos tokens de acceso sin que el usuario vuelva a iniciar sesión. Pero debe almacenarse de forma segura (ej. en una base de datos cifrada en el servidor) y no en el almacenamiento del cliente.
Limita el scope de los tokens a los permisos mínimos
Si tu app solo necesita leer el calendario del usuario, no pidas write:calendar. Esto reduce el daño si el token se compromete.
Revoca tokens cuando sea necesario
Muchas apps SaaS permiten a los usuarios ver sesiones activas y revocarlas. GitHub, por ejemplo, te permite revocar tokens personales en cualquier momento.
Monitorea el uso
Registrar el uso del token puede revelar actividad sospechosa. Si el mismo token se usa repentinamente desde Londres y Nueva York en minutos, es una señal de alarma.
Es útil comparar los tokens portadores con otros métodos populares:
Cookies & Sesiones
Sitios tradicionales usan sesiones almacenadas en el servidor y una cookie para identificarlas. Esto funciona bien en apps para navegador, pero es menos eficiente para APIs o apps móviles. Por ejemplo, iniciar sesión en Facebook en escritorio usa principalmente cookies, mientras que sus APIs móviles usan tokens.
API Keys
Una clave API es una cadena estática que autentica la aplicación, no el usuario. Por ejemplo, una app del clima puede usar una API key para obtener datos, pero esa clave no le dice al servidor qué usuario pide el pronóstico. Los tokens portadores pueden llevar información del usuario, lo que los hace más versátiles.
Mutual TLS (mTLS)
Algunos sistemas de alta seguridad usan certificados en el cliente y el servidor. Aunque es más seguro, esto es más complejo de implementar a gran escala. Para la mayoría de las plataformas SaaS, los tokens portadores logran el equilibrio entre facilidad de uso y seguridad.