Access Tokens vs Refresh Tokens: How Your App Stays Secure (and Logged In)

Let's face it, nobody likes entering passwords over and over. But how do our favorite apps keep us logged in without making things insecure? The answer: access tokens and refresh tokens. Let’s talk about what these are—and why every modern app uses them.
The Basics: Access Token = Your Entry Ticket
Imagine checking in at a movie theater. At the door, you show your ticket. The ticket taker glances at it, sees it’s for tonight, and waves you in.
That’s your access token—a little digital ticket your app uses to say, “Hey, I’m allowed in!” Every time your app wants something from the server (like loading your latest messages), it presents the access token.
Short duration: Access tokens usually expire quickly—maybe in 15 minutes or an hour. If someone steals your ticket, they can’t use it for long.
How it works: The app sends the access token along with each request, often in the
Authorization
header.
The Magic Pass: Refresh Token
What if you want to watch another movie? Or leave the theater for snacks? You’d get tired of buying new tickets. So, imagine you have a special pass you can show at the counter to get a new ticket whenever you want. That’s your refresh token.
Longer life: Refresh tokens stick around much longer—days, sometimes weeks.
Quiet login: When your access token expires, your app quietly swaps the refresh token for a new access token... no need to bug you for your password.
Guard it well: If someone steals your refresh token, they can get as many tickets (access tokens) as they want, so it must be protected carefully (ideally in an HTTP-only cookie).
Why Both?
It’s about security and smooth user experience:
Access tokens are short-lived, so if someone snatches one, they don’t have much time to do damage.
Refresh tokens mean you stay logged in without typing your password every hour, but they must be guarded like the crown jewels.
Real-World Flow
Here’s how it actually works:
Login: You enter your password. The app receives an access token and a refresh token from the server.
Normal use: App uses the access token to fetch your data.
Token expires: When the access token runs out, the app quietly uses the refresh token to ask, “Can I get a new ticket?”
If refresh token is expired or invalid: You get logged out and need to log in again.
A Simple Example (in Node.js)
Here’s a peek at how a server might create these tokens:
javascriptimport jwt from 'jsonwebtoken';
const generateTokens = (userId) => {
const accessToken = jwt.sign(
{ _id: userId },
process.env.ACCESS_TOKEN_SECRET,
{ expiresIn: "15m" }
);
const refreshToken = jwt.sign(
{ _id: userId },
process.env.REFRESH_TOKEN_SECRET,
{ expiresIn: "7d" }
);
return { accessToken, refreshToken };
};
Tips for Staying Safe
Keep refresh tokens secret: Never share them with the browser’s JavaScript. Use HTTP-only cookies or store them on the server.
Short-lived access tokens: The shorter their lifespan, the safer.
Rotate refresh tokens: Issue a new refresh token each time the old one is used.
Log out = revoke tokens: Kick out both tokens when the user logs out or you spot anything suspicious.
Analogy Cheat Sheet
Access Token: Like a single-use movie ticket—valid for one show, limited time.
Refresh Token: Like a VIP backstage pass—lets you get a new ticket anytime, but you’d better not lose it!
—
With this setup, you get the best of both worlds: your app stays secure, your users stay logged in, and everyone’s happy. Happy coding!
Subscribe to my newsletter
Read articles from Dinkar directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
