The basics of bearer tokens in b2c

Ever wonder how your phone stays logged into Spotify without asking for a password every five minutes? It’s usually a bearer token doing the heavy lifting behind the scenes.

Think of it like a boarding pass for your api. Once you have it, you just show it and get in—no more ID checks required. As explained in this guide to bearer tokens, the "bearer" of the string gets access, which is why we must protect them like house keys.

• Possession-based: If you hold it, you're authorized.
• Stateless: The server doesn't need to store your session; the token has the data.
• Standardized: Most b2c apps use OAuth 2.0 to keep things consistent across platforms like healthcare or retail.
• JWT (JSON Web Token): This is the common format used for bearer tokens. It’s basically a encoded string that holds the user info and permissions in a way the api can read.
• Token Types: You got two main ones. The ID token is for the client app to know who the user is (like showing their name), while the access token is what you actually send to the api to get data.

According to Microsoft, these tokens contain "claims" that tell the api exactly what permissions you got.

In retail, this lets a user view their cart but not someone else's. So, how do we actually build these?

How consumer identity authorization works

So, you got a login button, but what actually happens when a user clicks it? It's not magic, it’s a handoff between your app and an identity provider.

In most b2c setups, we use the authorization code flow. Your app sends the user to a login page, they prove who they are, and the server sends back a temporary code. Then, your backend swaps that code for the actual bearer token.

• The Authorize Endpoint: This is the front door where users enter their credentials. This is also where passwordless login happens—using things like passkeys or biometrics. It’s way better because there isn't a password to steal, users don't have to remember "P@ssword123!", and it ties the session to a specific device.
• The Token Endpoint: A secure, back-channel call where the "code" is exchanged for the access_token. You also get a Refresh Token here. These are long-lived and used to get a new access token once the old one expires, so the user doesn't have to login again every hour.
• The redirect: After login, the browser jumps back to your app with the goods.

Scopes are basically the "rules of the house." You don't want a fitness app having access to your bank balance, right? When requesting a token, the client asks for specific scopes like read:profile or write:orders.

As noted earlier, these show up in the scp claim of the jwt. In healthcare, a patient app might only get read:records, while a doctor's portal gets write:prescriptions. Always follow least privilege—if they don't need it, don't ask for it.

Next up, we’ll look at how to actually validate these tokens so nobody can just fake their way into your api.

Validating tokens on the resource server

So, you got the token. Cool. But how do you know it isn't just some junk string a hacker threw at your api? If you don't validate it properly, you're basically leaving the back door unlocked.

Validation usually happens right at the middleware level. You gotta check a few things before letting the request through:

• Signature check: Use the jwks endpoint from your provider to get the public key. If the signature doesn't match, drop it.
• Claims verification: Ensure the iss (issuer) is actually your auth server and the aud (audience) matches your api's client id.
• Timing is everything: Check exp (expiry) and nbf (not before). Don't let old or "future" tokens in.

For high-security apps, like in finance or healthcare, you might even check a revocation list to see if a user logged out early.

In a retail app, this prevents someone from using an old token to buy stuff on your dime. Next, we'll talk about how to keep these tokens from getting stolen in the first place.

Securing the token lifecycle

So, you’ve built a great api, but how do you stop it from becoming a playground for hackers? If a bearer token is like a house key, we need to make sure nobody can just copy it or find it under the doormat.

The truth is, even with the best login, a token can still be snatched if you're careless. I've seen too many devs dump tokens into localStorage because it’s easy. Don't do that. It’s a goldmine for XSS attacks.

• Rotation and TTL: Keep your access tokens short-lived (low Time to Live). If a token only lasts 15 minutes, the damage an attacker can do is limited. Use refresh token rotation so every time a new access token is requested, you get a new refresh token too.
• Revocation: You need a way to kill a token if a device is lost. Your backend should be able to invalidate refresh tokens instantly.
• Storage: Use HttpOnly cookies. It keeps the token away from malicious scripts.
• Https is non-negotiable: If you're not using it, you’re basically shouting the token across a crowded room.

A study by logto reminds us that bearer tokens are "possession-based"—whoever holds it, owns the session. Treat them like cash.

Since we've covered the lifecycle, let's look at some common mistakes people make when setting this up.

Common pitfalls in consumer api security

Look, we've all been there—it's 2 AM, you're trying to push a feature, and you just want the api to work. But cutting corners on bearer tokens is how data breaches start.

I've seen plenty of smart devs trip over these same three things:

• Hardcoding Secrets: Putting a client_secret inside a mobile app is like leaving your house keys in the lock. If I can download your app, I can find that secret.
• Token Confusion: Don't use an id_token to authorize api calls. As mentioned earlier, those are for identity (telling the app who the user is). Use an access_token for permissions; otherwise, you're asking for trouble.
• Forever Tokens: Setting an expiry for "9999 days" is a nightmare. If a token gets snatched in a retail app, that attacker has a permanent pass to the user's data.

flowchart TD
    A[Dev Shortcut] --> B{Mistake Made}
    B --> C[Hardcoded Secret]
    B --> D[Wrong Token Type]
    B --> E[Infinite Expiry]
    C & D & E --> F[Security Breach]

Building secure b2c apps isn't just about code; it's about trust. If you handle tokens right—short lives, proper validation, and no secrets in the frontend—you're ahead of most. Stay safe out there.

*** This is a Security Bloggers Network syndicated blog from MojoAuth - Advanced Authentication & Identity Solutions authored by MojoAuth - Advanced Authentication & Identity Solutions. Read the original post at: https://mojoauth.com/blog/what-is-passkey-account-login