OAuth2 Refresh Token Interview Questions and Answers
Learn OAuth2 Refresh Tokens with 10 interview questions, Mermaid diagrams, Spring Security examples, token lifecycle, and enterprise best practices.
OAuth2 Refresh Token - Interview Questions & Answers
An Access Token is intentionally short-lived for security reasons. If users had to log in every few minutes, the user experience would be poor.
OAuth2 solves this problem using a Refresh Token, which allows a client to obtain a new Access Token without asking the user to log in again.
Refresh Tokens are commonly used in Spring Security, Mobile Apps, Single Page Applications (SPA), Enterprise Applications, and Cloud Platforms.
Q1. What is a Refresh Token?
Answer
A Refresh Token is a long-lived credential issued by the Authorization Server that is used to obtain a new Access Token after the current one expires.
Unlike an Access Token, a Refresh Token is not sent to Resource Servers.
Refresh Token Flow
flowchart LR
User --> AuthorizationServer["Authorization Server"]
AuthorizationServer --> AccessToken["Access Token"]
AuthorizationServer --> RefreshToken["Refresh Token"]
AccessToken --> ResourceServer["Resource Server"]
RefreshToken --> AuthorizationServer
Benefits
- Better user experience
- Short-lived Access Tokens
- Improved security
Q2. Why do we need Refresh Tokens?
Answer
Access Tokens should expire quickly to reduce security risks.
Without Refresh Tokens:
- Users would need to log in repeatedly.
- Applications would have poor user experience.
- Sessions would be interrupted frequently.
Refresh Tokens solve this problem by allowing silent token renewal.
Token Lifecycle
flowchart TD
Login --> AccessToken["Access Token"]
AccessToken["Access Token"] --> Expires
Expires --> RefreshToken["Refresh Token"]
RefreshToken["Refresh Token"] --> NewAccessToken["New Access Token"]
Q3. How does a Refresh Token work?
Answer
The typical process is:
- User logs in.
- Authorization Server issues an Access Token and a Refresh Token.
- Access Token expires.
- Client sends the Refresh Token to the Authorization Server.
- Authorization Server validates the Refresh Token.
- A new Access Token is issued.
Complete Flow
sequenceDiagram
participant User
participant Client
participant AuthorizationServer
participant ResourceServer
User->>Client: Login
Client->>AuthorizationServer: Authenticate
AuthorizationServer-->>Client: Access Token + Refresh Token
Client->>ResourceServer: Access Token
ResourceServer-->>Client: Protected Data
Client->>AuthorizationServer: Refresh Token
AuthorizationServer-->>Client: New Access Token
Q4. What is the difference between an Access Token and a Refresh Token?
Answer
| Access Token | Refresh Token |
|---|---|
| Accesses APIs | Requests a new Access Token |
| Short-lived | Longer-lived |
| Sent to Resource Server | Sent only to Authorization Server |
| Frequently used | Used only when needed |
Comparison
flowchart TD
AccessToken["Access Token"] --> ProtectedAPI["Protected API"]
RefreshToken["Refresh Token"] --> AuthorizationServer["Authorization Server"]
AuthorizationServer --> NewAccessToken["New Access Token"]
Q5. Where should Refresh Tokens be stored?
Answer
Refresh Tokens must be stored securely because they provide long-term access.
Recommended storage:
| Platform | Recommended Storage |
|---|---|
| Web Application | HttpOnly Secure Cookie |
| Mobile Application | Keychain / Keystore |
| Backend Service | Secure Server Storage |
Avoid storing Refresh Tokens in browser Local Storage for sensitive applications.
Secure Storage
flowchart LR
RefreshToken --> SecureStorage
SecureStorage --> AuthorizationServer["Authorization Server"]
Q6. What happens when a Refresh Token expires or becomes invalid?
Answer
When a Refresh Token expires or is revoked:
- The Authorization Server rejects the request.
- No new Access Token is issued.
- The user must authenticate again.
Expired Refresh Token
flowchart TD
RefreshToken["Refresh Token"] --> AuthorizationServer["Authorization Server"]
AuthorizationServer["Authorization Server"] --> Expired?
Expired? --> Yes
Yes --> LoginAgain["Login Again"]
Q7. What is Refresh Token Rotation?
Answer
Refresh Token Rotation is a security technique where every successful refresh request returns:
- A new Access Token
- A new Refresh Token
The previous Refresh Token becomes invalid.
Rotation Flow
flowchart LR
RefreshToken1["Refresh Token 1"] --> AuthorizationServer["Authorization Server"]
AuthorizationServer["Authorization Server"] --> AccessToken2["Access Token 2"]
AuthorizationServer["Authorization Server"] --> RefreshToken2["Refresh Token 2"]
RefreshToken1["Refresh Token 1"] --> Invalid
Benefits
- Prevents replay attacks
- Limits token theft impact
- Improves security
Q8. What are common Refresh Token implementation mistakes?
Answer
Common mistakes include:
- Long-lived Access Tokens
- Never expiring Refresh Tokens
- Storing tokens in Local Storage
- Missing Refresh Token rotation
- Sending Refresh Tokens to Resource Servers
- Hardcoded client secrets
- No revocation support
Wrong Design
Refresh Token
↓
REST API ❌
Correct Design
Refresh Token
↓
Authorization Server ✅
Q9. How does Spring Security support Refresh Tokens?
Answer
Spring Authorization Server can issue and validate Refresh Tokens.
Typical architecture:
flowchart TD
User --> SpringAuthorizationServer["Spring Authorization Server"]
SpringAuthorizationServer["Spring Authorization Server"] --> AccessToken["Access Token"]
SpringAuthorizationServer["Spring Authorization Server"] --> RefreshToken["Refresh Token"]
RefreshToken["Refresh Token"] --> SpringAuthorizationServer["Spring Authorization Server"]
SpringAuthorizationServer["Spring Authorization Server"] --> NewAccessToken["New Access Token"]
NewAccessToken["New Access Token"] --> SpringResourceServer["Spring Resource Server"]
Spring Components
- Spring Security
- Spring Authorization Server
- OAuth2 Client
- Resource Server
- JWT Decoder
Q10. What are the enterprise best practices for Refresh Tokens?
Answer
Follow these best practices:
- Keep Access Tokens short-lived.
- Store Refresh Tokens securely.
- Use Refresh Token Rotation.
- Expire inactive Refresh Tokens.
- Revoke Refresh Tokens during logout.
- Protect token endpoints with HTTPS.
- Monitor suspicious refresh requests.
- Limit Refresh Token lifetime.
- Bind Refresh Tokens to the client where appropriate.
- Log refresh events for auditing.
Enterprise Token Architecture
flowchart TD
User --> IdentityProvider["Identity Provider"]
IdentityProvider["Identity Provider"] --> AuthorizationServer["Authorization Server"]
AuthorizationServer["Authorization Server"] --> AccessToken["Access Token"]
AuthorizationServer["Authorization Server"] --> RefreshToken["Refresh Token"]
AccessToken["Access Token"] --> ApiGateway["API Gateway"]
ApiGateway["API Gateway"] --> SpringBootApis["Spring Boot APIs"]
RefreshToken["Refresh Token"] --> AuthorizationServer["Authorization Server"]
Token Lifecycle
flowchart LR
Authenticate --> AccessToken["Access Token"]
AccessToken["Access Token"] --> Expires
Expires --> RefreshToken["Refresh Token"]
RefreshToken["Refresh Token"] --> NewAccessToken["New Access Token"]
NewAccessToken["New Access Token"] --> ProtectedApi["Protected API"]
Refresh Token Checklist
mindmap
root((Refresh Token))
Access Token Renewal
Secure Storage
Rotation
Revocation
HTTPS
Authorization Server
JWT
Spring Security
Monitoring
Senior Interview Tip
Refresh Tokens should never be treated like Access Tokens.
A production-ready OAuth2 implementation typically includes:
- Short-lived JWT Access Tokens
- Longer-lived Refresh Tokens
- Refresh Token Rotation
- Revocation Support
- Secure HttpOnly Cookies (for web applications)
- Spring Authorization Server
- API Gateway
- OAuth2 Scopes
- mTLS (for service-to-service communication)
- Zero Trust Architecture
Remember:
- Access Token → Used to access protected APIs.
- Refresh Token → Used only to obtain a new Access Token from the Authorization Server.
Quick Revision
- Refresh Tokens obtain new Access Tokens.
- They are issued by the Authorization Server.
- They are never sent to Resource Servers.
- Store Refresh Tokens securely.
- Use Refresh Token Rotation.
- Expire and revoke Refresh Tokens when appropriate.
- Always use HTTPS.
- Keep Access Tokens short-lived.
- Monitor refresh requests for suspicious activity.
- Combine Refresh Tokens with OAuth2, JWT, and Spring Security for enterprise applications.