RFC 6750

Standards & Rfcs Security Notes Jan 6, 2025 HTTP

Definition

So you have an access token from OAuth 2.0 - now what? How do you actually send it to an API to prove you are authorized? That is what RFC 6750 answers. It is the specification that tells you exactly how to transmit bearer tokens when making API requests, essentially standardizing the “show your ID” part of the authentication process.

The term “bearer token” is key here: whoever “bears” (carries) the token gets access. It is like a concert ticket that does not have your name on it - whoever shows up with the ticket gets in. This makes bearer tokens simple and flexible, but it also means protecting them is absolutely critical. If someone steals your token, they can impersonate you.

RFC 6750 defines three ways to send bearer tokens, but strongly recommends one of them: the Authorization header. You have probably seen this pattern thousands of times if you have worked with APIs: Authorization: Bearer eyJhbGci.... This approach keeps the token out of URLs (which get logged everywhere) and out of request bodies (which can cause issues with content types). The other two methods - putting the token in the URL or in a form field - exist for edge cases but come with serious drawbacks.

Example

Every time you use a mobile app: When you open Instagram and it loads your feed, the app is sending your bearer token with every single request to Instagram’s servers. “Show me the feed” goes with “and here is proof I am allowed to see it.” You never see this happening, but it occurs dozens of times per minute.

API testing tools: When developers use tools like Postman or Insomnia to test APIs, they paste their access token into the Authorization header. Every request they make to the API includes that token, proving they have permission.

Command-line API access: When you use curl to interact with APIs from your terminal, you type something like curl -H "Authorization: Bearer abc123" https://api.example.com/data. That is RFC 6750 in action - you are including your bearer token in the header.

Microservices talking to each other: In modern systems, services constantly communicate with each other. When your order service needs to check inventory, it sends a bearer token to prove it has permission to access that data. Thousands of these requests happen every second in large systems.

Analogy

The Concert Wristband: At music festivals, once you pass through security, you get a wristband. Every time you move between stages, access VIP areas, or buy drinks, you just show your wristband. You do not have to show your ID or ticket again - the wristband is your bearer token. But if someone steals your wristband, they get all your access.

The All-Access Press Pass: Journalists at events wear press passes around their necks. Every time they want to enter a restricted area, they just show the pass. It does not have any secret code they need to remember - just having the pass grants access. Bearer tokens work the same way.

The Subway Card: A prepaid subway card lets anyone who holds it ride the train. The turnstile does not ask “are you the person who bought this card?” - it just checks if the card has value. Bearer tokens are similarly “blind” to who is using them.

The Gym Key Tag: That little tag on your keychain that gets you into the gym does not require a PIN or fingerprint scan - you just scan it and the door opens. Whoever has the tag can get in, which is why you would not lend it to strangers.

Code Example


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

// Method 2: Form-Encoded Body (POST/PUT only)
POST /api/resource HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded

access_token=eyJhbGciOiJIUzI1NiIs...

// Method 3: URI Query Parameter (NOT RECOMMENDED - visible in logs)
GET /api/resource?access_token=eyJhbGciOiJIUzI1NiIs... HTTP/1.1
Host: api.example.com

// Error response when token is invalid
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="The access token expired"

Security Notes

SECURITY NOTES

CRITICAL: RFC 6750 defines Bearer Token usage. How to use tokens in HTTP requests.

Bearer Token Header:

  • Authorization header: Bearer [token]
  • Token in header: Standard way to send token
  • No other methods: Don’t send in body/URL

Usage:

  • Protected resources: Send token to access resources
  • Token validation: Server validates token
  • Token expiration: Return 401 if token expired
  • Token refresh: Client refreshes expired token

Security:

  • HTTPS mandatory: Always transmit over HTTPS
  • Token storage: Store securely (httpOnly cookies)
  • Token theft: Token theft grants access
  • Token revocation: Cannot revoke without server-side store