DEV Community

arafatruetbd
arafatruetbd

Posted on

Why Do APIs Use Bearer <token>? A Beginner-Friendly Explanation đŸ»

#api #beginners #security #tutorial

If you’ve ever worked with APIs, you’ve probably come across something like this:

Authorization: Bearer abc123
Enter fullscreen mode Exit fullscreen mode

And maybe you paused for a second and thought:

Why “Bearer”? Is there a bear involved? đŸ»

Not quite but the concept is actually pretty simple.

What Is a Bearer Token?

Think of a bearer token like a concert ticket.

Whoever holds the ticket gets in. No questions asked.

Similarly, whoever holds a valid token can access the API.

Valid ticket → Enter concert
Valid token → Access API
Enter fullscreen mode Exit fullscreen mode

That’s why it’s called a Bearer token the person “bearing” (holding) the token gets access.

Why Not Just Send the Token?

You might wonder why we don’t just send the token like this:

Authorization: abc123
Enter fullscreen mode Exit fullscreen mode

The problem is, the server wouldn’t know what that value represents. Is it a password? An API key? Something else?

By adding the word Bearer, we give the server context:

Authorization: Bearer abc123
Enter fullscreen mode Exit fullscreen mode

Now the server understands:

This is a bearer token. I know how to handle and validate it.

Different Types of Authorization

The Authorization header isn’t limited to bearer tokens. It supports multiple authentication schemes:

Authorization: Basic <credentials>
Authorization: Bearer <token>
Authorization: Digest <credentials>
Enter fullscreen mode Exit fullscreen mode

The first word acts like a label, telling the server how to interpret the rest.

Here’s a quick breakdown:

Basic   → Username and password  
Bearer  → Access token  
Digest  → Challenge-response authentication
Enter fullscreen mode Exit fullscreen mode

Without this label, the server would have to guess and that’s not something servers are good at (or enjoy).

Why Is Bearer So Popular?

Because it’s standardized and widely supported.

Most API gateways, backend frameworks, and authentication libraries already understand this format. It’s easy to parse and implement.

For example:

const [scheme, token] = authorizationHeader.split(" ");
Enter fullscreen mode Exit fullscreen mode

This gives you:

scheme = "Bearer";
token = "abc123";
Enter fullscreen mode Exit fullscreen mode

Simple, clean, and no need for custom headers or complex parsing logic.

Are Bearer Tokens Always JWTs?

Nope.

A JWT (JSON Web Token) is just one type of bearer token:

Authorization: Bearer eyJhbGciOi...
Enter fullscreen mode Exit fullscreen mode

But bearer tokens can also be simple random strings:

Authorization: Bearer x7a91k2p
Enter fullscreen mode Exit fullscreen mode

The key takeaway:

Bearer = how the token is sent  
JWT = one possible format of the token
Enter fullscreen mode Exit fullscreen mode

Why HTTPS Matters

Bearer tokens are like cash if someone gets hold of them, they can use them.

That’s why you should always send them over HTTPS:

HTTPS ✅
HTTP  ❌
Enter fullscreen mode Exit fullscreen mode

Also, avoid putting tokens in URLs:

/api/profile?token=abc123
Enter fullscreen mode Exit fullscreen mode

URLs can be stored in browser history, logs, and analytics tools, making them less secure.

The Authorization header is the safest and most standard place to include your token.

Final Thoughts

When you see this:

Authorization: Bearer <token>
Enter fullscreen mode Exit fullscreen mode

It simply means:

“Hey API, I’m using Bearer authentication, and here’s my access token.”

It’s popular because it’s clear, standardized, and supported across modern web technologies.

And no still no actual bears involved. đŸ»

Top comments (0)