RFC 6750

Definicion

Ya tienes un access token de OAuth 2.0 - ¿y ahora qué? ¿Cómo lo envías realmente a una API para demostrar que estás autorizado? Eso es exactamente lo que responde RFC 6750. Es la especificación que te dice exactamente cómo transmitir bearer tokens al hacer peticiones a APIs, básicamente estandarizando la parte de “muestra tu identificación” del proceso de autenticación.

El término “bearer token” es clave aquí: quien “porta” (lleva) el token obtiene acceso. Es como una entrada de concierto que no tiene tu nombre - quien aparezca con la entrada, entra. Esto hace que los bearer tokens sean simples y flexibles, pero también significa que protegerlos es absolutamente crítico. Si alguien roba tu token, puede hacerse pasar por ti.

RFC 6750 define tres formas de enviar bearer tokens, pero recomienda fuertemente una de ellas: el header Authorization. Probablemente has visto este patrón miles de veces si has trabajado con APIs: Authorization: Bearer eyJhbGci.... Este enfoque mantiene el token fuera de las URLs (que se registran en logs por todas partes) y fuera de los cuerpos de las peticiones (lo que puede causar problemas con tipos de contenido). Los otros dos métodos - poner el token en la URL o en un campo de formulario - existen para casos extremos pero vienen con serias desventajas.

Ejemplo

Cada vez que usas una app móvil: Cuando abres Instagram y carga tu feed, la app está enviando tu bearer token con cada petición a los servidores de Instagram. “Muéstrame el feed” va junto con “y aquí está la prueba de que tengo permiso para verlo”. Nunca ves esto ocurriendo, pero pasa docenas de veces por minuto.

Herramientas de testing de APIs: Cuando los desarrolladores usan herramientas como Postman o Insomnia para probar APIs, pegan su access token en el header Authorization. Cada petición que hacen a la API incluye ese token, demostrando que tienen permiso.

Acceso a APIs desde línea de comandos: Cuando usas curl para interactuar con APIs desde tu terminal, escribes algo como curl -H "Authorization: Bearer abc123" https://api.example.com/data. Eso es RFC 6750 en acción - estás incluyendo tu bearer token en el header.

Microservicios comunicándose entre sí: En sistemas modernos, los servicios se comunican constantemente entre ellos. Cuando tu servicio de pedidos necesita verificar el inventario, envía un bearer token para demostrar que tiene permiso para acceder a esos datos. Miles de estas peticiones ocurren cada segundo en sistemas grandes.

Analogia

La Pulsera del Festival: En festivales de música, una vez que pasas por seguridad, te dan una pulsera. Cada vez que te mueves entre escenarios, accedes a zonas VIP o compras bebidas, solo muestras tu pulsera. No tienes que mostrar tu DNI o entrada de nuevo - la pulsera es tu bearer token. Pero si alguien roba tu pulsera, obtiene todo tu acceso.

El Pase de Prensa con Acceso Total: Los periodistas en eventos llevan pases de prensa colgados del cuello. Cada vez que quieren entrar a una zona restringida, solo muestran el pase. No tiene ningún código secreto que necesiten recordar - simplemente tener el pase concede acceso. Los bearer tokens funcionan de la misma manera.

La Tarjeta del Metro: Una tarjeta de metro prepagada permite viajar a cualquiera que la tenga. El torno no pregunta “¿eres tú la persona que compró esta tarjeta?” - solo verifica si la tarjeta tiene saldo. Los bearer tokens son igualmente “ciegos” respecto a quién los usa.

La Llave del Gimnasio: Ese pequeño llavero que te permite entrar al gimnasio no requiere PIN ni escaneo de huella - simplemente lo pasas y la puerta se abre. Quien tenga el llavero puede entrar, por eso no se lo prestarías a extraños.

Code Example

// Método 1: Header Authorization (RECOMENDADO)
GET /api/users/me [HTTP/1.1](https://reference.apios.info/es/terms/http-1-1/)
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// Método 2: Body codificado en formulario (solo POST/PUT)
POST /api/resource HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded

access_token=eyJhbGciOiJIUzI1NiIs...

// Método 3: Parámetro en Query URI (NO RECOMENDADO - visible en logs)
GET /api/resource?access_token=eyJhbGciOiJIUzI1NiIs... HTTP/1.1
Host: api.example.com

// Respuesta de error cuando el token es inválido
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="The access token expired"

Notas de Seguridad