¿Qué es un Bearer Token? OAuth 2.0, JWTs, Seguridad
Bearer token: string opaco que autentica requests API — quien lo posee tiene acceso completo. Enviado como header Authorization: Bearer.
¿Qué es un bearer token?
Un bearer token es un credencial de seguridad usado para autenticar requests API, definido en la especificación OAuth 2.0 (RFC 6750). La característica definitoria está en el nombre: quien porta (bears) el token recibe acceso — el token mismo es la prueba de autorización. Sin firma, sin clave separada, sin challenge-response. Posesión equivale acceso.
Los bearer tokens son el esquema de autenticación dominante para REST APIs modernas y flows OAuth 2.0. Reemplazan approaches más viejos como Basic Auth.
Cómo funcionan los bearer tokens en HTTP
Un bearer token se envía en el header HTTP Authorization con el esquema Bearer:
GET /api/users/me HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...El server valida el token y honora el request o devuelve 401 Unauthorized. Flow completo:
- Cliente se autentica. Via OAuth 2.0, exchange de API key, o formulario login.
- Server emite un bearer token. Devuelto en la response, típicamente como JSON.
- Cliente guarda el token. En memoria, secure storage, o cookie httpOnly.
- Cliente envía token con cada request.
- Server valida cada request.
- Token expira. Cliente usa refresh token o re-autentica.
Formatos de bearer token
Tokens opacos
Un string aleatorio sin información embebida. El server guarda mapeos token-a-usuario en una base de datos.
Authorization: Bearer 7b3f2e8a-1c4d-4b6a-9e7f-2c8d3a4b5e1fPros: revocación es instantánea (borrar de DB). Cons: cada request requiere un lookup de DB.
JWT (JSON Web Tokens)
Un formato self-contained de token firmado (RFC 7519). El payload contiene los claims; la firma prueba autenticidad sin estado server-side.
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cJWTs son tres segmentos base64-encoded separados por puntos. Pros: sin lookup DB. Cons: revocación más difícil.
Reference tokens
Un híbrido: token opaco corto que mapea a una sesión server-side.
Bearer token vs otros esquemas auth
| Esquema | Cómo funciona | Mejor para |
|---|---|---|
| Bearer Token | Token en header Authorization; posesión = acceso | REST APIs modernas, flows OAuth 2.0 |
| Basic Auth | Username:password base64 en Authorization | Solo APIs internas/legacy |
| API Key | Key estática en header o query | Server-to-server, integraciones simples |
| HMAC / Signed Requests | Cliente firma request con secreto compartido | APIs alta seguridad (AWS, Stripe webhooks) |
| Mutual TLS (mTLS) | Cliente presenta certificado | Service-to-service, zero-trust |
| Session Cookies | Session ID server-side en cookie | Apps browser |
OAuth 2.0 y bearer tokens
OAuth 2.0 es el framework que estandarizó bearer tokens para acceso API. Flows comunes:
- Authorization Code (con PKCE). Apps user-facing.
- Client Credentials. Server-to-server.
- Refresh Token. Token long-lived para obtener nuevos access tokens.
- Device Code. Devices sin browser.
Consideraciones de seguridad
- HTTPS es obligatorio.
- TTLs cortos. Access tokens 15min-1h típico.
- Storage cliente seguro. Browser SPAs: httpOnly secure cookie. Mobile: Keychain/Keystore.
- Revocación de token. Implementar endpoint de introspection o revocation.
- Minimización de scope.
- Rotar refresh tokens.
- Validación de audience e issuer.
Errores comunes con bearer tokens
- Almacenar tokens en localStorage en apps browser. Ataques XSS leen localStorage.
- Loggear tokens. Logs server pueden capturar headers Authorization. Filtrar.
- Access tokens long-lived.
- Sin rotación de refresh token.
- Confiar en claims JWT sin verificar firma.
- Usar HS256 cuando RS256 es apropiado.
Testing de APIs bearer-token at scale
- Issuance de token es una API. Pre-emitir tokens o mockear auth server.
- Token expira mid-test. Implementar lógica refresh en scripts.
- Tokens per-user vs shared. Tokens per-VU para resultados realistas.
- Testear paths de revocación.
FAQ: Bearer tokens
¿Son seguros los bearer tokens?
Sí, cuando se manejan correctamente: solo HTTPS, TTLs cortos, storage seguro de cliente, minimización de scope.
¿Cuál es la diferencia entre un bearer token y un JWT?
Bearer token es una categoría — cualquier cosa enviada en header Authorization: Bearer. JWT es un formato específico de bearer token con claims embebidos y firma.
¿Cuánto debería durar un bearer token?
Access tokens: 15 minutos a 1 hora. Refresh tokens: horas a días.
¿Puedo revocar un JWT bearer token?
No nativamente — JWTs son válidos hasta expiry. Revocación requiere denylist o estrategia TTL corto + rotación de refresh token.
¿Qué pasa si mi bearer token es robado?
El ladrón tiene acceso completo hasta que el token expira. Por eso TTLs cortos importan.
¿Puedo usar bearer tokens en apps browser?
Sí, pero con cuidado. Almacenar en cookies httpOnly secure (no localStorage).
Testea APIs protegidas por bearer-token con LoadFocus
Si estás load-testeando APIs que usan bearer tokens, LoadFocus corre scripts JMeter y k6 desde 25+ regiones cloud con soporte nativo para flows OAuth, gestión de headers y rotación de token per-VU. Regístrate en loadfocus.com/signup — sin tarjeta de crédito — y corre tu primer load test API autenticado en menos de 5 minutos.
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus — la misma plataforma que potencia todo lo que acabas de leer.