如何将一些附加字段添加到此 Spring 引导服务生成的 JWT 令牌中？

Question

I am working on a Spring Boot microservice that generate a JWT token and I have the following doubt about the possibility to add additional information into the generated token.

Basically in my code I have done something like this (it works fine):

@Override
public UserDetails loadUserByUsername(String UserId) throws UsernameNotFoundException {
    
    String ErrMsg = "";
    
    if (UserId == null || UserId.length() < 2) {
        ErrMsg = "Nome utente assente o non valido";
        
        logger.warn(ErrMsg);
        
        throw new UsernameNotFoundException(ErrMsg); 
    } 
    
    User user = this.GetHttpValue(UserId);
    
    if (user == null) {
        ErrMsg = String.format("User %s not found!!", UserId);
        
        logger.warn(ErrMsg);
        
        throw new UsernameNotFoundException(ErrMsg);
    }
    
    UserBuilder builder = null;
    
    builder = org.springframework.security.core.userdetails.User.withUsername(user.getEMail());
    builder.password(user.getPswd());
    
    String[] operations = user.getUserTypes().stream()
            .map(UserType::getOperations)
            .flatMap(Set::stream)
            .map(Operation::getName)
            .distinct()
            .toArray(String[]::new);
    
    builder.authorities(operations);
    
    return builder.build();
        
}

As you can see in the previous code I have this method returning a UserDetails object (belonging to Spring Security, it is this class: org.springframework.security.core.userdetails.UserDetails ). This UserDetails instance was created starting from this retrieved model object (it was retrieved performing a call to a REST endpoint):

User user = this.GetHttpValue(UserId);

Basically this UserDetails object is used to generate the JWT token by this second method that uses the previous UserDetails object:

private String doGenerateToken(Map<String, Object> claims, UserDetails userDetails) 
{
    final Date createdDate = clock.now();
    final Date expirationDate = calculateExpirationDate(createdDate);

    return Jwts.builder()
            .setClaims(claims)
            .setSubject(userDetails.getUsername())
            .claim("authorities", userDetails.getAuthorities().stream().map(GrantedAuthority::getAuthority).collect(Collectors.toList()))
            .setIssuedAt(createdDate)
            .setExpiration(expirationDate)
            .signWith(SignatureAlgorithm.HS512, jwtConfig.getSecret().getBytes())
            .compact();
}

NOTE: the Jwts is io.jsonwebtoken.Jwts .

This generate a token containing the following payload information:

{
  "sub": "xxx@gmail.com",
  "exp": 1637412048,
  "iat": 1637325648,
  "authorities": [
    "ADMIN"
  ]
}

It is correct but...is it possible to add some further information to this payload? In particular I need to add some information that are into my User DTO object but not into the previous Spring Security UserDetails instance.

I implemented this behavior following an Udemy tutorial and now I have the following doubt.

Why the previous doGenerateToken() method generate the token starting from the Spring Security UserDetails instance and not directly from the User DTO object (it contains more usefull information).

If there are some specific reason to use this UserDetails instance instead my simple User DTO object, exist a way to add these information to the UserDetails instance and then put these additional fields into my JWT token?

Answer 1

You are passing a map of claims to the doGenerateToken method. These are then added to the token payload as claims. You can add whatever you like to this map to create the token.

As for the question why the doGenerateToken method doesn't use the User DTO? Well, if that method is not part of an interface, then you can have it accept any class, right? If you prefer to work with the User object, then I think you can. If it's an implementation of an interface, then you should ask the authors what was the reason for that, but people rather have thought through those interfaces in Spring and there are good reasons why they are built this way or another. Even if at first they look weird.