JWT (JSON Web Token) in Banking Applications

Why JWT is Used

JWT is commonly used for:

• Authentication
• Authorization
• Identity Propagation Between Microservices
• API Security
• Single Sign-On (SSO)

In banking systems, JWT is commonly used between:

• Internet Banking → API Gateway
• Mobile Banking → Backend APIs
• Microservice → Microservice Communication
• OAuth2 / OpenID Connect Integrations

JWT Structure

A JWT contains three parts:

Header.Payload.Signature

Example JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

.

eyJzdWIiOiIxMjM0NSIsInJvbGUiOiJDVVNUT01FUiIsImV4cCI6MTcwMDAwMDAwMH0

.

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
        

Part 1: Header

The header contains metadata about the token.

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

Banking Recommendation

{
  "alg": "RS256"
}

RS256 is preferred over HS256 because asymmetric cryptography provides stronger security and better key management.

Part 2: Payload

The payload contains claims.

{
  "sub": "123456",
  "customerId": "CUST001",
  "role": "PREMIUM_CUSTOMER",
  "exp": 1700000000
}

Standard JWT Claims

Subject (sub)

{
  "sub":"12345"
}

Represents the user identity.

Issuer (iss)

{
  "iss":"bank-auth-service"
}

Identifies who issued the token.

Audience (aud)

{
  "aud":"payment-service"
}

Specifies who can consume the token.

Expiration (exp)

{
  "exp":1700000000
}

Defines token expiry time.

Issued At (iat)

{
  "iat":1699999999
}

Creation timestamp.

JWT ID (jti)

{
  "jti":"abc123xyz"
}

Unique token identifier used for revocation tracking.

Part 3: Signature

The signature ensures token integrity.

Base64(Header)
+
"."
+
Base64(Payload)
        

The resulting string is signed.

HMACSHA256(
 base64UrlEncode(header)
 +
 "."
 +
 base64UrlEncode(payload),
 secret
)
        

JWT Authentication Flow

Step 1: Customer Login

POST /login

{
  "username":"naresh",
  "password":"******"
}
        

Step 2: Authentication Service Validation

• Database
• LDAP
• Active Directory
• Identity and Access Management (IAM)

Step 3: JWT Generation

{
  "sub":"12345",
  "role":"CUSTOMER",
  "exp":"..."
}

Step 4: Client Stores JWT

• Mobile App
• Browser

Step 5: Subsequent Requests

GET /accounts

Authorization: Bearer eyJhbGc...
        

Step 6: API Gateway Validation

No database lookup is required.

Why JWT Became Popular

Traditional Session-Based Authentication

Client
   |
Server Session
   |
Redis
        

Every request requires a session lookup.

JWT-Based Authentication

Client
   |
JWT
   |
Microservices
        

No session lookup is required. JWT enables stateless and highly scalable systems.

JWT in Banking Microservices

Mobile App
     |
API Gateway
     |
---------------------------------
|       |        |             |
Account Payment Customer Loan
Service Service Service Service
        

Gateway validates JWT once and forwards claims downstream.

{
  "customerId":"12345",
  "role":"PREMIUM"
}

HS256 vs RS256

HS256

• Symmetric Key
• Same Secret Used for Signing and Verification
• Every Service Needs the Secret Key

RS256

• Asymmetric Key Pair
• Private Key → Sign
• Public Key → Verify

Typical Banking Architecture

Auth Server
    |
Private Key

Microservices
    |
Public Key
        

Microservices can verify tokens but cannot generate forged tokens.

JWT Security Risks

Risk 1: Sensitive Data in Payload

Wrong

{
  "accountNumber":"123456789",
  "balance":"500000"
}

JWT payloads are not encrypted.

Correct

{
  "customerId":"12345"
}

Risk 2: Long Expiration

{
  "exp":"30 days"
}

Long-lived tokens increase risk if stolen.

Banking Recommendation:

• Access Token: 10–15 Minutes
• Refresh Token: 24 Hours

Risk 3: Missing Audience Validation

{
  "aud":"payment-service"
}

Prevents token replay attacks.

Risk 4: Algorithm Attack

Never accept:

{
  "alg":"none"
}

Always whitelist approved algorithms such as RS256.

JWT vs Opaque Token

JWT

• Self-contained
• Contains Claims
• No Database Lookup

Opaque Token

a8hjsd789asd

• Requires Introspection Endpoint
• Additional Validation Call Required

/introspect

Banking Preference

• External Customers → Opaque Tokens
• Internal Microservices → JWT

JWT Revocation Challenges

JWT is stateless and difficult to revoke immediately.

Solution 1: Short Expiry

Access tokens expire within 10–15 minutes.

Solution 2: Blacklisting

{
  "jti":"abc123"
}

Store revoked token identifiers in Redis.

Solution 3: Token Versioning

User Table

token_version = 5
        

{
  "version":5
}

After logout, increment the version and invalidate older tokens.

JWT in OAuth2 Architecture

Customer
    |
Identity Provider
(Keycloak / Okta / ForgeRock)
    |
JWT
    |
API Gateway
    |
Microservices
        

Access Token: JWT

Refresh Token: Opaque Token

This is a common enterprise banking architecture.

Senior-Level Interview Answer

JWT is a stateless, signed token format used to securely transmit identity and authorization claims across distributed systems. In banking microservices, JWTs are typically issued by an OAuth2/OpenID Connect authorization server and validated at the API Gateway and service layers. A JWT consists of a header, payload, and signature. We generally prefer RS256 over HS256 because private keys remain only with the authorization server while microservices verify using public keys. In banking environments, JWT payloads should never contain sensitive customer data, only identifiers and authorization claims. Access tokens are kept short-lived, typically 10–15 minutes, with refresh tokens used for renewal. Additional controls such as audience validation, key rotation, token revocation strategies, and gateway-level verification are essential for regulatory and security compliance.

In enterprise banking systems, JWT tokens are typically signed using RS256 (RSA Signature Algorithm) rather than HS256 (HMAC SHA-256).

The primary reason is security, key management, regulatory compliance, and support for distributed microservices architectures.

HS256 Architecture

Auth Service
    |
 Shared Secret
    |
-------------------
| Account Service |
| Payment Service |
| Loan Service    |
-------------------
        

HS256 uses a symmetric key. The same secret key is used to both sign and verify JWT tokens.

How HS256 Works

• Authentication Service generates JWT.
• JWT is signed using a shared secret.
• Every microservice requires the same secret to validate the token.
• The same secret can also generate new tokens.

Problems with HS256

• Every service must store the secret.
• Compromise of one service compromises the entire platform.
• Any service can generate fake JWTs.
• Key rotation becomes difficult.
• Less suitable for large-scale distributed systems.

RS256 Architecture

                 Private Key
                      |
              Auth Service
                      |
                  JWT Token
                      |
------------------------------------------------
| Account Service   Public Key Verify          |
| Payment Service   Public Key Verify          |
| Loan Service      Public Key Verify          |
------------------------------------------------
        

RS256 uses asymmetric cryptography.

• Private Key → Sign JWT
• Public Key → Verify JWT

Only the Authentication Server has access to the private key. Microservices receive only the public key.

Benefits of RS256

• Only the Authorization Server can create tokens.
• Microservices can only verify tokens.
• Compromised services cannot forge JWTs.
• Supports Zero Trust Architecture.
• Simplifies key rotation.
• Meets banking regulatory requirements.

Comparison: HS256 vs RS256

Typical Banking Authentication Architecture

Customer
    |
Mobile Banking
    |
API Gateway
    |
OAuth2 Authorization Server
(Keycloak / ForgeRock / Okta)
    |
RS256 JWT
    |
--------------------------------
| Account Service             |
| Payment Service             |
| Customer Service            |
| Loan Service                |
--------------------------------
        

Advantages

• Stateless authentication
• No session replication
• Horizontal scalability
• Public/Private key cryptography
• Gateway-level JWT validation
• OAuth2/OpenID Connect compliance
• Zero Trust microservices security

Architect-Level Interview Answer

In banking environments, RS256 is preferred over HS256 because it separates token generation from token validation. The Authorization Server exclusively owns the private key used for signing JWTs, while downstream services use only public keys for verification. This eliminates the risk of services generating fraudulent tokens, simplifies key rotation, supports zero-trust architectures, and satisfies enterprise security and compliance requirements. For modern banking microservices, RS256 combined with OAuth2 and OpenID Connect is considered the industry-standard approach.

Problem with HS256

In HS256, every microservice shares the same secret key.

Auth Service
     |
 Shared Secret
     |
-------------------
| Account Service |
| Payment Service |
| Loan Service    |
-------------------
        

Challenges

• Every service has the secret key.
• Any service can generate fake tokens.
• Difficult key management.

Why Banks Prefer RS256

                 Private Key
                      |
              Auth Service
                      |
                  JWT Token
                      |
------------------------------------------------
| Account Service   Public Key Verify          |
| Payment Service   Public Key Verify          |
| Loan Service      Public Key Verify          |
------------------------------------------------
        

Advantages

• Only Authorization Server can sign tokens.
• Microservices can only verify tokens.
• Better auditability.
• Easier key rotation.
• Improved regulatory compliance.

Project Structure

com.bank.auth

├── controller
│     └── AuthController.java
│
├── config
│     └── SecurityConfig.java
│
├── security
│     ├── JwtService.java
│     ├── JwtAuthenticationFilter.java
│     └── KeyLoader.java
│
├── dto
│     ├── LoginRequest.java
│     └── LoginResponse.java
│
└── BankApplication.java
        

Generate RSA Keys

openssl genrsa -out private.pem 2048

openssl rsa \
-in private.pem \
-pubout \
-out public.pem
        

Store Keys

src/main/resources/keys

private.pem
public.pem
        

KeyLoader.java

Loads RSA private and public keys from PEM files.

package com.bank.auth.security;

@Component
public class KeyLoader {

    public PrivateKey loadPrivateKey() throws Exception {
        ...
    }

    public PublicKey loadPublicKey() throws Exception {
        ...
    }
}
        

JwtService.java

Responsible for generating and validating RS256 JWT tokens.

@Service
public class JwtService {

    public String generateToken(
            String username,
            String role)
            throws Exception {

        PrivateKey privateKey =
                keyLoader.loadPrivateKey();

        return Jwts.builder()
                .subject(username)
                .claim("role", role)
                .issuer("BANK-AUTH")
                .issuedAt(new Date())
                .expiration(
                        new Date(
                                System.currentTimeMillis()
                                        + 900000))
                .signWith(
                        privateKey,
                        SignatureAlgorithm.RS256)
                .compact();
    }

    public Claims validateToken(
            String token)
            throws Exception {

        PublicKey publicKey =
                keyLoader.loadPublicKey();

        return Jwts.parser()
                .verifyWith(publicKey)
                .build()
                .parseSignedClaims(token)
                .getPayload();
    }
}
        

JWT Authentication Filter

Intercepts every incoming request and validates JWT before allowing access to protected resources.

@Component
public class JwtAuthenticationFilter
        extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(
            HttpServletRequest request,
            HttpServletResponse response,
            FilterChain chain)
            throws ServletException, IOException {

        ...
    }
}
        

Security Configuration

@Configuration
public class SecurityConfig {

    @Bean
    SecurityFilterChain filterChain(
            HttpSecurity http)
            throws Exception {

        http
            .csrf(csrf -> csrf.disable())

            .sessionManagement(
                    session ->
                            session.sessionCreationPolicy(
                                    SessionCreationPolicy.STATELESS))

            .authorizeHttpRequests(auth ->
                    auth
                        .requestMatchers("/auth/login")
                        .permitAll()
                        .anyRequest()
                        .authenticated())

            .addFilterBefore(
                    filter,
                    UsernamePasswordAuthenticationFilter.class);

        return http.build();
    }
}
        

Banking Login Controller

@RestController
@RequestMapping("/auth")
public class AuthController {

    @PostMapping("/login")
    public LoginResponse login(
            @RequestBody LoginRequest request)
            throws Exception {

        if ("naresh".equals(request.getUsername())
                &&
                "bank123".equals(
                        request.getPassword())) {

            String token =
                    jwtService.generateToken(
                            request.getUsername(),
                            "CUSTOMER");

            return new LoginResponse(token);
        }

        throw new RuntimeException(
                "Invalid Credentials");
    }
}
        

JWT Flow in Banking

Customer
   |
Mobile Banking
   |
Login API
   |
Authentication Service
   |
Generate JWT (RS256)
   |
API Gateway
   |
Verify Signature
   |
Account Service
Payment Service
Loan Service
        

Architect-Level Interview Questions

Why Not Store Account Numbers in JWT?

JWT payloads are Base64 encoded, not encrypted. Anyone holding the token can decode the payload.

Incorrect

{
  "accountNumber":"12345678"
}
        

Never Store

• Account Number
• PAN
• Aadhaar
• Card Number
• Balance

Correct Approach

{
  "sub":"customer123",
  "role":"CUSTOMER",
  "scope":"PAYMENT"
}
        

JWT Revocation

Logout
   |
Redis Blacklist
   |
Store JTI
   |
Every Request
   |
Check JWT
Check Redis
   |
Reject Revoked Token
        

Refresh Token Flow

Token Lifetime

• Access Token: 15 Minutes
• Refresh Token: 24 Hours

Token Expired
      |
/refresh
      |
Validate Refresh Token
      |
Issue New JWT
        

JWT with Kafka

Producer Event

{
  "customerId":"123",
  "jwt":"eyJ..."
}
        

Consumer Processing

1. Validate Signature
2. Validate Expiry
3. Process Event

In enterprise banking systems, JWTs are usually propagated through Kafka headers rather than message payloads.

Complete Banking Authentication Architecture

                   ┌─────────────────┐
                   │ Mobile/Web App  │
                   └────────┬────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ API Gateway      │
                  │ Spring Gateway   │
                  └────────┬─────────┘
                           │
                           ▼
              ┌─────────────────────────┐
              │ Authorization Server    │
              │ OAuth2 / OIDC           │
              │ Keycloak / ForgeRock    │
              └──────────┬──────────────┘
                         │
              ┌──────────┴──────────┐
              │                     │
              ▼                     ▼
       Access Token           Refresh Token
       JWT (15 mins)          DB/Redis (24 hrs)

                         │
                         ▼

 ┌─────────────┬─────────────┬─────────────┬─────────────┐
 │ Account MS  │ Payment MS  │ Loan MS     │ Customer MS │
 └─────────────┴─────────────┴─────────────┴─────────────┘

                         │
                         ▼
                     Redis
               Token Blacklist
        

Maven Dependencies

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
        

Banking JWT Claims Example

{
  "sub":"CUST10001",
  "jti":"8f1e9f71",
  "role":"CUSTOMER",
  "scope":"PAYMENT",
  "channel":"MOBILE",
  "iss":"BANK_AUTH_SERVER",
  "aud":"PAYMENT_SERVICE",
  "iat":1710000000,
  "exp":1710000900
}
        

Common Banking Interview Questions

Why Use Refresh Tokens?

• Access Token: 15 Minutes
• Refresh Token: 24 Hours
• Reduces risk if access token is stolen.

Why Redis Blacklist?

Without Redis

Logout
  ↓
Token Still Valid

With Redis

Logout
  ↓
Blacklist JTI
  ↓
Reject Future Requests
        

Why Validate JWT at API Gateway?

• Single validation point.
• Reduced duplication.
• Lower microservice latency.
• Centralized security policy.
• Better audit logging.

Why OAuth2 + OpenID Connect?

OAuth2: Authorization

OpenID Connect: Authentication + Identity

Modern banking systems typically use Keycloak, ForgeRock, or Okta as Identity Providers.

Architect-Level Summary

• OAuth2 Authorization Server
• RS256 JWT Access Tokens
• Refresh Tokens stored in DB/Redis
• API Gateway Validation
• Redis Token Blacklist
• Role-Based Authorization
• JWKS Key Rotation
• Audit Logging and Traceability
• MFA Integration
• Zero-Trust Service-to-Service Security

This is the level of discussion expected for Lead Java Engineers, Solution Architects, and Principal Engineers in large banking organizations.