All notes

Everything Between Login and 'Welcome Back' (Part 2)

Learn how production authentication actually works. Access Tokens, Refresh Tokens, OAuth2, Logout, JWT Revocation, and security best practices explained for backend interviews.

6 min read

In Part 1, we learned how JWTs work and why they're called stateless.

Now let's answer the question that almost every interviewer eventually asks.

"If JWTs are stateless, how do you log users out?"

Before answering that, we need to understand Access Tokens and Refresh Tokens.

Step 1: Access Token

An Access Token is sent with every protected API request.

GET /profile
 
Authorization: Bearer <Access Token>

Whenever the server receives a request, it performs three checks.

If all checks pass...

200 OK

Otherwise...

401 Unauthorized

Most applications keep Access Tokens very short-lived.

5 Minutes
 
10 Minutes
 
15 Minutes

Why Short Lived?

Imagine someone steals your laptop.

If your Access Token is valid for:

30 Days

the attacker has an entire month.

Instead...

Access Token
 
↓
 
Expires In
 
10 Minutes

Even if stolen, its usefulness is very limited.

Step 2: Refresh Token

If Access Tokens expire every few minutes...

Wouldn't users have to log in constantly?

That's exactly why Refresh Tokens exist.

A Refresh Token is never sent with every API request.

Its only purpose is to obtain a new Access Token.

Typical lifetime:

30 Days
 
60 Days
 
90 Days

Login flow:

Login
 
↓
 
Verify Credentials
 
↓
 
Access Token
 
+
 
Refresh Token

After ten minutes...

Access Token
 
↓
 
Expired

Instead of asking the user to log in again...

POST /refresh

The Refresh Token is exchanged for a brand new Access Token.

The user never notices.

Step 3: Why Two Tokens?

Interview Question.

Why not just make the Access Token valid for 30 days?

Because security.

Suppose an attacker steals your token.

Access Token
 
30 Days
 
↓
 
Attacker Has Full Access

Instead...

Access Token
 
10 Minutes
 
+
 
Refresh Token
 
30 Days

The attacker has only a few minutes unless they also steal the Refresh Token.

Step 4: Where Should Tokens Be Stored?

This question appears surprisingly often.

Access Token

Usually stored in:

Avoid Local Storage for sensitive applications because XSS attacks may expose it.

Refresh Token

Usually stored inside:

HTTP Only
 
Secure
 
SameSite Cookie

Since JavaScript cannot read HTTP Only cookies, stealing them through XSS becomes much harder.

Many companies also store Refresh Tokens inside a database or Redis so they can revoke them immediately.

Step 5: Cookies vs Sessions vs JWT

This question confuses many developers.

Cookies

Cookies are simply a storage mechanism.

They can store:

A cookie itself is not authentication.

Sessions

Client
 
↓
 
Session ID
 
↓
 
Server Database
 
↓
 
User Information

Pros

Cons

JWT

Client
 
↓
 
JWT
 
↓
 
Verify Signature
 
↓
 
Continue

Pros

Cons

Step 6: OAuth2

Another favorite interview topic.

Imagine you click:

Continue with Google

Did Google send your password to Netflix?

Absolutely not.

Instead...

User
 
↓
 
Netflix
 
↓
 
Google Login
 
↓
 
User Grants Permission
 
↓
 
Authorization Code
 
↓
 
Netflix Backend
 
↓
 
Google
 
↓
 
Access Token
 
↓
 
User Information

Notice something important.

Netflix never learns your Google password.

Google simply tells Netflix:

"I have verified this user."

OAuth2 is Authorization, not Authentication.

Authentication is built on top of OAuth2 using protocols like OpenID Connect.

This distinction impresses interviewers.

Step 7: If JWT Is Stateless...

How Do We Logout?

Here's the problem.

JWT
 
↓
 
Already Issued
 
↓
 
Server Doesn't Store It

The server cannot magically delete something it never stored.

So production systems combine multiple techniques.

Solution 1

Short Lived Access Tokens

Probably the simplest solution.

Access Token
 
10 Minutes

Worst case...

An attacker gets ten minutes.

Solution 2

Revoke Refresh Tokens

Delete them.

DELETE
 
FROM refresh_tokens
 
WHERE user_id = 101;

Now no new Access Tokens can be created.

Solution 3

Redis Blacklist

Some industries can't even tolerate ten minutes.

Example:

Store revoked JWT IDs inside Redis.

if(redis.exists(jwtId)){
 
    rejectRequest();
 
}

Every request now checks Redis before accepting the token.

Solution 4

Token Versioning

This is one of my favorite interview answers.

Users table:

id
 
token_version
 
1

JWT

{
   "userId":101,
   "version":1
}

Every request compares versions.

if(jwt.version != user.tokenVersion){
 
    reject();
 
}

Need to logout from every device?

UPDATE users
 
SET token_version = token_version + 1;

Every existing JWT instantly becomes invalid.

Solution 5

Refresh Token Rotation

Instead of reusing Refresh Tokens forever...

Generate a new one every time.

Refresh Token A
 
↓
 
Exchange
 
↓
 
Refresh Token B

Refresh Token A immediately becomes invalid.

If somebody later tries using Token A...

Possible Token Theft
 
↓
 
Terminate Session

Many modern authentication providers use this approach.

Step 8: CSRF vs XSS

Another common interview topic.

XSS

Malicious JavaScript executes inside your website.

Goal:

Steal user information or authentication tokens.

Protection:

CSRF

The attacker tricks a logged-in user into performing unwanted actions.

Example:

Transfer Money
 
Delete Account
 
Change Password

Protection:

Step 9: Production Best Practices

A production authentication system usually combines:

✅ JWT Access Tokens

✅ Refresh Tokens

✅ HTTPS

✅ HTTP Only Secure Cookies

✅ Refresh Token Rotation

✅ Redis Blacklists

✅ MFA

✅ Rate Limiting

✅ Token Versioning

No single mechanism is enough.

Security comes from combining multiple layers.

Common Interview Questions

Can JWTs be revoked?

Yes.

Using Redis Blacklists, Token Versioning, or short-lived Access Tokens with Refresh Token revocation.

Is JWT encrypted?

No.

JWT is encoded.

Only the signature is protected.

Should passwords be stored inside JWTs?

Never.

JWTs should only contain claims.

Why not store Access Tokens in Local Storage?

Because XSS attacks can read Local Storage.

HTTP Only cookies provide much better protection.

Is OAuth2 Authentication?

No.

OAuth2 is an Authorization framework.

Authentication is commonly implemented using OpenID Connect on top of OAuth2.

Final Thoughts

Authentication isn't about choosing JWT or Sessions.

It's about balancing security, performance, and user experience.

The best production systems combine multiple techniques:

Understanding these tradeoffs is what separates someone who has simply used Spring Security from someone who understands how authentication actually works in production.

The next time an interviewer asks,

"If your JWT gets stolen, what would you do?"

You'll know the answer goes far beyond simply saying,

"We use JWT."

LinkedIn
X
Resume