Authentication is one of those topics every backend engineer uses, but surprisingly few understand deeply.
If you've interviewed for a backend role, you've probably heard questions like:
- What is JWT?
- Is JWT an Access Token?
- Why do we need Refresh Tokens?
- What does Stateless Authentication mean?
- If JWTs are stateless, how do you logout?
- What happens if someone steals my token?
Let's answer all of them.
Step 1: Authentication
Authentication simply answers one question.
Who are you?
When you log in:
Email
Password
↓
Authentication ServerThe server verifies your credentials.
If they're correct, it doesn't expect you to send your password on every API request.
Instead, it gives you a token.
Step 2: What Is A Token?
A token is simply proof that you've already authenticated.
Instead of sending:
Email
Passwordwith every request, you send:
Authorization: Bearer eyJhbGciOiJIUzI1Ni...The server validates the token and knows who you are.
Think of it like entering an office.
You show your ID card once.
After that, security recognizes your badge instead of asking for your passport every time.
Step 3: What Is A JWT?
JWT stands for JSON Web Token.
It is not authentication itself.
It is simply a format for representing claims.
A JWT has three parts.
Header
.
Payload
.
SignatureA typical JWT looks like this.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJ1c2VySWQiOjEwMSwicm9sZSI6IlVTRVIifQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cHeader
Contains metadata.
{
"alg":"HS256",
"typ":"JWT"
}Payload
Contains claims about the user.
{
"userId":101,
"email":"jitesh@gmail.com",
"role":"USER",
"exp":1719000000
}Notice something important.
Passwords should never appear inside a JWT.
Typical claims include:
- User ID
- Role
- Expiration Time
Anyone holding the token can decode the payload because it is Base64URL encoded, not encrypted.
Never store secrets inside a JWT.
Signature
The signature prevents tampering.
HMACSHA256(
Header +
Payload +
Secret Key
)If someone changes:
role = USERto
role = ADMINthe signature becomes invalid.
The server immediately rejects the request.
JWT Is Signed, Not Encrypted
One common interview question is:
Can users read a JWT?
Yes.
JWT payloads are encoded, not encrypted.
Anyone can decode them using websites like jwt.io.
The signature only guarantees integrity.
It does not hide the contents.
Is JWT An Access Token?
Not exactly.
A JWT is a format.
An Access Token is a purpose.
Think of it like this.
Passport
↓
Format
Visa
↓
PurposeSimilarly,
JWT
↓
Token Format
Access Token
↓
Used To Access APIsMost modern systems simply use a JWT as the Access Token.
But they don't have to.
Some companies issue random opaque strings instead.
What Is An Access Token?
The Access Token is sent with every protected API request.
GET /profile
Authorization: Bearer <Access Token>The server checks:
- Is the signature valid?
- Has the token expired?
If yes,
200 OKOtherwise,
401 UnauthorizedAccess Tokens are intentionally short-lived.
Typical expiration:
5 Minutes
10 Minutes
15 MinutesWhy Short Lived?
Imagine someone steals your Access Token.
If it expires in:
10 Minutesthe attacker has very little time.
If it expires in:
30 Daysthey have an entire month.
What Is A Refresh Token?
A Refresh Token is not sent with every request.
Its only job is to obtain a new Access Token.
Typical lifetime:
30 Days
60 Days
90 DaysLogin Flow
User Login
↓
Verify Username & Password
↓
Issue
Access Token
+
Refresh TokenNow every API call uses the Access Token.
When it expires:
POST /refreshThe Refresh Token is exchanged for a new Access Token.
The user never notices.
Where Should Tokens Be Stored?
This is another favorite interview question.
Access Token
Usually stored:
- In memory
- Secure HTTP-only cookies
Avoid Local Storage for sensitive applications because XSS attacks can steal tokens.
Refresh Token
Usually stored:
- HTTP-only Secure Cookie
On the server:
- Database
- Redis
- Hashed in persistent storage
This allows immediate revocation.
What Does Stateless Mean?
Stateless means:
The server does not remember previous requests.
Session Authentication
User Login
↓
Session ID
↓
Database
↓
Session123
↓
User101Every request requires a database lookup.
JWT Authentication
JWT
↓
Verify Signature
↓
Extract Claims
↓
ContinueNo session lookup is required just to identify the user.
Everything needed already exists inside the token.
That's why JWT authentication scales so well.
If JWTs Are Stateless, How Do You Logout?
This is the interview question everyone eventually gets.
Since the server isn't tracking Access Tokens, it cannot magically destroy one.
Production systems combine multiple techniques.
1. Short Lived Access Tokens
Expire within 5 to 15 minutes.
2. Refresh Token Revocation
Delete the Refresh Token.
DELETE
FROM refresh_tokens
WHERE user_id = 101;The attacker cannot obtain new Access Tokens.
3. Token Blacklist
Maintain revoked JWT IDs inside Redis.
if(redis.exists(jwtId)){
rejectRequest();
}Useful for banking and enterprise applications.
4. Token Versioning
Store a version number for every user.
Users
id
token_version
3JWT
{
"userId":101,
"version":3
}Every request compares the JWT version with the database.
if(jwt.version != user.tokenVersion){
reject();
}Increment the version to instantly invalidate every existing token.
Refresh Token Rotation
Another advanced interview topic.
Every refresh request returns:
Old Refresh Token
↓
Invalid
↓
New Refresh TokenIf the old Refresh Token is ever reused:
Possible Token Theft
↓
Terminate SessionThis protects against stolen Refresh Tokens.
Common JWT Claims
Interviewers sometimes ask about standard JWT fields.
{
"sub":"101",
"iss":"auth-service",
"aud":"mobile-app",
"iat":1719000000,
"exp":1719003600,
"jti":"uuid"
}Important ones include:
- sub → Subject (User ID)
- exp → Expiration
- iat → Issued At
- iss → Issuer
- aud → Audience
- jti → Unique Token ID
Common Interview Mistakes
❌ Storing passwords inside JWTs
❌ Long-lived Access Tokens
❌ Storing tokens in Local Storage without understanding XSS risks
❌ Assuming JWTs are encrypted
❌ Saying JWTs cannot be revoked
Interview Summary
If someone asks:
Why do we need both Access Tokens and Refresh Tokens?
A strong answer is:
Access Tokens are short-lived and sent with every API request, reducing the impact of token theft. Refresh Tokens are long-lived and used only to obtain new Access Tokens. Because Refresh Tokens are stored server-side and can be revoked, users stay logged in without repeatedly entering their credentials while the system maintains strong security.
Final Thoughts
JWTs are popular because they're lightweight, scalable, and eliminate database lookups for authentication.
But production authentication isn't just about issuing tokens.
A secure authentication system combines:
- Short-lived Access Tokens
- Refresh Tokens
- Token Rotation
- Revocation Strategies
- Secure Storage
- Proper Claim Validation
Understanding these concepts doesn't just help you clear backend interviews—it helps you build authentication systems that are actually secure in production.