Why Two Methods for JWT Token Generation? Understanding Single Responsibility Principle

"Why do we need both generateToken() (public) and createToken() (private) instead of just one method?" Because separation of concerns makes your code extensible. The public method handles what claims to add (business logic), while the private method handles how to build the JWT (technical details). This lets you add new token types without repeating code. Let's understand why this design pattern is essential.

The Code in Question

@Component
public class JwtUtil {

    @Value("${jwt.secret}")
    private String secretKey;

    @Value("${jwt.expiration:86400000}")
    private long expirationTime;

    private Key getSigningKey() {
        return Keys.hmacShaKeyFor(secretKey.getBytes());
    }

    // Public method: Generate JWT token for a user
    public String generateToken(String email) {
        Map<String, Object> claims = new HashMap<>();
        return createToken(claims, email);
    }

    // Private method: Create the actual JWT token
    private String createToken(Map<String, Object> claims, String subject) {
        return Jwts.builder()
            .setClaims(claims)
            .setSubject(subject)
            .setIssuedAt(new Date(System.currentTimeMillis()))
            .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
            .signWith(getSigningKey(), SignatureAlgorithm.HS256)
            .compact();
    }
}

Your question:

"Why do you think we need both generateToken() (public) and createToken() (private) as separate methods instead of just one?"

Hint: Think about future features... what if you wanted to add custom data to certain tokens? 🤔

---

The Problem: One Method Design

What It Would Look Like

// ❌ Bad Design: Everything in one method
public String generateToken(String email) {
    return Jwts.builder()
        .setSubject(email)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)
        .compact();
}

Looks simple, right? But wait...

The Real-World Requirement

What if you need tokens for different purposes?

1. Standard login token - Just email
2. Admin token - Email + role
3. Password reset token - Email + expiration (1 hour instead of 24)
4. API token - Email + permissions

With One Method: Code Duplication

// Login token
public String generateLoginToken(String email) {
    return Jwts.builder()
        .setSubject(email)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)
        .compact();
}

// Admin token (needs role)
public String generateAdminToken(String email, String role) {
    return Jwts.builder()
        .claim("role", role)  // ← Only difference!
        .setSubject(email)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)
        .compact();
}

// Password reset token (1 hour expiration)
public String generatePasswordResetToken(String email) {
    return Jwts.builder()
        .claim("type", "password_reset")
        .setSubject(email)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + 3600000))  // ← Only difference!
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)
        .compact();
}

// API token (needs permissions)
public String generateApiToken(String email, List<String> permissions) {
    return Jwts.builder()
        .claim("permissions", permissions)  // ← Only difference!
        .setSubject(email)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)
        .compact();
}

Problems:

• ❌ Code duplication - Same 6 lines repeated 4 times
• ❌ DRY violation - Don't Repeat Yourself principle broken
• ❌ Hard to maintain - Change algorithm? Update 4 places!
• ❌ Error-prone - Easy to forget to update one method
• ❌ Harder to test - Must test same logic 4 times

---

The Solution: Separation of Concerns

Good Design: Two Methods

// Public method 1: Regular login
public String generateToken(String email) {
    Map<String, Object> claims = new HashMap<>();
    return createToken(claims, email);
}

// Public method 2: Admin token
public String generateAdminToken(String email, String role) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("role", role);  // ← Business logic: What to add
    return createToken(claims, email);  // ← Reuse technical details
}

// Public method 3: Password reset
public String generatePasswordResetToken(String email) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("type", "password_reset");
    return createTokenWithShortExpiration(claims, email, 3600000); // 1 hour
}

// Public method 4: API token
public String generateApiToken(String email, List<String> permissions) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("permissions", permissions);
    return createToken(claims, email);
}

// Private method: Reusable token builder (technical details)
private String createToken(Map<String, Object> claims, String subject) {
    return Jwts.builder()
        .setClaims(claims)
        .setSubject(subject)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)
        .compact();
}

Benefits:

• ✅ DRY - Token-building logic written once
• ✅ Easy to extend - Add new token types without duplicating code
• ✅ Easy to maintain - Change algorithm in ONE place
• ✅ Clear separation - Business logic vs technical details
• ✅ Easy to test - Test token building once, test claim variations separately

---

The Restaurant Kitchen Analogy

Think of JWT token generation like a restaurant kitchen:

❌ Bad Way: No Separation

Chef makes Burger:
    1. Cut bread
    2. Cook meat
    3. Add lettuce
    4. Add tomato
    5. Add sauce
    6. Wrap it up

Chef makes Sandwich:
    1. Cut bread
    2. Cook chicken
    3. Add lettuce
    4. Add tomato
    5. Add mayo
    6. Wrap it up

Chef makes Wrap:
    1. Cut tortilla
    2. Cook meat
    3. Add lettuce
    4. Add tomato
    5. Add sauce
    6. Wrap it up

Problem: Repeating "Cut, Cook, Add, Wrap" for each dish!

What if the restaurant changes wrapping paper?

• Update burger recipe ❌
• Update sandwich recipe ❌
• Update wrap recipe ❌
• 3 places to change!

✅ Good Way: Reusable Assembly Line

General Assembly Line (private method):
    1. Get base (bread/wrap/tortilla)
    2. Cook protein (meat/chicken)
    3. Add lettuce
    4. Add tomato
    5. Add toppings (custom)
    6. Wrap it up

Public methods (what customers order):
    - makeBurger() → calls assembly line with (bread, meat, sauce)
    - makeSandwich() → calls assembly line with (bread, chicken, mayo)
    - makeWrap() → calls assembly line with (tortilla, meat, sauce)
    - makeTaco() → calls assembly line with (tortilla, beef, salsa)

Benefits:

• ✅ One reusable process
• ✅ Change wrapping paper? Update assembly line ONCE
• ✅ Add new menu item? Just call assembly line with different ingredients

Same concept with JWT:

createToken() = Assembly line (private, reusable)
generateToken() = Customer order 1 (public, calls assembly)
generateAdminToken() = Customer order 2 (public, calls assembly)
generateApiToken() = Customer order 3 (public, calls assembly)

---

How It Works: The Current Code

Step-by-Step Breakdown

// What you (the caller) provide
public String generateToken(String email) {
    Map<String, Object> claims = new HashMap<>();  // ← Empty claims (basic token)
    return createToken(claims, email);              // ← Call reusable builder
}

Visual flow:

generateToken("test@example.com")
    ↓
Create empty claims map: {}
    ↓
Pass to createToken({}, "test@example.com")
    ↓
createToken() builds JWT:
    - Claims: {}
    - Subject: "test@example.com"
    - IssuedAt: 2025-10-19T10:00:00
    - Expiration: 2025-10-20T10:00:00 (24 hours)
    - Sign with HS256
    ↓
Return: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

What createToken() Does (Reusable)

private String createToken(Map<String, Object> claims, String subject) {
    return Jwts.builder()
        .setClaims(claims)                // Custom data (roles, permissions, etc.)
        .setSubject(subject)              // User identifier (email)
        .setIssuedAt(new Date(System.currentTimeMillis()))  // When token created
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))  // When expires
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)  // Cryptographic signature
        .compact();                       // Convert to JWT string
}

This method doesn't care WHAT claims you add - it just builds the token!

---

Future: Easy Extension

Scenario: Add Admin Token with Role

Old way (no separation):

// ❌ Have to write entire method again
public String generateAdminToken(String email, String role) {
    return Jwts.builder()
        .claim("role", role)
        .setSubject(email)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)
        .compact();
}

New way (with separation):

// ✅ Just add what's different, reuse everything else
public String generateAdminToken(String email, String role) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("role", role);  // ← Only new part!
    return createToken(claims, email);  // ← Reuse existing builder
}

4 lines instead of 8! And no duplication.

Scenario: Add API Token with Permissions

// ✅ Easy to add
public String generateApiToken(String email, List<String> permissions) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("permissions", permissions);
    return createToken(claims, email);  // ← Same reusable builder
}

Scenario: Add Password Reset Token (Short Expiration)

// ✅ Create variant with custom expiration
private String createTokenWithCustomExpiration(
    Map<String, Object> claims,
    String subject,
    long customExpiration
) {
    return Jwts.builder()
        .setClaims(claims)
        .setSubject(subject)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + customExpiration))  // ← Custom
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)
        .compact();
}

public String generatePasswordResetToken(String email) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("type", "password_reset");
    return createTokenWithCustomExpiration(claims, email, 3600000);  // 1 hour
}

All these use the same pattern! ✅

---

The Two Responsibilities

Public Method: Business Logic (What)

public String generateAdminToken(String email, String role) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("role", role);  // ← Decision: "Admins need role in token"
    return createToken(claims, email);
}

Responsibility: Decide what claims to add based on business requirements.

Questions it answers:

• What custom data should this token contain?
• Who is this token for?
• What permissions should it grant?

Private Method: Technical Details (How)

private String createToken(Map<String, Object> claims, String subject) {
    return Jwts.builder()
        .setClaims(claims)
        .setSubject(subject)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)  // ← How to sign
        .compact();  // ← How to serialize
}

Responsibility: Handle how to build the JWT token technically.

Questions it answers:

• How to structure the JWT?
• What algorithm to use?
• How to set expiration?
• How to sign the token?

---

Single Responsibility Principle (SRP)

This is one of the SOLID principles:

A class should have only one reason to change.

Applied to Our Code

generateToken() changes when:

• Business requirements change (e.g., "Admins need roles in token")
• New token types needed (e.g., "Add API tokens")

createToken() changes when:

• Technical requirements change (e.g., "Switch from HS256 to RS256")
• JWT library updates (e.g., "Migrate from io.jsonwebtoken to another library")

Separation ensures:

• ✅ Business changes don't touch technical details
• ✅ Technical changes don't touch business logic
• ✅ Each method has ONE clear responsibility

---

Real-World Example: Complete Implementation

@Component
public class JwtUtil {

    @Value("${jwt.secret}")
    private String secretKey;

    @Value("${jwt.expiration:86400000}")  // 24 hours default
    private long expirationTime;

    private Key getSigningKey() {
        return Keys.hmacShaKeyFor(secretKey.getBytes());
    }

    // 1. Standard login token (email only)
    public String generateToken(String email) {
        Map<String, Object> claims = new HashMap<>();
        return createToken(claims, email);
    }

    // 2. Admin token (email + role)
    public String generateAdminToken(String email, String role) {
        Map<String, Object> claims = new HashMap<>();
        claims.put("role", role);
        claims.put("permissions", Arrays.asList("READ", "WRITE", "DELETE"));
        return createToken(claims, email);
    }

    // 3. Password reset token (email + type, short expiration)
    public String generatePasswordResetToken(String email) {
        Map<String, Object> claims = new HashMap<>();
        claims.put("type", "password_reset");
        return createTokenWithCustomExpiration(claims, email, 3600000); // 1 hour
    }

    // 4. API token (email + API key + permissions)
    public String generateApiToken(String email, String apiKey, List<String> permissions) {
        Map<String, Object> claims = new HashMap<>();
        claims.put("apiKey", apiKey);
        claims.put("permissions", permissions);
        return createToken(claims, email);
    }

    // 5. Refresh token (email only, long expiration)
    public String generateRefreshToken(String email) {
        Map<String, Object> claims = new HashMap<>();
        claims.put("type", "refresh");
        return createTokenWithCustomExpiration(claims, email, 604800000); // 7 days
    }

    // Private helper: Standard token builder
    private String createToken(Map<String, Object> claims, String subject) {
        return Jwts.builder()
            .setClaims(claims)
            .setSubject(subject)
            .setIssuedAt(new Date(System.currentTimeMillis()))
            .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
            .signWith(getSigningKey(), SignatureAlgorithm.HS256)
            .compact();
    }

    // Private helper: Token builder with custom expiration
    private String createTokenWithCustomExpiration(
        Map<String, Object> claims,
        String subject,
        long customExpiration
    ) {
        return Jwts.builder()
            .setClaims(claims)
            .setSubject(subject)
            .setIssuedAt(new Date(System.currentTimeMillis()))
            .setExpiration(new Date(System.currentTimeMillis() + customExpiration))
            .signWith(getSigningKey(), SignatureAlgorithm.HS256)
            .compact();
    }
}

Notice:

• 5 public methods for different token types
• 2 private methods for reusable token building
• Business logic (what claims) in public methods
• Technical details (how to build) in private methods

If you need to change from HS256 to RS256:

• ✅ Change 2 private methods (technical details)
• ❌ DON'T change 5 public methods (business logic)

---

Testing Benefits

With Separation: Easy to Test

@Test
public void testGenerateToken() {
    String token = jwtUtil.generateToken("test@example.com");
    Claims claims = jwtUtil.extractAllClaims(token);

    assertEquals("test@example.com", claims.getSubject());
    assertNotNull(claims.getIssuedAt());
    assertNotNull(claims.getExpiration());
}

@Test
public void testGenerateAdminToken() {
    String token = jwtUtil.generateAdminToken("admin@example.com", "ADMIN");
    Claims claims = jwtUtil.extractAllClaims(token);

    assertEquals("admin@example.com", claims.getSubject());
    assertEquals("ADMIN", claims.get("role"));  // ← Test custom claim
}

@Test
public void testGeneratePasswordResetToken() {
    String token = jwtUtil.generatePasswordResetToken("user@example.com");
    Claims claims = jwtUtil.extractAllClaims(token);

    assertEquals("password_reset", claims.get("type"));
    // Test expiration is 1 hour (not 24)
}

Each public method tests business logic. Private methods tested indirectly through public methods.

Without Separation: Harder to Test

@Test
public void testGenerateLoginToken() {
    // Test entire token building + claim logic
}

@Test
public void testGenerateAdminToken() {
    // Test entire token building + claim logic (duplicated test logic!)
}

@Test
public void testGeneratePasswordResetToken() {
    // Test entire token building + claim logic (duplicated test logic!)
}

More duplication, harder to maintain.

---

Maintenance Example: Algorithm Change

Scenario: Switch from HS256 to RS256

With separation:

// Before: HS256
private String createToken(Map<String, Object> claims, String subject) {
    return Jwts.builder()
        .setClaims(claims)
        .setSubject(subject)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getSigningKey(), SignatureAlgorithm.HS256)  // ← Change here
        .compact();
}

// After: RS256
private String createToken(Map<String, Object> claims, String subject) {
    return Jwts.builder()
        .setClaims(claims)
        .setSubject(subject)
        .setIssuedAt(new Date(System.currentTimeMillis()))
        .setExpiration(new Date(System.currentTimeMillis() + expirationTime))
        .signWith(getRsaPrivateKey(), SignatureAlgorithm.RS256)  // ← Only change
        .compact();
}

Changed 1 line in 1 method! ✅

All 5 token types automatically updated! ✅

Without separation:

// Have to update HS256 → RS256 in:
generateToken() ❌
generateAdminToken() ❌
generatePasswordResetToken() ❌
generateApiToken() ❌
generateRefreshToken() ❌

5 methods to update, 5 places to make mistakes!

---

Summary

The Question

"Why do you think we need both generateToken() (public) and createToken() (private) as separate methods instead of just one?"

The Answer

Because separation of concerns provides:

Benefit	With Separation	Without Separation
Code reuse	✅ Token building logic once	❌ Repeated 5+ times
Extensibility	✅ Add new token types easily	❌ Duplicate entire logic
Maintainability	✅ Change algorithm in 1 place	❌ Update 5+ methods
Testing	✅ Test business logic separately	❌ Test everything together
Clarity	✅ Clear responsibilities	❌ Mixed concerns
Follows SOLID	✅ Single Responsibility	❌ Violates SRP
Follows DRY	✅ Don't Repeat Yourself	❌ Lots of duplication

The Two Responsibilities

// Public method: WHAT (Business Logic)
public String generateAdminToken(String email, String role) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("role", role);  // ← Decision: What to include
    return createToken(claims, email);
}

// Private method: HOW (Technical Details)
private String createToken(Map<String, Object> claims, String subject) {
    return Jwts.builder()  // ← Implementation: How to build
        .setClaims(claims)
        .setSubject(subject)
        // ... technical JWT building details
        .compact();
}

Key Takeaways

1. generateToken() handles business logic - What claims to add
2. createToken() handles technical details - How to build JWT
3. Separation enables extensibility - Add new token types without duplication
4. Follows Single Responsibility Principle - Each method has one reason to change
5. Follows DRY principle - Don't Repeat Yourself
6. Restaurant analogy - Assembly line (reusable) vs menu items (custom orders)

The Bottom Line

One method = Simple now, painful later

Two methods = Slightly more complex now, easy to extend forever

This is good software design - thinking ahead about future requirements! 🎯

Now you understand that separating generateToken() and createToken() isn't just "fancy coding" - it's essential for maintainability and extensibility as your application grows! 💡