JWT Authentication in Spring Boot: Complete Architecture, Implementation & Interview Guide

curiouswomen

15 min read

·

Aug 31, 2026

--

Listen

Share

JWT (JSON Web Token) is one of the most commonly used mechanisms for implementing stateless authentication in modern REST APIs.

For a Java/Spring Boot backend developer with around 4 years of experience, it is not enough to know that “JWT is a token.” You should be able to explain:

• Why JWT is used
• How a JWT is generated
• What a secret key is
• How the secret key is managed
• What is inside a JWT
• How the server validates the token
• How Spring Security establishes authentication
• Why JWT authentication is stateless
• What happens when a token expires
• How this architecture changes in production
• Common security mistakes and interview questions

This article covers the complete JWT authentication flow from login to authenticated API requests.

1. What Problem Does JWT Solve?

Consider a REST API where a user first logs in:

POST /api/auth/login

{
    "email": "user@example.com",
    "password": "password"
}

The backend verifies the credentials.

The question is:

How does the backend recognize this user in subsequent requests?

For example:

GET /api/groups
GET /api/expenses
POST /api/expenses
GET /api/balances

The client needs to send some proof of authentication with every request.

JWT provides that mechanism.

The basic flow is:

LOGIN
               │
               ▼
        Email + Password
               │
               ▼
       Verify Credentials
               │
               ▼
         Generate JWT
               │
               ▼
      Return JWT to Client
               │
               ▼
     Client stores token
               │
               ▼
   Sends JWT with every request
               │
               ▼
       Server validates JWT
               │
               ▼
       Authenticate User

2. Why JWT Instead of Server-Side Sessions?

Traditional session-based authentication generally works like this:

Client
   │
   │ Login
   ▼
Server
   │
   │ Create Session
   ▼
Session Store
   │
   └── sessionId
          │
          ▼
       Client

The server maintains session state.

With JWT:

Client
   │
   │ Login
   ▼
Server
   │
   │ Generate signed JWT
   ▼
Client

The token itself carries information required to identify the authenticated user.

The server doesn’t need to maintain a traditional login session for every user.

This makes JWT particularly useful for REST APIs and distributed systems.

Important interview point

JWT does not mean authentication is automatically secure or scalable.

JWT is simply a token format and mechanism for carrying signed claims.

The architecture around it still matters.

3. High-Level JWT Architecture

A typical Spring Boot architecture looks like this:

CLIENT
                          │
                          │
                    POST /login
                          │
                          ▼
                  ┌──────────────┐
                  │ AuthController│
                  └──────┬───────┘
                         │
                         ▼
                  ┌──────────────┐
                  │ AuthService  │
                  └──────┬───────┘
                         │
                   Verify password
                         │
                         ▼
                  ┌──────────────┐
                  │ UserRepository│
                  └──────┬───────┘
                         │
                    User found?
                         │
                        YES
                         │
                         ▼
                  ┌──────────────┐
                  │  JWTService  │
                  └──────┬───────┘
                         │
                  Generate JWT
                         │
                         ▼
                       Client

For subsequent requests:

Client
   │
   │ Authorization: Bearer <JWT>
   ▼
Spring Security Filter Chain
   │
   ▼
JWT Authentication Filter
   │
   ▼
Validate JWT
   │
   ▼
Extract User Identity
   │
   ▼
Load User / Authorities
   │
   ▼
Create Authentication
   │
   ▼
SecurityContext
   │
   ▼
Controller

This distinction is extremely important:

JWT generation happens during login. JWT validation happens on subsequent requests.

4. What Exactly Is a JWT?

A JWT usually looks like:

xxxxx.yyyyy.zzzzz

It consists of three Base64URL-encoded sections:

HEADER.PAYLOAD.SIGNATURE

For example:

eyJhbGciOiJIUzI1NiJ9
.
eyJzdWIiOiJ1c2VyQGV4YW1wbGUuY29tIiwiZXhwIjoxNzU2NjM...
.
signature

The three components are:

┌──────────────┐
│    Header    │
├──────────────┤
│   Payload    │
├──────────────┤
│  Signature   │
└──────────────┘

5. JWT Header

The header contains metadata about the token.

For example:

{
  "alg": "HS256",
  "typ": "JWT"
}

Important fields include:

alg

The signing algorithm.

For example:

HS256

typ

The token type:

JWT

The header is not secret.

6. JWT Payload

The payload contains claims.

Example:

{
  "sub": "user@example.com",
  "iat": 1756627200,
  "exp": 1756630800
}

Common claims include:

ClaimMeaningsubSubject / user identityiatIssued-at timeexpExpiration timeissIssueraudAudiencejtiJWT ID

You can also have application-specific claims:

{
    "sub": "user@example.com",
    "role": "USER"
}

However, do not put sensitive information such as:

password
passwordHash
credit card number
private secrets

inside a normal JWT payload.

Why?

Because the payload is encoded, not encrypted.

Anyone holding the token can decode the header and payload.

The signature protects integrity, not confidentiality.

This is one of the most important JWT interview points.

7. What Is the JWT Secret Key?

This is often misunderstood.

The JWT secret key is not the user’s password.

It is a cryptographic key owned by the application.

For an HMAC algorithm such as HS256:

JWT Data
   +
Secret Key
   ↓
Cryptographic Signature

The server later uses the same secret to verify that signature.

Conceptually:

APPLICATION
                      │
                 Secret Key
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        User A      User B      User C
         JWT          JWT         JWT

Therefore:

One application secret can be used to sign tokens for many users.

It is not one secret per user.

8. Why Do We Need the Secret Key?

Suppose the server generates a token containing:

{
    "sub": "user@example.com",
    "role": "USER"
}

A malicious client might decode the token and modify:

USER

to:

ADMIN

Without a signature, the server could not reliably detect this modification.

With a signature:

Original Header
      +
Original Payload
      +
Secret Key
      ↓
Signature

When the request arrives:

Received Header
      +
Received Payload
      +
Server Secret
      ↓
Verify Signature

If the payload was modified:

Modified Payload
      ↓
Different Signature
      ↓
❌ Validation fails

Therefore:

The signature provides integrity and authenticity of the token contents.

9. JWT Secret: One Per User or One Per Application?

This is a common interview question.

Incorrect mental model

User A → Secret A
User B → Secret B
User C → Secret C

Typical HMAC-based JWT architecture

Application
     │
     └── Secret Key
           │
     ┌─────┼─────┐
     ▼     ▼     ▼
   JWT-A JWT-B JWT-C

The same application secret signs tokens for multiple users.

You may use different secrets across environments:

Development → Secret Dev
Staging     → Secret Staging
Production  → Secret Production

This prevents a development secret from being used against production.

10. How Should We Generate the Secret Key?

Do not manually invent something like:

jwt.secret=mysecret123

For production, use a cryptographically secure random key.

With JJWT, an HS256 key can be generated using the library’s key-generation API:

SecretKey key = Jwts.SIG.HS256.key().build();

The generated key can then be encoded for configuration/storage.

Conceptually:

Secure Random Key Generator
          ↓
       SecretKey
          ↓
      Key Bytes
          ↓
      Base64 Encoding
          ↓
Configuration / Secret Store

The important point is:

Generate the cryptographic key using a secure key generator, rather than creating a human-readable password and treating it as a cryptographic key.

11. Why Should We Generate the Secret Only Once?

This is another very important architectural concept.

Imagine the application generates a new secret every time it starts:

Application starts
       ↓
Generate Secret A
       ↓
Issue JWT
       ↓
Application restarts
       ↓
Generate Secret B

The previously issued JWT was signed with:

Secret A

But the restarted application now has:

Secret B

Therefore:

Old JWT
   ↓
Verify using Secret B
   ↓
❌ Invalid

Every restart would effectively invalidate existing tokens.

Therefore:

The signing key should be stable for the lifetime of the tokens that it needs to validate.

The application should load the configured key during startup, not generate a new key every startup.

12. Where Should the Secret Be Stored?

For a local learning project:

jwt.secret=<secret>

This is acceptable for understanding the implementation.

But do not commit real production secrets to Git.

A production application could use:

Environment Variables

or a dedicated secret-management solution such as:

AWS Secrets Manager
HashiCorp Vault
Kubernetes Secrets
Cloud-specific secret stores

The architecture becomes:

Secret Manager
      ↓
Application Startup
      ↓
JWT Configuration
      ↓
JWTService

The key principle is:

The source of the secret can change; the JWTService should simply receive the correct signing key.

13. JWT Generation in Spring Boot

A simplified JWT service can look like:

@Service
public class JwtService {

    private final SecretKey secretKey;
    private final long expiration;    public JwtService(
            SecretKey secretKey,
            @Value("${jwt.expiration}") long expiration) {        this.secretKey = secretKey;
        this.expiration = expiration;
    }    public String generateToken(String email) {        Instant now = Instant.now();        return Jwts.builder()
                .subject(email)
                .issuedAt(Date.from(now))
                .expiration(Date.from(now.plusMillis(expiration)))
                .signWith(secretKey)
                .compact();
    }
}

The exact implementation can vary depending on your JJWT and Spring Boot versions, but the architecture remains the same.

14. Breaking Down JWT Generation

Consider:

Jwts.builder()

This starts constructing the JWT.

Then:

.subject(email)

identifies the user.

For example:

{
    "sub": "user@example.com"
}

Issued At

.issuedAt(...)

adds:

iat

This represents when the token was issued.

Expiration

.expiration(...)

adds:

exp

For example:

Token created → 4:00 PM
Expires       → 5:00 PM

If:

jwt.expiration=3600000

then:

3,600,000 ms
     ↓
3,600 seconds
     ↓
60 minutes
     ↓
1 hour

Sign the Token

.signWith(secretKey)

This is where the JWT gets its cryptographic signature.

Conceptually:

Header
   +
Payload
   +
Secret Key
   ↓
Signature

Compact

Finally:

.compact()

produces the serialized JWT string:

HEADER.PAYLOAD.SIGNATURE

This is the value returned to the client.

15. Complete Login Flow

Let’s connect everything.

The client sends:

POST /api/auth/login
Content-Type: application/json

{
    "email": "user@example.com",
    "password": "password"
}

The request reaches:

AuthController
      ↓
AuthService

The service finds the user:

UserRepository
      ↓
User

The stored password should be a hash, not the original password.

For example:

Raw Password
      ↓
PasswordEncoder
      ↓
BCrypt Hash

During login:

Raw Password
      +
Stored Password Hash
      ↓
PasswordEncoder.matches(...)
      ↓
Valid / Invalid

If valid:

AuthService
      ↓
JWTService
      ↓
Generate JWT
      ↓
Return JWT

16. JWT Generation Architecture

LOGIN
                      │
                      ▼
               ┌─────────────┐
               │    Client   │
               └──────┬──────┘
                      │
                email/password
                      │
                      ▼
               ┌─────────────┐
               │AuthController│
               └──────┬──────┘
                      │
                      ▼
               ┌─────────────┐
               │ AuthService │
               └──────┬──────┘
                      │
                 Verify Password
                      │
                      ▼
               ┌─────────────┐
               │UserRepository│
               └──────┬──────┘
                      │
                   User exists
                      │
                      ▼
               ┌─────────────┐
               │  JWTService │
               └──────┬──────┘
                      │
              ┌───────┼────────┐
              │       │        │
              ▼       ▼        ▼
           subject   issued    expiry
                      at
              │       │        │
              └───────┼────────┘
                      │
                      ▼
                  SecretKey
                      │
                      ▼
                    SIGN
                      │
                      ▼
                  JWT Token
                      │
                      ▼
                    Client

17. What Happens After Login?

The client receives:

JWT Token

For future API requests, it sends:

Authorization: Bearer <JWT>

For example:

GET /api/expenses
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

Now the request enters the Spring Security filter chain.

18. JWT Authentication Filter

This is the other half of JWT authentication.

The filter typically performs these steps:

Incoming Request
      ↓
Extract Authorization Header
      ↓
Check "Bearer "
      ↓
Extract JWT
      ↓
Validate JWT
      ↓
Extract User Identity
      ↓
Load User Details
      ↓
Create Authentication
      ↓
Put Authentication in SecurityContext
      ↓
Continue Filter Chain

This is fundamentally different from token generation.

Generation

Login
 ↓
Generate JWT

Validation

Every protected request
 ↓
Read JWT
 ↓
Validate JWT
 ↓
Authenticate user

19. What Does JWT Validation Actually Check?

A JWT validation process can include:

1. Signature

Was the token signed using the expected signing key?

Signature valid?

2. Expiration

Has the token expired?

exp > current time?

3. Structure

Is it a valid JWT?

4. Claims

Are required claims present and acceptable?

For example:

sub exists?
issuer correct?
audience correct?

The exact checks depend on the application’s security requirements.

20. How Does Spring Security Know the User Is Authenticated?

After successfully validating the JWT, the filter can create an Authentication object.

Conceptually:

UsernamePasswordAuthenticationToken authentication =
        new UsernamePasswordAuthenticationToken(
                userDetails,
                null,
                userDetails.getAuthorities()
        );

Then:

SecurityContextHolder
        .getContext()
        .setAuthentication(authentication);

Now Spring Security considers the request authenticated.

The controller can then access the authenticated principal.

Conceptually:

JWT
 ↓
JWT Filter
 ↓
Authentication
 ↓
SecurityContext
 ↓
Controller

This is one of the most important Spring Security concepts to understand.

21. Complete End-to-End Flow

Putting everything together:

┌──────────────┐
                    │    CLIENT    │
                    └──────┬───────┘
                           │
                     Login Request
                           │
                           ▼
                    ┌──────────────┐
                    │AuthController│
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │ AuthService  │
                    └──────┬───────┘
                           │
                    Verify Password
                           │
                           ▼
                    ┌──────────────┐
                    │UserRepository│
                    └──────┬───────┘
                           │
                         Valid
                           │
                           ▼
                    ┌──────────────┐
                    │  JWTService  │
                    └──────┬───────┘
                           │
                     Create Claims
                           │
                           ▼
                       SecretKey
                           │
                           ▼
                         SIGN
                           │
                           ▼
                         JWT
                           │
                           ▼
                        CLIENT
                           │
                           │
                 Authorization: Bearer JWT
                           │
                           ▼
                ┌────────────────────┐
                │ Spring Security    │
                │ Filter Chain       │
                └─────────┬──────────┘
                          │
                          ▼
                ┌────────────────────┐
                │ JWT Auth Filter    │
                └─────────┬──────────┘
                          │
                     Validate JWT
                          │
                          ▼
                  Extract User ID
                          │
                          ▼
                   Load UserDetails
                          │
                          ▼
                   Authentication
                          │
                          ▼
                  SecurityContext
                          │
                          ▼
                     Controller
                          │
                          ▼
                    Business Logic

22. Why Is JWT Called Stateless Authentication?

With traditional session authentication:

Client
   ↓
Session ID
   ↓
Server
   ↓
Session Store

The server needs to maintain session information.

With JWT:

Client
   ↓
JWT
   ↓
Server validates token

The authentication state is represented by the token rather than a traditional server-side session.

Therefore, JWT-based authentication is commonly described as stateless.

But be precise in interviews

Don’t say:

“JWT has no state.”

A better answer is:

“JWT authentication can be stateless because the server does not need to maintain a traditional authentication session for each client. The token carries signed claims that the server can validate independently.”

23. Stateless Does Not Mean No Database Calls

This is a subtle but important point.

Suppose the JWT contains:

{
    "sub": "user@example.com"
}

The server may still query the database:

JWT
 ↓
email
 ↓
UserRepository
 ↓
User

That does not automatically make JWT authentication stateful.

Statelessness refers primarily to the authentication mechanism not depending on a server-side session.

Whether you query the database for user details, roles, account status, etc. is an architectural choice.

24. JWT vs Encryption

Another common interview mistake:

“JWT encrypts the user’s information.”

Usually, this is incorrect.

A standard signed JWT is generally:

Encoded + Signed

not:

Encrypted

Therefore:

Anyone holding the JWT
        ↓
Can decode payload

But:

Anyone modifies payload
        ↓
Signature becomes invalid
        ↓
Server rejects token

If confidentiality is required, encryption must be designed separately, such as using an encrypted token/JWE or another appropriate mechanism.

25. Why Do We Need Token Expiration?

Imagine a token never expires:

JWT
 ↓
Valid forever

If the token is stolen, an attacker may be able to use it for a very long time.

Therefore, access tokens should generally have a limited lifetime.

Example:

Access Token
   ↓
Expires in 15 minutes / 30 minutes / 1 hour

After expiration:

Request
 ↓
JWT
 ↓
exp < current time
 ↓
❌ Unauthorized

26. What Happens When the JWT Expires?

The client must obtain a new valid access token.

A common production architecture uses:

Short-lived Access Token
+
Longer-lived Refresh Token

For example:

Access Token
   → short lifetime

Refresh Token
   → longer lifetime

Flow:

Login
 ↓
Access Token + Refresh Token
 ↓
Access Token expires
 ↓
Client sends Refresh Token
 ↓
Server validates refresh token
 ↓
New Access Token

This reduces the exposure window of an access token while avoiding forcing the user to log in frequently.

The exact refresh-token design depends on the application’s security requirements.

27. What Happens If the User Logs Out?

This is one of JWT’s biggest architectural differences from traditional sessions.

With a traditional session:

Logout
 ↓
Invalidate Session

With a purely stateless JWT:

Logout
 ↓
Client deletes token

But if an attacker already has a copy of the token, deleting the client’s copy does not invalidate the attacker’s copy.

Therefore, production systems may need additional mechanisms such as:

• Short-lived access tokens
• Refresh-token rotation
• Refresh-token revocation
• Token/session tracking
• Token denylisting in specific scenarios

This is why saying:

“JWT logout is simply deleting the token”

is incomplete for a senior-level interview.

28. JWT Security Best Practices

1. Never hard-code production secrets

Avoid:

private static final String SECRET = "my-secret";

Prefer:

Environment variable
Secret Manager
Vault
Kubernetes Secret

2. Never commit secrets to Git

Bad:

jwt.secret=production-secret

inside a public repository.

3. Use strong cryptographic keys

Do not use:

password123
mysecret
abc123

as your signing key.

Use a cryptographically generated key of an appropriate size.

4. Keep access tokens short-lived

A shorter lifetime reduces the damage window if a token is stolen.

5. Don’t store sensitive information in JWT payload

Remember:

JWT payload ≠ encrypted storage

6. Validate important claims

Depending on your architecture, validate:

signature
expiration
issuer
audience
subject

7. Use HTTPS

Even if the JWT is correctly signed, transmitting it over an insecure connection can expose it to attackers.

Always protect authentication traffic with TLS/HTTPS.

29. HS256 vs RS256

A strong backend interview should also know the difference.

HS256

Uses symmetric cryptography:

Same Secret
             /         \
            /           \
       Signing        Verification

The same secret is used for both signing and verification.

Good for:

Single application
Simple architecture
Internal services where key distribution is manageable

RS256

Uses asymmetric cryptography:

Private Key → Sign
Public Key  → Verify

Architecture:

Authorization Server
       │
   Private Key
       │
      Sign
       │
      JWT
       │
       ▼
 Other Services
       │
   Public Key
       │
    Verify

This becomes useful in distributed systems where many services need to verify tokens but should not possess the signing private key.

Interview answer

“HS256 uses one shared symmetric key for signing and verification, while RS256 uses a private key for signing and a public key for verification. RS256 is often preferable when multiple services need to verify tokens without being given the ability to create valid tokens.”

30. Why Is RS256 Often Useful in Microservices?

Imagine:

Auth Service
                  │
            Private Key
                  │
                Sign
                  │
                 JWT
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
   Expense     Payment    Group
   Service     Service    Service

All services need to verify the JWT.

With HS256:

All services need shared secret

That means every service that can verify tokens also possesses the secret needed to create valid signatures.

With RS256:

Auth Service
   ↓
Private Key
   ↓
Sign

Other services
   ↓
Public Key
   ↓
Verify

The private signing key remains centralized.

This is a major reason asymmetric signing is attractive in distributed architectures.

31. Common JWT Architecture in a Production System

A mature architecture could look like:

┌───────────────┐
                         │ Authentication│
                         │    Service    │
                         └───────┬───────┘
                                 │
                           Private Key
                                 │
                               SIGN
                                 │
                                JWT
                                 │
              ┌──────────────────┼──────────────────┐
              ▼                  ▼                  ▼
        Expense Service    Group Service      Payment Service
              │                  │                  │
         Public Key         Public Key         Public Key
              │                  │                  │
           VERIFY             VERIFY             VERIFY

This architecture becomes especially useful when the application evolves into microservices.

32. Where Does Spring Security Fit?

Spring Security provides the infrastructure around authentication and authorization.

A simplified request flow is:

HTTP Request
     ↓
Spring Security Filter Chain
     ↓
JWT Authentication Filter
     ↓
JWT Validation
     ↓
Authentication
     ↓
SecurityContext
     ↓
Authorization Rules
     ↓
Controller

Authentication answers:

Who are you?

Authorization answers:

Are you allowed to perform this operation?

For example:

Authentication:
user = nandini@example.com

Authorization:
role = USERPOST /admin/users
       ↓
Access denied

33. Authentication vs Authorization

This distinction is extremely important in interviews.

Authentication

Determines identity.

Who are you?

Example:

JWT
 ↓
subject = user@example.com
 ↓
User identified

Authorization

Determines permissions.

What are you allowed to do?

Example:

USER
 ↓
Can create expense

ADMIN
 ↓
Can manage users

JWT can carry information used for authorization, such as roles or permissions, but Spring Security is responsible for enforcing the application’s authorization rules.

34. A Strong 4-Year Experience Interview Answer

If the interviewer asks:

“Explain how you implemented JWT authentication in your Spring Boot application.”

A strong answer would be:

“We implemented stateless authentication using Spring Security and JWT. During login, the client sends credentials to our authentication endpoint. We retrieve the user and verify the raw password against the stored BCrypt hash using PasswordEncoder. If authentication succeeds, our JWT service creates a signed token containing claims such as the user’s identity and expiration time. The token is signed using a securely generated application signing key, which is externalized from the application and managed through configuration or a secret-management mechanism in production.

The client sends the token in the Authorization header as a Bearer token for subsequent requests. A custom JWT authentication filter runs within the Spring Security filter chain, extracts the token, validates its signature and claims such as expiration, and identifies the user. We then create an Authentication object and put it into the SecurityContext. Spring Security can subsequently use that authentication for authorization decisions before the request reaches the controller.

Since we’re not relying on a traditional server-side authentication session, this gives us a stateless authentication model. For production, I’d also consider short-lived access tokens, refresh-token rotation/revocation, HTTPS, secure secret management, and asymmetric signing such as RS256 if multiple services need to verify tokens.”

That is much stronger than:

“We use JWT because it is secure and stateless.”

35. Common Interview Questions

Q1. Is JWT encrypted?

Answer: Not normally. A standard JWT is encoded and signed. Its payload can be decoded. The signature protects integrity; it does not provide confidentiality.

Q2. Why do we need a secret key?

Answer: The signing key is used to create and verify the JWT signature, allowing the server to detect tampering and establish that the token was signed by a trusted issuer.

Q3. Is the secret key different for every user?

Answer: No. With a typical HMAC implementation, the application has a signing secret that can be used for tokens belonging to many users.

Q4. Should we generate a new secret every application startup?

Answer: No. If we do that, previously issued tokens become unverifiable after restart. The signing key should be persisted and loaded from configuration or a secret manager.

Q5. Where should the JWT secret be stored?

Answer: Never hard-code production secrets or commit them to source control. Use environment variables or a dedicated secret-management solution such as a cloud secret manager or Vault.

Q6. What are the three parts of JWT?

Answer:

Header.Payload.Signature

Q7. What is exp?

Answer: The expiration-time claim. It indicates when the token should no longer be accepted.

Q8. What is sub?

Answer: The subject claim, commonly used to represent the identity associated with the token.

Q9. What happens if someone modifies the JWT payload?

Answer: The signature will no longer match the modified header and payload, so signature validation should fail.

Q10. Can someone read JWT data?

Answer: Yes. Unless additional encryption is used, the header and payload are readable by anyone who possesses the token.

Q11. Why use JWT instead of sessions?

Answer: JWT can support stateless authentication, which can simplify horizontal scaling and distributed architectures because the authentication state doesn’t have to be maintained as a traditional server-side session.

Q12. How does logout work with JWT?

Answer: In a purely stateless design, deleting the token on the client doesn’t invalidate a stolen token. Production systems often address this using short-lived access tokens, refresh-token rotation/revocation, or other token-management mechanisms.

Q13. HS256 vs RS256?

Answer:

HS256
Symmetric
Same key → Sign + Verify

RS256
Asymmetric
Private key → Sign
Public key  → Verify

RS256 can be advantageous in distributed systems because verification services don’t need access to the private signing key.

36. The Mental Model to Remember

Don’t memorize individual JWT APIs.

Remember this architecture:

LOGIN
                      │
                      ▼
             Email + Password
                      │
                      ▼
              Verify Password
                      │
                      ▼
                 User Valid?
                      │
                     YES
                      │
                      ▼
                Create Claims
                      │
                      ▼
                Sign with Key
                      │
                      ▼
                     JWT
                      │
                      ▼
                    Client
                      │
                      │
          Authorization: Bearer JWT
                      │
                      ▼
              Security Filter Chain
                      │
                      ▼
               JWT Validation
                      │
                      ▼
            Extract User Identity
                      │
                      ▼
              Authentication
                      │
                      ▼
             SecurityContext
                      │
                      ▼
                 Controller
                      │
                      ▼
              Business Logic

And remember these five concepts:

1. Authentication
       ↓
   Who is the user?

2. JWT
       ↓
   Signed token carrying claims3. Secret/Key
       ↓
   Used to create/verify signature4. Filter
       ↓
   Validates JWT on incoming requests5. SecurityContext
       ↓
   Holds authenticated user information

37. Final Takeaway

JWT authentication is not simply:

Login → Generate Token → Done

A complete implementation consists of two major phases:

JWT AUTHENTICATION

         ┌───────────────────────┐
         │   1. TOKEN GENERATION │
         └───────────┬───────────┘
                     │
                Login request
                     │
                Verify password
                     │
                Create claims
                     │
                 Sign JWT
                     │
                     ▼
                    JWT
                     │
                     │
         ┌───────────▼───────────┐
         │   2. TOKEN VALIDATION  │
         └───────────┬───────────┘
                     │
               Incoming request
                     │
                 Read JWT
                     │
               Verify signature
                     │
              Validate expiration
                     │
              Identify the user
                     │
              Create Authentication
                     │
              SecurityContext
                     │
                     ▼
                  Controller

For a senior Java backend developer, the key is understanding why each component exists, not merely remembering the code.

The complete mental model is:

Credentials establish identity → JWT represents that authenticated identity → cryptographic signing protects token integrity → the security filter validates the token → Spring Security establishes Authentication → authorization rules decide what the user can access.

Once this flow is clear, implementing JWT with Spring Security becomes much easier — and you can also reason about more advanced topics such as refresh tokens, key rotation, OAuth2/OIDC, RS256, API gateways, and microservice authentication.