How Access and Refresh Tokens Work

#accesstoken #refreshtoken #oauth #backend

Ever wondered how apps like Netflix and Facebook keep you logged in for months without ever asking for your password again? I used to just take it for granted - until I actually dug into how it works under the hood. Turns out, two small things are responsible for that seamless experience: access tokens and refresh tokens.
Let's break it down.

Modern apps don't pass your username and password around with every request. That would be like showing your passport every single time you walk through a door inside a building you've already entered. It's unnecessary, and honestly, a huge security risk.
Instead, protocols like OAuth 2.0 and OpenID Connect (OIDC) use tokens. You prove who you are once, get a token, and that token does the talking for you from that point on.

Here's the simple version of what happens when you hit "Login":

You make a request to the app — say, "Login with Google."
The app reaches out to an Authorization Server (Google, in this case), which checks your identity and hands back an authorization code. That code is then exchanged for your tokens.
From that point on, the app uses your access token to fetch your data from the Resource Server — all without you doing anything.

The Authorization Server handles who you are. The Resource Server handles what you're allowed to do.

The Access Token

Think of the access token as your daily pass. Every time the app needs to fetch your data or perform an action on your behalf, it attaches the access token to the request. The server looks at it, says "yep, this person is allowed," and responds.
But here's the thing — this token is short-lived, usually only valid for few minutes to a few hours.
Why so short? Because it's exposed a lot. It travels with almost every request, which means there are more opportunities for it to be intercepted. If someone does steal it, keeping it short-lived means the damage window is tiny. They can't do much with a token that expires in few minutes.
A long-lived access token would be a nightmare from a security standpoint. The longer it's valid, the more time an attacker has to exploit it.

The Refresh Token

Now here's where it gets interesting. If the access token expires every 20 minutes, why aren't you constantly being logged out and forced to re-enter your password?
That's the refresh token's job.
The refresh token is long-lived — we're talking days, weeks, sometimes even months. But it doesn't travel with every request like the access token does. It sits quietly in the background and only gets used for one thing: getting a new access token when the old one expires.
When your access token dies, the app uses the refresh token to silently request a fresh one from the Authorization Server — and you don't feel a thing. No interruption, no login screen, nothing.
One important thing though — the refresh token never goes to the Resource Server. It only ever talks to the Authorization Server. This separation is intentional and keeps it much safer than the access token.

Quick Comparison

Why Not Just Use One Token?

This is the question that stumped me at first too. Why bother with two?
Here's the honest answer: one token doing everything is a security disaster waiting to happen.
If you had a single long-lived token that was sent with every request, stealing it would give an attacker full access for a long time — and there's not much you could do about it quickly.
By splitting it into two:

The access token gets exposed often, so it's kept short-lived — stolen token, small problem.
The refresh token is exposed rarely, so it can afford to live longer — and it's much easier to revoke on the server side if something feels off.