Access Token vs Refresh Token: What Really Happens When Your Login “Expires”

Open any app that keeps you logged in for days — your email, your bank, a food delivery app — and something interesting is happening that you never see. Behind the scenes, your login is quietly expiring and being renewed, over and over, sometimes every few minutes. You never notice, because the app was built not to bother you with it.

That whole quiet system runs on two small pieces of text called tokens — an access token and a refresh token. They sound similar, and most explanations either drown you in cryptography or wave their hands and move on. Let's fix that, in plain words, and then get to the question people actually want answered: what happens if one gets stolen?

A quick analogy before any jargon

Think about checking into a hotel. At the front desk, you show your ID and pay. In return, you get a room key card. It doesn't prove who you are in any deep sense — it just opens door 214. It works for anyone holding it, it's only good for a few days, and if you lose it, the hotel deactivates that specific card and hands you a new one. You don't re-show your ID for that — the front desk remembers you checked in, and can issue replacement cards until checkout.

That's almost exactly the relationship between the two tokens:

• The key card is your access token— short-lived, used constantly, disposable.
• Your checked-in status at the front desk is your refresh token— what lets you get a new key card without re-showing ID every time.

Hold onto that picture. Everything below is just this idea, in more detail.

What is an access token?

An access token is a small piece of text your app sends with every single request to prove "this is really coming from a logged-in user." It rides in a header:

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.abc123

A few things are almost always true about it:

• It's short-lived — commonly 5 to 15 minutes.
• It's sent constantly — every API call attaches it.
• The server checks it without a database lookup in most modern setups (many access tokens are JWTs, verified by signature rather than a lookup).
• It usually can't be cancelled early. Since checking it doesn't touch a database, the server can't reach out and revoke one that's already out in the wild — it just has to wait for it to expire.

That last point explains almost everything else in this article. If a token can't be cancelled early, the only lever left is making it expire fast.

What is a refresh token?

A refresh token is a longer-lived credential — days or weeks — whose only job is getting you a new access token once the old one dies. It's treated very differently:

• It's not sent with normal requests. It only ever goes to one dedicated endpoint.
• The server does track it, usually in a database, specifically so it can be revoked. This is what makes a "log out of all devices" button possible.
• It lives longer on purpose, so you're not retyping your password every 15 minutes.

Back to the hotel: the refresh token is your reservation on file at the front desk — not something you flash at every door, but what lets the desk hand you a new key when the old one stops working.

Side by side

| | Access Token | Refresh Token | | — -| — -| — -| | Job | Proves identity on every request | Gets a new access token | | Lifetime | Minutes | Days to weeks | | Sent on every API call? | Yes | No | | Can be revoked early? | Usually not | Usually yes | | Damage if stolen | Small, capped | Serious, but contained |

What actually happens when your access token expires

1. Your app sends a request with the old token.
2. The server checks it, sees the expiry time has passed.
3. It rejects the request — almost always with 401 Unauthorized. Not a crash, not a blank screen.
4. The token doesn't get extended. It's just dead.

If the app stopped there, you'd see a login screen every 15 minutes. It doesn't, because of what happens next — quietly, in the background.

The silent refresh

1. The client catches that specific 401.
2. It sends the refresh token to a separate endpoint (something like POST /auth/refresh) — never the same place the failed request went.
3. The server looks the refresh token up in its own records and confirms it's real, unrevoked, and unused.
4. It issues a brand-new access token — and usually a brand-new refresh token too, retiring the old one. This is called rotation.
5. The client silently retries the original request.
6. You see a page load. That's it.

Three requests happened where you experienced one. That's the entire trick behind apps that never seem to log you out — right up until the refresh token itself expires or gets revoked, at which point you finally do see a real login screen again.

So — can a stolen access token actually be used?

Here's the honest answer, not the comfortable one: yes. An access token is a "bearer" token — whoever holds it can use it, no extra password check required. If a copy leaks while it's still valid, it works for whoever has it.

What keeps that from being a disaster is that several small limits stack on top of each other:

• The clock. A 5–15 minute lifetime gives an attacker a tiny window.
• Scope. It's often limited to specific actions — reading your profile, say, not changing your password.
• No self-renewal. An access token alone can't mint a new one. Once it expires, a thief holding only this token is locked out for good.
• Encrypted transport. Over HTTPS, it isn't readable in transit — realistic leaks come from XSS or a compromised device, not someone sniffing Wi-Fi.
• Anomaly detection. Plenty of systems flag a token suddenly used from a new country and cut it off early.

A stolen access token is closer to finding someone's hotel key card in a hallway than stealing their identity. It might open one door, briefly. It doesn't get a new key, and it stops working soon — permanently.

The one that actually deserves your worry

A stolen refresh token is a bigger deal, because it's built to last so much longer. If access-token theft is a leaky bucket, refresh-token theft is the tap itself.

That's why real systems don't treat it casually:

• It's stored more carefully — often in an HttpOnly cookie that JavaScript can't read at all.
• Rotation means a copied token is only good until the real owner's app refreshes next — after which the stolen copy is already dead.
• Reuse detection is the clever part: if an already-used, supposedly dead refresh token shows up again, that's not a coincidence — it means two parties have a copy. The server revokes the entire chain, logging out the attacker and the real user.
• It can be killed on command, which is how "log out everywhere" buttons work.

None of this makes it harmless. It makes it contained — bounded by rotation, watched by reuse detection, and killable on demand, instead of a permanent skeleton key.

Why split one token into two at all

There's a real tension here: you want identity checks that are cheap on every request, but anything cheap to check usually can't be cancelled early — and anything that can't be cancelled early is dangerous if it leaks.

Splitting one credential into two resolves the tension instead of picking a side. The thing used constantly gets made cheap and disposable. The thing that's dangerous if leaked gets used rarely, so it can afford to be tracked, rotated, and revoked.

It's the same reason the hotel doesn't ask for your ID at every door, but also doesn't hand out master keys at the front desk. Fast and frequent gets a disposable pass. Rare and powerful gets a real check.

— -

There's no magic keeping you logged in for days. There's a short-lived access token quietly expiring every few minutes, a 401 you never see, and a refresh token working behind the scenes to get you a new one — until it, too, eventually expires and asks you to log in for real.

The honest answer to "what if a token leaks" was never "it's impossible." It's that the system is deliberately built so the damage has a ceiling, whichever one leaks. That's the entire point of using two tokens instead of one.

I write about API testing and web security at OrbitTest. The full technical version of this piece — with a request/response test matrix and an extended FAQ — is here: [Access Token vs Refresh Token Explained]