[Spring Security] JWT 기반 서버 인가 객체 전달 방법

Spring Security 6 버전 기준

 

최근 Spring Security 를 이용한 JWT기반 인증 서버를 리팩토링 하면서 인증/인가에 대한 부분을 다뤄보았다.

 

여러 레포와 블로그 글을 많이 보았지만 구현 방법은 모두 달랐다.

 

그래서 Spring Security 공식 문서를 참고하여 구현해 보았다.

 

그 중 인가(Authorization) 방법을 중점적으로 다뤄볼 것이다.

 

1. AuthUser

이 클래스는 서비스단에서 사용할 사용자의 unique한 식별자들을 정보를 넣어 전달되는 임시 객체로,

현재 인가된 사용자 정보를 담아 사용될 것이다.

 

@Getter
@AllArgsConstructor
public class AuthUser {

        private final Long id;
        
        private final String email;
        
        @JsonIgnore
        private final String password;
        
        private final List<Role> roles;
}

 

 

클래스 이름은 LoginUser, CurrentUser, CurrentAuthUser 등등.. 사용해도 되겠다.

 

필드 구성 또한 서비스 로직에서 사용할 정보들을 원하는대로 담으면 되겠다.

 

단, 서비스 내에서 사용할 사용자를 식별할 값(id, email 등) 을 필수로 포함해야 한다.

 

 

여기서 Role는 서버에서 사용하는 enum타입이다. 

public enum Role {
    ROLE_USER, ROLE_ADMIN
}

 

인증 객체를 사용할 땐 Authority로 변환하여 전달하고, JWT에도 넣을 예정이다.

 

 

 

토큰을 이용한 인증/인가의 특징은 무상태성(STATELESS)이다.

 

토큰 기반 인증/인가 서버는 DB 조회를 거치지 않고 사용자를 인증하기 때문에,

 

인가 과정에서 DB에서 가져온 User를 직접 사용할 수 없다.

 

따라서 인가용 임시 객체를 만들어 사용한 것이다.

 

인가 과정마다 DB를 거쳐 사용자 객체를 직접 가져올 순 있겠지만, 그렇게 되면 토큰을 사용하는 의미가 없다.
또한, 특정 서비스 로직을 제외하고 User의 모든 정보를 사용할 필요가 없기 때문에 매번 사용자를 가져오는 것은 비 효율적이다.

 

 

2. CustomUserDetails

public class CustomUserDetails extends AuthUser implements UserDetails {

    //인가용 객체 생성자
    public CustomUserDetails(Long id, String email, String password, List<Role> roles) {
        super(id, email, password, roles);
    }

    //인증용 객체 생성자
    public CustomUserDetails(User user) {
        super(user.getId(), user.getEmail(), user.getPassword(), user.getRoles());
    }

    //AuthUser에서 List<Role>을 가져와서 추가
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return new ArrayList<GrantedAuthority>(getRoles().stream().map(Role::toString).map(SimpleGrantedAuthority::new).toList());
    }


    @Override
    public String getUsername() {
        return getEmail();
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

 

Spring Security에서 사용할 인증용 객체를 만들어야 한다.

 

해당 클래스는 AuthUser를 상속하고 Spring Security의 UserDetiails의 인터페이스를 구현한다.

 

사용자의 권한들을 가져오는 getAuthorities()에서는 enum을 담은 List를 사용했기 때문에 String으로 변환 후 SimplGrantedAuthority 객체로 만들어서 List로 반환했다.

 

3. UserRepositoryUserDetailsService (CustomUserDetailsService)

@Service
@RequiredArgsConstructor
public class UserRepositoryUserDetailsService implements UserDetailsService {

    private final UserRepository userRepository;

    //Username은 email로 사용함
    @Override
    public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {

        Optional<User> optionalUser = userRepository.findByEmail(email);
        if (optionalUser.isPresent()) {
            User user = optionalUser.get();
            return new CustomUserDetails(user);
        }
        throw new UsernameNotFoundException("사용자가 존재하지 않습니다.");
    }

}

 

해당 클래스에서는 인증(Authentication) 과정 중에 사용될 loadUserByUsername 메소드를 정의한다.

 

서비스에서 사용하는 UserRepo를 사용하여 실제 User 객체를 가져오고, CustomDetails 인증용 객체를 만들어서 인증을 진행하게 된다.

 

이제 인증/인가용 객체 정의와 메소드 구현을 완료했고, 인증/인가 과정을 살펴보겠다.

 

3. 토큰 발급

토큰은 io.jsonwebtoken 라이브러리를 사용했다.

public String createToken(CustomUserDetails customUserDetails, Instant expiration) {

    Instant issuedAt = Instant.now();

    List<String> roles = customUserDetails.getAuthorities().stream()
            .map(GrantedAuthority::getAuthority)
            .toList();

    return Jwts.builder()
            .header()
            .add("typ", "JWT") // JWT 타입
            .and()
            .subject(customUserDetails.getUsername()) //email
            .claim("id", customUserDetails.getId()) //id
            .claim("roles", roles) //권한
            .issuedAt(Date.from(issuedAt)) // 현재 시간
            .expiration(Date.from(expiration)) //만료 시간
            .signWith(secretKey)
            .compact();
}

 

사용자가 로그인을 성공했을 때 발급해줄 토큰을 생성한다.

 

subject에는 email을, claim에는 id와 roles 을 넣어주었다.

 

최종적으로 토큰을 생성하면 payload는 아래처럼 된다.

 

추후에 인가 과정에서 id, email, role을 가져오는 함수는 다음과 같다.

//ID 추출
public Long getIdFromToken(String token) throws SignatureException {
    return Jwts.parser()
            .verifyWith(secretKey)
            .build()
            .parseSignedClaims(token)
            .getPayload()
            .get("id", Long.class);
}

//email 추출
public String getEmailFromToken(String token) throws SignatureException {
    return Jwts.parser()
            .verifyWith(secretKey)
            .build()
            .parseSignedClaims(token)
            .getPayload()
            .getSubject();
}

//Role 추출
public List<Role> getRolesFromToken(String token) throws SignatureException{
    List<String> roles = Jwts.parser()
            .verifyWith(secretKey)
            .build()
            .parseSignedClaims(token)
            .getPayload()
            .get("roles", List.class);
    return roles.stream().map(Role::valueOf).toList();
}

 

 

 

4. 인가

이제 인가 과정을 살펴보겠다.

 

아래는 인가용 필터 JwtAuthorizationFilter의 일부이다.

private void authenticateAccessToken(String accessToken) {

    //AccessToken 유효성 검증
    jwtUtil.validateToken(accessToken);

    //CustomUserDetail 객체 생성
    CustomUserDetails userDetails = new CustomUserDetails(
            jwtUtil.getId(accessToken),
            jwtUtil.getEmail(accessToken),
            null,
            jwtUtil.getRoles(accessToken)
    );

    //Spring Security 인증 토큰 생성
    Authentication authToken = new UsernamePasswordAuthenticationToken(
            userDetails,
            null,
            userDetails.getAuthorities());

    //인증 객체 저장
    SecurityContextHolder.getContext().setAuthentication(authToken);
}

 

위는 요청으로부터 access token을 추출하여 검증하는 메소드이다.

 

토큰의 유효성을 검사한 뒤, CustomUserDetails를 생성자를 통해 생성한 후 인증 객체를 저장한다.

 

마지막에 SecurityContextHolder에 인증 객체를 저장해두면 인가 과정이 완료된다.

 

 

5. 인가된 객체 전달받기

인가된 객체는 어노테이션을 통해 받을 것이다.

@AuthenticationPrincipal
@Retention(RetentionPolicy.RUNTIME)
public @interface CurrentUser {
}

 

어노테이션을 정의하고, @AuthenticationPrincipal을 붙이면 SecurityContextHolder에 담긴 인증 객체가 전달되게 된다.

 

@PutMapping("/name")
public ResponseEntity<?> updateName(@CurrentUser AuthUser authUser, @RequestParam String name) {
    userService.updateName(authUser, name);
    return new ResponseEntity<>(HttpStatus.OK);
}

 

이제 인가가 필요한 Controller에서 미리 정의해둔 어노테이션을 통해 AuthUser를 전달받으면 된다.

 

여기서 눈여겨 볼 것이 있는데,

인가 과정에서는 SecurityContextHolder에 CustomUserDetails를 넣었지만 @CurrentUser는 AuthUser를 받는다.

 

public class CustomUserDetails extends AuthUser implements UserDetails {

 

CustomUserDetails는 AuthUser를 상속받고 있기 때문에 AuthUser로 치환이 가능하다. (리스코프 치환 원칙)

 

 

6. 주의할 점

여기서 주의할 점은 AuthUser는 인가된 사용자의 정보를 담고 있는 임시 객체일 뿐, 실제 사용자가 아니다.

 

아래 예시처럼 AuthUser의 필드값만 사용하고, 실제 사용자는 DB조회를 거쳐야한다.

@Transactional
public void updateName(AuthUser authUser, String name) {
    User userByEmail = userRepository.findByEmail(authUser.getEmail()).orElseThrow(
            () -> new CustomException(ErrorCode.USER_NOT_FOUND)
    );
    userByEmail.setName(name);
}

 

@Transactional
public void updateName(AuthUser authUser, String name) {
    User userById = userRepository.findById(authUser.getId()).orElseThrow(
            () -> new CustomException(ErrorCode.USER_NOT_FOUND)
    );
    userById.setName(name);
}

 

@Transactional
public void updateName(AuthUser authUser, String name) {
    List<Role> roles = authUser.getRoles();
    if (roles.contains(Role.ROLE_USER)) {
        log.info("일반 사용자 감지");
    }
    //...
}