JWT Claims - Interview Questions & Answers

JWT (JSON Web Token) claims are pieces of information stored inside the Payload section of a JWT. They describe the authenticated user, token metadata, permissions, and other information required by applications.

Claims allow APIs and microservices to make authorization decisions without querying the database on every request.

---

Q1. What are JWT Claims?

Answer

Claims are key-value pairs stored inside the JWT Payload.

They contain information about:

• User Identity
• Token Metadata
• Roles
• Permissions
• Expiration
• Issuer

JWT Structure

flowchart LR
A[JWT]

A --> B[Header]

A --> C[Payload - Claims]

A --> D[Signature]

Example Payload

{
  "sub":"venu",
  "role":"ADMIN",
  "department":"Payments",
  "exp":1750000000
}

---

Q2. Why are JWT Claims important?

Answer

Claims allow applications to identify users and make authorization decisions without additional database lookups.

Authentication Flow

flowchart TD
A[User Login] --> B[JWT Generated] --> C[Claims Stored] --> D[Client] --> E[Protected API] --> F[Read Claims] --> G[Authorize User]

Benefits

• Stateless Authentication
• Faster Authorization
• Reduced Database Calls
• Better Scalability

---

Q3. What are the different types of JWT Claims?

Answer

JWT defines three categories of claims.

Type	Purpose
Registered Claims	Standard JWT fields
Public Claims	Shared custom claims
Private Claims	Application-specific claims

Claim Categories

flowchart TD
A[JWT Claims]

A --> B[Registered Claims]

A --> C[Public Claims]

A --> D[Private Claims]

---

Q4. What are Registered Claims?

Answer

Registered Claims are predefined claim names defined in RFC 7519.

Claim	Description
iss	Issuer
sub	Subject
aud	Audience
exp	Expiration Time
nbf	Not Before
iat	Issued At
jti	JWT ID

Registered Claims

flowchart TD
A[Registered Claims]

A --> B[iss]

A --> C[sub]

A --> D[aud]

A --> E[exp]

A --> F[iat]

A --> G[jti]

Interview Tip

Using standard claim names improves interoperability between systems.

---

Q5. What are Public and Private Claims?

Answer

Public Claims

Public Claims are custom claims intended to be shared across multiple systems.

Example

{
   "department":"Finance",
   "country":"US"
}

---

Private Claims

Private Claims are application-specific.

Example

{
   "employeeId":"EMP101",
   "customerTier":"Gold"
}

Custom Claims

flowchart LR
A[Payload]

A --> B[Department]

A --> C[Role]

A --> D[Employee ID]

A --> E[Customer Tier]

---

Q6. Which claims are commonly used in enterprise applications?

Answer

Typical enterprise claims include:

Claim	Example
sub	User ID
email	User Email
role	ADMIN
permissions	READ, WRITE
department	Finance
tenant	Tenant ID
employeeId	EMP1001
organization	ABC Bank

Enterprise JWT

flowchart TD
A[JWT Payload]

A --> B[User ID]

A --> C[Role]

A --> D[Permissions]

A --> E[Department]

A --> F[Tenant]

These claims help implement Role-Based and Attribute-Based Authorization.

---

Q7. Why shouldn't sensitive information be stored inside JWT Claims?

Answer

JWT Payloads are Base64URL encoded, not encrypted.

Anyone possessing the token can decode the Payload.

JWT Visibility

flowchart LR
A[JWT] --> B[Base64URL Decode]

C[Readable Claims] --> C[Readable Claims]

Never Store

• Passwords
• Credit Card Numbers
• Aadhaar / SSN
• API Keys
• Database Passwords
• OTPs
• Encryption Keys

Safe Claims

• Username
• User ID
• Roles
• Permissions
• Token Expiration

---

Q8. How does Spring Security use JWT Claims?

Answer

Spring Security extracts claims from the JWT and builds the authenticated user's security context.

Spring Security Flow

flowchart TD
A[Incoming JWT] --> B[JWT Filter] --> C[Extract Claims] --> D[Create Authentication] --> E[SecurityContext] --> F[Controller]

Example

@PreAuthorize("hasRole('ADMIN')")

Spring Security checks the role claim before invoking the method.

---

Q9. What are common mistakes when designing JWT Claims?

Answer

Common mistakes include:

• Storing passwords
• Large Payloads
• Missing expiration
• Too many custom claims
• Using inconsistent claim names
• Not validating issuer
• Not validating audience
• Exposing confidential business data

Wrong Design

{
   "username":"venu",
   "password":"admin123"
}

Correct Design

{
   "sub":"venu",
   "role":"ADMIN",
   "exp":1750000000
}

---

Q10. What are the enterprise best practices for JWT Claims?

Answer

Follow these best practices:

• Use registered claims whenever possible.
• Keep claims minimal.
• Never store sensitive information.
• Include token expiration.
• Validate issuer and audience.
• Use meaningful custom claims.
• Standardize claim names across services.
• Rotate signing keys regularly.
• Use HTTPS for token transmission.
• Validate every incoming token.

Enterprise JWT Architecture

flowchart TD
A[User] --> B[Authentication Server] --> C[Generate JWT] --> D[JWT Claims] --> E[API Gateway] --> F[Spring Security] --> G[Microservices]

Claim-Based Authorization

flowchart LR
A[JWT] --> B[Extract Claims] --> C[Role Check] --> D[Permission Check] --> E[Business Service]

Senior Interview Tip

JWT Claims should contain only the information necessary for authentication and authorization.

A production-ready JWT typically includes:

• sub (Subject)
• iss (Issuer)
• aud (Audience)
• exp (Expiration)
• iat (Issued At)
• jti (JWT ID)
• role or authorities
• Minimal custom claims required by downstream services

Avoid putting sensitive or frequently changing information in claims, as issued JWTs generally remain unchanged until they expire or are replaced.

---

Quick Revision

• Claims are stored in the JWT Payload.
• There are three claim types: Registered, Public, and Private.
• Registered claims follow RFC 7519.
• Claims are used for authentication and authorization.
• Never store sensitive information in claims.
• Keep JWT Payloads small.
• Spring Security extracts claims to build the SecurityContext.
• Always validate issuer, audience, and expiration.
• Use standard claim names where possible.
• Enterprise applications use claims to enable scalable, stateless authorization.