GoodBye, Spring Boot...👋

_(사실 GoodBye까지도 아닌 것 같다. 지금처럼 인생은 모르는거니까🤣~!)_ 2024년이 되자마자 팀 내에서의 역할이 바뀌어, 모바일 담당자로 전환되면서 백엔드 개발자에서 iOS 개발자로의 새로운 도전을 맞게 되었다. 처음 직무 전환에 대한 제안을 주셨을 때에는 고민이 많았다. 현재 진행 중인 백엔드 개발이 정말로 즐거웠기 때문이다. 데이터를 다루고 다양한 기술 스택을 학습하며 비즈니스 로직을 개발하는 것이 내겐 정말 매력적인 작업이었다. 그럼에도 불구하고, 아이폰 사용자로서 직접 사용할 수 있는 앱 서비스를 개발하는 꿈이 항상 내 마음 한 켠에 남아 있었다. 하지만, 현재 하는 일과는 다른 완전히 새로운 분야에 많은 시간을 투자해야 했기 때문에 도전이 쉽지 않았다. 때문에 더욱 좋은 기회를 잡았다는 생각이 들어 iOS 개발자로의 전환을 결심하게 되었다. 프로덕트를 만들어가는 과정에서 전문성을 쌓는 즐거움을 느끼고, 팀과 함께 사용자들의 편의성을 높일 수 있는 서비스를 만드는 것을 iOS에서도 경험할 수 있다는 설렘이 크다. 하여튼 이렇게, 사용자들에게 가치 있는 경험을 제공할 수 있는 iOS 개발자로 성장하고자 하는 다짐과 함께 2024년을 시작하게 되었다!!

첫 강의 선택!!🐣

심도 깊은 강의를 듣기 전에.. Swift 문법을 먼저 익힐 필요가 있었다! 새로운 언어를 익힐 때마다 매번 드는 생각이지만, 다른 문법에 익숙한 채로 새로운 문법을 익히는 것은 좀 많이 햇갈리고.. 어렵다..🤤

나의 강의 결정 조건

1. Swift의 완전 기초 문법부터 알려주는 강의일 것
2. Windows에서 학습 가능한 강의(온라인 Swift 컴파일러에서도 진행하기 위함)
3. 무료 강의
4. 교육 플랫폼이면 좋겠다. 진행도와 다음 강의를 보기 원활하기 때문.

강의 선택

야곰의 스위프트 기본 문법 강좌

시중에 나와 있는 모든 강의들이 유익하지만, 나는 위의 조건들을 바탕으로 위의 강의를 선택했다. 나에게 이 강의가 맞는지 몇 개 들어보며 핵심적이고 간결한 강의였기 때문에 집중하기 쉽다고 느껴졌기 때문이다.

_새로운 언어와 기술 스택 익힐 생각에 설렘만 가득한 것🥰.._

Spring Boot 2.7.3 Gradle

Swagger란?

Open Api Specification(OAS), 이는 RESTful API spec을 정의된 규칙에 맞게 json이나 yaml로 표현하는 방식을 의미한다. Swagger는 OAS를 위한 프레임워크이며, API들이 갖고 있는 specification을 정의할 수 있는 툴들 중 하나이다. API의 문서를 자동화뿐만 아니라, 파라미터를 넣어보고 테스트를 진행할 수 있다. API 문서를 작성하는 시간을 절약할 수 있고, API 정보를 실시간으로 유지할 수 있다는 장점이 있다.

Springfox와 Springdoc

Spring에서 Swagger를 쉽게 사용할 수 있도록 도와주는 라이브러리로 Springdoc과 Springfox가 존재한다. 현재 2022년을 기준으로 사람들은 Springfox를 더 많이 사용하고 있기 때문에 Springfox를 적용해보겠다.

적용

build.gradle에 의존성 추가

    implementation 'io.springfox:springfox-boot-starter:3.0.0'

SwaggerConfig

@Configuration
public class SwaggerConfig {

    private Docket testDocket(String groupName, Predicate<String> selector) {
        return new Docket(DocumentationType.OAS_30)
                .apiInfo(this.apiInfo(groupName)) // ApiInfo 설정
                .useDefaultResponseMessages(false)
                .groupName("testApi")
                .select()
                .apis(RequestHandlerSelectors.
                        basePackage("패키지명"))
                .paths(PathSelectors.ant("/api/**")).build();
    }

    private ApiInfo apiInfo() {
          return new ApiInfoBuilder()
                .title("제목")
                .description("설명")
                .version(version)
                .contact(new Contact("이름", "홈페이지 URL", "e-mail"))
                .build();
    }
}

• 3.0으로 넘어오면서 @EnableSwagger2 는 사용하지 않아도 된다.
• Docket: Swagger 설정의 핵심이 되는 Bean이다.
• groupName(): 만약 Docket이 하나라면 생략이 가능하지만, 여러 개라면 groupName이 충돌해 오류가 발생하기 때문에 groupName을 명시해주어야 한다.
• select(): ApiSelectorBuild 클래스의 인스턴스를 반환한다.
• useDefaultResponseMessages(): true로 설정하면 Swagger에서 제공해주는 기본 응답 코드를 보여준다.
• apis(): API가 작성되어 있는 Controller 패키지를 지정한다.(예: com.example.demo.XXXApiController) 만약, RequestHandlerSelectors.any()로 설정한다면 전체 API에 대한 문서를 Swagger를 통해 나타낼 수 있다.
• paths(): 나타내고자 하는 API path를 작성한다. PathSelectors.any()로 설정한다면 패키지 안의 모든 API에 대한 문서를 나타낼 수 있다.

Controller 작성

이제 Swagger에 나타낼 Controller를 작성해보겠다.

import io.swagger.annotations.Api;
import io.swagger.annotations.ApiModelProperty;
import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.responses.ApiResponse;
import io.swagger.v3.oas.annotations.responses.ApiResponses;
import lombok.Data;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;

import javax.validation.Valid;
import javax.validation.constraints.NotNull;

//Controller
@Api(tags = "Controller 이름")
@RestController
public class TestApiController {

    @Operation(summary = "요약", description = "설명")
    @ApiResponses({
            @ApiResponse(responseCode = "200", description = "OK"),
            @ApiResponse(responseCode = "500", description = "Server Error")
    })
    @PostMapping("/api/test")
    public ResponseDto exampleMethod(
            @Parameter(description = "파라미터 설명", example = "1") @Valid RequestDto requestDto
    ) {
        return new ResponseDto();
    }
}

// RequestDto
@Data
class RequestDto {
    @ApiModelProperty(value="값1 설명", example="0")
    @NotNull
    private Long reqVar1;

    @ApiModelProperty(value="값2 설명", example="example string")
    private String reqVar2;
}

// ResponseDto
@Data
class ResponseDto {
    @ApiModelProperty(value="값1 설명", example="0")
    private Long resVar1;

    @ApiModelProperty(value="값2 설명", example="example string", hidden = true)
    private String resVar2;
}

각각의 어노테이션에 다양한 값이 있어 자세히 나타낼 수 있다. 일부만 간단하게 작성해보았다.

• @Api: tags 값으로 Swagger에 나타낼 Controller의 이름을 지정했다.
• @Operation: API에 대한 요약 정보(summary)와 설명(decription)을 작성했다.
• @ApiResponse: API의 HTTP Status Code 반환 값에 대한 설명을 작성했다.
  • @ApiResponses 어노테이션을 이용해 여러 개의 반환 값을 작성할 수 있다.
• @Parameter: 파라미터에 대한 설명(decription)와 예시(example)을 작성했다.
• @ApiModelProperty: DTO 필드에 대한 설명(decription)와 예시(example)을 작성했다.

애플리케이션을 실행시키고 http://localhost:8080/swagger-ui/index.html로 접속해 Swagger를 실행시키면 작성한 API에 대한 문서가 생성된 것을 볼 수 있다. Controller 부분과 Schemas 부분을 간단히 들여다보겠다. 직관적이라 쉽게 이해할 수 있다.

Controller

@Valid 어노테이션에 의해 RequestDto의 @NotNull 어노테이션이 적용되어 resVar1 값 옆에 *required라고 명시된 것을 확인할 수 있다. @ApiResponse로 작성한 반환 값들에 대한 설명을 확인할 수 있다. Docket 객체의 useDefaultResponseMessages() 값을 true로 설정해두었다면 200, 401, 403, 404에 대한 기본 응답 메세지 또한 확인할 수 있다.

Schemas

응답 데이터에 대한 정보를 확인할 수 있다. reqVar2 값을 hidden=true로 설정해두었기 때문에 화면에 보이지 않는다. 요청DTO에도 설정해둘 수 있다.

실행

왼쪽 상단의 "Try it out"을 눌러 API를 실행해보겠다.

ApiInfo

ApiInfo 객체를 이용해 Swagger 위에 나타나는 부분을 커스터마이징 할 수 있다.

@Configuration
public class SwaggerConfig {

    private Docket testDocket(String groupName, Predicate<String> selector) {
        return new Docket(DocumentationType.OAS_30)
                .apiInfo(this.apiInfo(groupName)) // ApiInfo 설정
                .useDefaultResponseMessages(false)
                .groupName("testApi")
                .select()
                .apis(RequestHandlerSelectors.
                        basePackage("패키지명"))
                .paths(PathSelectors.ant("/api/**")).build();
    }

    private ApiInfo apiInfo() {
          return new ApiInfoBuilder()
                .title("제목")
                .description("설명")
                .version(version)
                .contact(new Contact("이름", "홈페이지 URL", "e-mail"))
                .build();
    }
}

생성자를 이용해 모든 정보를 넣거나, 혹은 build() 메소드를 통해 원하는 정보를 넣어 객체를 생성할 수 있다.

JWT를 사용하기 위한 설정

SwaggerConfig

@Configuration
public class SwaggerConfig {

    private Docket testDocket(String groupName, Predicate<String> selector) {
        return new Docket(DocumentationType.OAS_30)
                .useDefaultResponseMessages(false)
                .securityContexts(List.of(this.securityContext())) // SecurityContext 설정
                .securitySchemes(List.of(this.apiKey())) // ApiKey 설정
                .groupName("testApi")
                .select()
                .apis(RequestHandlerSelectors.
                        basePackage("패키지명"))
                .paths(PathSelectors.ant("/api/**")).build();
    }

    // JWT SecurityContext 구성
    private SecurityContext securityContext() {
        return SecurityContext.builder()
                .securityReferences(defaultAuth())
                .build();
    }

    private List<SecurityReference> defaultAuth() {
        AuthorizationScope authorizationScope = new AuthorizationScope("global", "accessEverything");
        AuthorizationScope[] authorizationScopes = new AuthorizationScope[1];
        authorizationScopes[0] = authorizationScope;
        return List.of(new SecurityReference("Authorization", authorizationScopes));
    }

    // ApiKey 정의
    private ApiKey apiKey() {
        return new ApiKey("Authorization", "Authorization", "header");
    }
}

저는 JWT 토큰 방식을 이용해 Authorization Header를 "Bearer {Access Token}" 형식으로 받아와 인증을 처리했기 때문에, 이 글을 보시는 분들과 ApiKey를 정의하는 방식이 다를 수 있습니다.

• SecurityContext: 인증하는 방식을 설정한다. 전역 AuthorizationScope를 사용해 SecurityContext를 구성했다.
• ApiKey: Swagger 내에서 인증하는 방식으로, ApiKey는 JWT, Bearer, Authorization이 있다. Authorization을 인증 헤더로 포함하도록 ApiKey를 정의했다.(2번째 인자의 Authorization이 중요함!)

실행

Swagger를 실행해보면 오른쪽에 자물쇠 모양의 버튼이 생성된 것을 확인할 수 있다. 토큰을 입력하고 Authorize 버튼을 누르면 API에 대한 모든 요청이 HTTP 헤더에 토큰이 자동으로 포함된다. 인증 후, 자물쇠가 잠겨있는 것을 확인할 수 있다.

환경별 Swagger 작동 처리

시행착오

운영 환경에서는 Swagger가 작동하지 않도록 처리하는 것이 필요하다. 이 문제 때문에 며칠동안 고민이 많았는데, SwaggerConfig 클래스에 @Profile 어노테이션을 달았는데도 우선 "작동"이 된다는 점이었다.

SwaggerConfig

@Profile({"!prod"})
@Configuration
public class SwaggerConfig {
    // ...
}

예상대로라면 prod 값일 때는 Swagger가 작동되지 않을 줄 알았다.

운영 환경

spring.profiles.active: prod

개발 환경

spring.profiles.active: dev

?????? .. 그리고 모든 Controller가 똑같이 보이고 똑같이 실행됐다. SecurityConfig에서 IP 등을 사용해 접근을 직접 제어하는 방법도 사용해보았지만, IP가 바뀔 때도 있을 것이고, 손이 많이 가는 방법이라 사용하고 싶지 않아서 더 고민을 하게 됐다.(API 문서 개발이 급해 그냥 커밋해버리고 싶다는 생각을 12129038109번정도 했다🤤...)

찾아낸 방법👍

사실 이거 기록해두려고 글을 작성한 것 같다.. 구글링을 열심히 하다가!! 이 글을 보고 방법을 참고해 해결했다!! Docket 객체의 enabled() 메소드를 활용하는 방법이었다.

@Configuration
public class SwaggerConfig {

    @Profile({"test || dev"})
    @Bean
    public Docket indexApi() {
        return docket("default", PathSelectors.ant("/api/**"));
    }

    @Bean
    @Profile({"!test && !dev"})
    public Docket disable() {
        return new Docket(DocumentationType.OAS_30).enable(false);
    }

운영 환경에서 아예 Swagger 페이지에 접근이 불가능해진다!!! 이상 Swagger 적용기였다.. 끝까지 글을 봐주신 분들 감사합니다!

QueryDSL이란?

정적 타입을 이용해 SQL과 같은 쿼리를 생성할 수 있도록 도와주는 프레임워크이다. 문자가 아닌 자바 코드로 쿼리를 작성함으로써, 컴파일 시점에 문법 오류를 쉽게 확인할수 있다. 또한, Query를 자동 완성해주며, 동적 쿼리 작성을 편리하게 할 수 있다. 쿼리 작성 시 제약 조건 등을 메서드 추출을 통해 재사용할 수 있다는 장점도 있다.

JPQL

JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공한다. JPQL은 엔티티 객체를 대상으로 쿼리하며, SQL은 데이터베이스 테이블을 대상으로 쿼리한다.

List<Member> result = em.createQuery(
        "select m From Member m where m.username like '%kim%'", // 테이블이 아닌 엔티티 Member
        Member.class
).getResultList();

QueryDSL

쿼리 작성이 단순하고 쉽다.

PAFactoryQuery query = new JPAQueryFactory(em);
QMember m = QMember.member; 
List<Member> list = query.selectFrom(m)
                        .where(m.name.like("kim"))
                        .orderBy(m.id.desc())
                        .fetch();

QueryDSL 설정

개발환경

Spring Boot 2.6.5 java 11.0.9 IDE Intellij Windows

Spring Boot 2.6 이상 버전에서는 Querydsl 5.0을 사용한다.

build.gradle

querydsl 플러그인 추가

// Querydsl 버전 plugins 위에 추가
buildscript {
    ext {
        queryDslVersion = "5.0.0"
    }
}

plugins {
    id 'org.springframework.boot' version '2.6.3'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
    id "com.ewerk.gradle.plugins.querydsl" version "1.0.10" // querydsl 플러그인 추가
}

querydsl dependency 추가

dependencies {
    // ...
    implementation "com.querydsl:querydsl-jpa:${queryDslVersion}"
    implementation "com.querydsl:querydsl-apt:${queryDslVersion}"
}

querydsl 추가 설정

// querydsl에서 사용할 경로 설정(현재 지정한 부분은 .gitignore에 포함됨)
def querydslDir = "$buildDir/generated/querydsl"

// JPA 사용 여부 및 사용할 경로 설정
querydsl {
    jpa = true
    querydslSourcesDir = querydslDir
}

// build 시 사용할 sourceSet 추가 설정
sourceSets {
    main.java.srcDir querydslDir
}

// querydsl 컴파일 시 사용할 옵션 설정
compileQuerydsl{
    options.annotationProcessorPath = configurations.querydsl
}

// querydsl이 compileClassPath를 상속하도록 설정
configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
    querydsl.extendsFrom compileClasspath
}

나같은 경우 sourceSet 설정에 React와 관련된 설정을 미리 해두어서 햇갈렸는데, 설정 아래에 그대로 붙여 넣어줘도 문제가 없었다.

Build

Intellij 우측 gradle 탭에서 other -> compilQuerydsl을 누르거나 애플리케이션을 실행시켜 Build를 해주면, 위에서 지정한 querydslDir에 Q타입이 생기는 것을 확인할 수 있다.

JPAQueryFactory 등록

구글링을 해보면, 'JpaRepository<XXX, Long>, XXXRepositoryCustom'을 extends하는 XXXRepository를 생성하고, XXXRepositoryCustom을 생성한 후에, XXXRepositoryImpl을 생성하는 복잡한 방법이 있다. 이러한 방법 대신, @Bean으로 등록하면 간단하게 QueryDSL을 사용할 수 있다.

QuerydslConfig

import com.querydsl.jpa.impl.JPAQueryFactory;
import lombok.RequiredArgsConstructor;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.persistence.EntityManager;


@Configuration
@RequiredArgsConstructor
public class QuerydslConfig {

    private final EntityManager em;

    @Bean
    public JPAQueryFactory jpaQueryFactory(EntityManager em){
        return new JPAQueryFactory(em);
    }
}

이후 JPAQueryFactory을 선언하고 사용하면 된다.

참고

https://tecoble.techcourse.co.kr/post/2021-08-08-basic-querydsl/ https://dingdingmin-back-end-developer.tistory.com/entry/Spring-Data-JPA-7-Querydsl-%EC%82%AC%EC%9A%A9-gradle-7x

• Spring Boot 2.7.3
• Java 11.0.9
• JUnit5
• Mockito

상황

• 우선, 작업이 촉박하게 이루어지는 상황이라 테스트 코드를 작성하지 못했다.. 이미 로직을 작성해둔 상태라서 로직에 맞춰서 테스트 코드를 작업하려고 했다. 일단, 좋은 테스트를 위한 FIRST 규칙의 Timely는 지키지 못했다.
• JWT 토큰을 발급해주는 메서드의 테스트 코드를 작성 중이었다.

AuthService

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class AuthService {

    private final JwtTokenProvider jwtTokenProvider;
    private final RedisService redisService;

    public TokenDto generateToken(String email, String authorities) {
        TokenDto tokenDto = jwtTokenProvider.createToken(email, authorities);
        saveRefreshToken(email, tokenDto.getRefreshToken()); // // line 78
        return tokenDto;
    }

    public void saveRefreshToken(String email, String refreshToken) {
        redisService.setValuesWithTimeout("RT(" + email + "):", // key
                refreshToken, // value
                jwtTokenProvider.getTokenExpirationTime(refreshToken)); // timeout(milliseconds)
    }
}

• generateToken: Access Token과 Refresh Token을 생성하고, Redis에 Refresh Token을 저장
• saveRefreshToken: Redis에 Refresh Token을 유효 기간과 함께 저장. 유효 기관을 초과하면 사라진다.

AuthServiceTest

@ExtendWith(MockitoExtension.class)
public class AuthServiceTest {

    @Mock
    JwtTokenProvider jwtTokenProvider;
    @Mock
    RedisService redisService;
    @Spy
    @InjectMocks
    AuthService authService;

    @Test
    public void generateToken() throws Exception {
        // given
        String email = "user@email.com";
        String authorities = "ROLE_USER";

        TokenDto returnTokenDto = new TokenDto("accessToken", "refreshToken");

        Mockito.when(authService.generateToken(email, authorities))
                .thenReturn(returnTokenDto);

        // when
        TokenDto generateToken = authService.generateToken(email, authorities); // line 72

        // then
        assertEquals(generateToken, returnTokenDto);
    }
}

• 같은 TokenDto를 가리키게 하기 위해 returnTokenDto 객체를 생성했다.

발생한 문제 & 해결 방법

1. NullPointerException

java.lang.NullPointerException at {프로젝트명}.Service.AuthService.generateToken(AuthService.java:78) at {프로젝트명}.Service.AuthService.generateToken(AuthServiceTest.java:72)

왜?

디버깅을 해보니 tokenDto가 비어있었는데, JwtTokenProvider가 Mock 객체임을 떠올렸다. AuthServiceTest에 아래의 코드를 추가했다.

Mockito.when(jwtTokenProvider.createToken(email, authorities))
       .thenReturn(returnTokenDto);

2. CannotStubVoidMethodWithReturnValue

org.mockito.exceptions.misusing.CannotStubVoidMethodWithReturnValue: 'setValuesWithTimeout' is a void method and it cannot be stubbed with a return value! Voids are usually stubbed with Throwables: doThrow(exception).when(mock).someVoidMethod(); If you need to set the void method to do nothing you can use: doNothing().when(mock).someVoidMethod(); For more information, check out the javadocs for Mockito.doNothing().

If you're unsure why you're getting above error read on. Due to the nature of the syntax above problem might occur because:

1. The method you are trying to stub is overloaded. Make sure you are calling the right overloaded version.
2. Somewhere in your test you are stubbing final methods. Sorry, Mockito does not verify/stub final methods.
3. A spy is stubbed using when(spy.foo()).then() syntax. It is safer to stub spies -
   • with doReturn|Throw() family of methods. More in javadocs for Mockito.spy() method.
4. Mocking methods declared on non-public parent classes is not supported.

왜?

saveRefreshToken 메소드의 redisService.setValuesWithTimeout 메소드가 void 값을 리턴하는 메소드이기 때문에, 반환 값을 가지는 stub 방식을 사용할 수 없다고 한다. 메소드를 선택적으로 stub할 수 있도록 하는 @Spy 어노테이션과 해결책으로 제시한 doNothing().when(mock).someVoidMethod();을 사용해 해결했다. AuthService를 Spy 객체로 만들고, 아래와 같이 saveRefreshToken에 대한 stub을 작성했다.

Mockito.doNothing()
        .when(authService)
        .saveRefreshToken(email, returnTokenDto.getRefreshToken());

위의 코드를 추가하고 디버깅해보았더니, 실제 코드를 실행해보았더니 generateToken을 실행시켰을 때 AuthService saveRefreshToken을 호출하지 않고, stub으로 작성한 Spy 객체의 saveRefreshToken 메소드가 실행되는 것을 확인할 수 있었다.

최종 코드

AuthServiceTest

@ExtendWith(MockitoExtension.class)
public class AuthServiceTest {

    @Mock JwtTokenProvider jwtTokenProvider;
    @Mock RedisService redisService;

    @Spy
    @InjectMocks
    AuthService authService;

    @Test
    public void generateToken() throws Exception {
        // given
        String provider = SERVER;
        String email = "user@email.com";
        String authorities = "ROLE_USER";

        TokenDto returnTokenDto = new TokenDto("at", "rt");

        Mockito.when(jwtTokenProvider.createToken(email, authorities))
                .thenReturn(returnTokenDto);
        Mockito.doNothing()
                .when(authService)
                .saveRefreshToken(email, returnTokenDto.getRefreshToken());
        Mockito.when(authService.generateToken(email, authorities))
                .thenReturn(returnTokenDto);

        // when
        TokenDto generateToken = authService.generateToken(email, authorities);

        // then
        assertEquals(generateToken, returnTokenDto);
    }
}

실행 결과

한 3일동안 해결하지 못했던 문제였어서 '시간도 없는데.. 통합테스트로 바꿔버릴까..' 생각도 잠깐 들었지만🙄 단위 테스트 코드를 꼭 한 번 작성해보고 싶었다!! 에러를 해결하지 못했을 때, 실제 AuthService의 saveRefreshToken 메소드를 호출하는 것을 보면서 '이 방식이 단위 테스트가 맞나..?' 했는데, 결과적으로 Spy 객체를 사용함으로써 단위 테스트의 의미를 퇴색시키지 않은 것 같아 다행이다.

참고

https://jojoldu.tistory.com/239 https://stackoverflow.com/questions/33124153/mockito-nullpointerexception-when-stubbing-method https://cobbybb.tistory.com/16

테스트 대상 단위가 엄격하게 정해져있지는 않지만, 일반적으로 클래스 또는 메소드 수준으로 정해진다. 단위의 크기가 작을수록 단위의 복잡성이 낮아지고, 실행하려는 기능을 표현하기 더 쉬워진다. 단위 테스트는 해당 부분만 독립적으로 테스트하기 때문에 어떤 코드를 리팩토링하여도 빠르게 문제 여부를 파악할 수 있다. 개발자는 작성한 테스트 코드를 수시로 빠르게 돌리면서 문제점을 파악할 수 있다.

@ExtendWith

단위 테스트에 공통적으로 사용할 확장 기능을 선언해주는 역할을 한다. 인자로 확장할 Extension을 명시하면 된다. SpringExtension.class 또는 MockitoExtension.class를 많이 사용한다. Spring Test Context 프레임워크와 Junit5와 통합해 사용할 때는 SpringExtension.class를 사용한다. JUniit5와 Mockito를 연동해 테스트를 진행할 경우에는 MockitoExtension.class를 사용한다. (스택오버플로우를 참고해보면 더 자세히 알 수 있다.)

Mockito

개발자가 동작을 직접 제어할 수 있는 가짜(Mock) 객체를 지원하는 테스트 프레임워크이다. 일반적으로 Spring으로 웹 애플리케이션을 개발하면, 여러 객체들 간의 의존성이 생긴다. 이러한 의존성은 단위 테스트를 작성을 어렵게 하는데, 이를 해결하기 위해 가짜 객체를 주입시켜주는 Mockito 라이브러리를 활용할 수 있다. Mockito를 활용하면 가짜 객체에 원하는 결과를 Stub하여 단위 테스트를 진행할 수 있다.

@Mock

Mock 객체를 생성한다. 실제로 메서드는 갖고 있지만 내부 구현이 없는 상태이다.

@Spy

모든 기능을 가지고 있는 완전한 객체이다. Stub하지 않은 메소드들은 원본 메소드 그대로 사용한다. 즉, 테스트 대상의 일부분만 Mocking 하는 것이다. 대체로 @Spy보다는 @Mock을 쓰는 것을 추천하지만, 외부 라이브러리를 이용한 테스트에는 @Spy를 사용하는 것을 추천한다.

@InjectMocks

@Mock 또는 @Spy로 생성된 가짜 객체를 자동으로 주입시켜주는 객체이다.

@InjectMocks 객체에서 사용할 객체를 @Mock으로 만들어 쓰면 된다. 만약 Service를 테스트하는 클래스를 생성했다면, Service 객체를 @InjectMocks 어노테이션을 사용해 생성하고, Service단에서 사용할 Repository와 같은 객체들은 @Mock 어노테이션을 사용해 생성하면 된다.

Stub

다른 객체 대신에 가짜 객체(Mock Object)를 주입하여 어떤 결과를 반환하라고 정해진 답변을 준비시킨다. Mock 객체의 메소드를 호출해도 실제로 코드를 실행하지 않기 때문에, 메소드의 행동을 미리 정해두어야 한다. when(), thenReturn(), thenThrow() 등을 사용해 리턴 값 또는 예외 발생을 정할 수 있다. 같은 조건으로 다시 stub 할 경우 이전의 행동을 덮어 씌운다.

doReturn / thenReturn 테스트 대상 기능 중 일부 기능이 준비가 되지 않았을 때 혹은 다른 시스템과 통신 등이 필요한 경우, 미리 리턴 값을 선언하여 테스트할 수 있다.

• doReturn
  • 메소드를 실제 호출하지 않으면서 리턴 값을 임의로 정할 수 있다.
  • 실제로 메소드를 호출하지 않기 때문에 대상 메소드에 문제점이 있어도 알 수 없다.
• thenReturn
  • 메소드를 실제 호출하지만, 리턴 값을 임의로 정의할 수 있다.
  • 메소드 작업이 오래 걸릴 경우 끝날 때까지 기다려야 한다.
  • 실제 메소드를 호출하기 때문에, 대상 메소드에 문제점이 있을 경우 발견할 수 있다.

참고

https://mangkyu.tistory.com/143 https://velog.io/@ausg/Mockito-Test-Framework-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0 https://jojoldu.tistory.com/239 https://royleej9.tistory.com/entry/Mockito-doReturn-thenReturn

실제 운영 환경에서 사용될 클래스들을 통합해 테스트한다. 단위 테스트처럼 기능 검증을 위한 것이 아닌, 전체적으로 플로우가 제대로 동작하는지 검증하기 위해 사용한다. 애플리케이션 설정과 Bean들을 모두 로드해 운영환경과 가장 유사한 테스트가 가능하다는 장점이 있지만, 시간이 오래 걸리고 무겁다는 단점이 있다. 또, 단위가 크기 때문에 디버깅이 어려운 편이다.

build.gradle

    testImplementation 'org.springframework.boot:spring-boot-starter-test'

@SpringBootTest

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)
@AutoConfigureMockMvc
class SampleControllerTest {
​
   @Autowired
   MockMvc mockMvc;
​
   @Test
   public void hello() throws Exception {
       mockMvc.perform(get("/hello"))
          .andExpect(status().isOk())
          .andExpect(content().string("hello namjune"))
          .andDo(print());
  }

@SpringBootApplication을 찾아서 테스트를 위한 빈들을 다 생성한다. 그리고, @MockBean으로 정의된 빈을 찾아서 교체한다.

webEnvironment

웹 테스트 환경 구성이 가능하다. default 값은 MOCK이다.

MOCK

WebApplicationContext를 로드하며, 내장된 서블릿 컨테이너가 아닌 Mock 서블릿을 제공한다. @AutoConfigureMockMvc 어노테이션을 함께 사용하면 별다른 설정 없이 간편하게 MockMvc를 사용한 테스트를 진행할 수 있다. MockMvc는 실제 객체와 비슷하지만 테스트에 필요한 기능만 가지는 가짜 객체를 만들어 스프링 MVC 동작을 재현할 수 있게 해주는 클래스이다. 브라우저에서 요청과 응답을 의미하는 객체로써, Controller 테스트 사용을 용이하게 해준다.

@AutoConfigureMockMvc
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)
class XXXTest {
    @Autowired
    public MockMvc mockMvc;
}

RANDOM_PORT / DEFINED_PORT

EmbeddedWebApplicationContext를 로드하며 실제 서블릿 환경을 구성한다. MockMvc 대신, RestTemplate를 사용할 수 있다. 실제 가용한 포트로 내장 톰캣을 띄우고 응답을 받아, 실제 서버가 동작하는 것처럼 테스트를 수행할 수 있다.

TestRestTemplate RestTemplate의 테스트를 위한 버전이다. NONE 설정을 제외한 webEnvironment 설정시 그에 맞춰서 자동으로 설정되어 빈이 생성된다. HTTP 요청 후, JSON, xml, String과 같은 응답을 받을 수 있는 템플릿이다.

@AutoConfigureMockMvc
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class XXXTest {
    @Autowired 
    private TestRestTemplate restTemplate;
}

NONE

서블릿 환경을 제공하지 않는다.

MockMvc과 TestRestTemplate의 차이

Servlet Container MockMvc는 서블릿 컨테이너를 생성하지 않는 반면, TestRestTemplate은 서블릿 컨테이너를 사용한다. 그래서 마치 실제 서버가 동작하는 것처럼 테스트를 수행할 수 있다.(몇몇 Bean은 Mock 객체로 대체될 수는 있다.)

테스트 관점 MockMvc는 서버 입장에서 구현한 API를 통해 비즈니스 로직이 문제 없이 수행되는지 테스트할 수 있다면, TestRestTemplate은 클라이언트의 입장에서 RestTemplate을 사용하듯이 테스트를 수행할 수 있다.

properties

프로퍼티를 {key=value} 형식으로 직접 추가할 수 있다.

@SpringBootTest(
    properties = {
        "propertyTest.value=propertyTest"
    }
)
class XXXTest {

    @Value("${propertyTest.value}")
    private String propertyValue; // 값: "propertyTest"

}

기본적으로 클래스 경로상의 application.properties 또는 application.yml를 통해 애플리케이션 설정을 하지만, 테스트를 위한 다른 설정이 필요할 경우 다른 프로퍼티를 로드할 수 있다.

@SpringBootTest(
    properties = {
        "spring.config.location=classpath:application-test.yml"
    }
)
class XXXTest {
    // ...
}

@MockBean

Controller 테스트 코드에서 Service 단으로 흘러 들어갈 경우, 테스트 단위가 너무 커지게 되고 구동 시간이 오래 걸린다. 만약 Controller만 테스트 하고 싶을 경우, Service 객체를 MockBean으로 만들어 사용할 수 있다. @MockBean 어노테이션을 사용하게 되면, Spring Application Context에 들어있는 Bean을 Mock으로 만든 객체(가짜 객체)로 교체한다. 모든 @Test마다 자동으로 리셋된다. 테스트할 때 Spring Boot Container가 필요하고 Bean이 Container에 존재한다면 @MockBean을 사용하고, 아닌 경우에는 @Mock을 쓰면 된다.

@AutoConfigureMockMvc
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)
class XXXTest {
    @Autowired
    public MockMvc mockMvc;

    @MockBean
    public TestService testService;
}

슬라이스 테스트

계층(layer) 별로 테스트하고 싶을 때 사용하게 되는 방법이다. 글의 시작 부분에 적은 것처럼@SpringBootTest의 경우 모든 Bean을 로드하는 통합 테스트이기 때문에, 테스트 구동 시간이 오래 걸리는 단점이 있다. 특정 계층만을 테스트하고 싶을 때 사용하면 유용하다. @JsonTest, @WebFluxTest, @DataJpaTest 등 다양한 어노테이션이 있지만, @WebMvcTest만 간단하게 적고 넘어가겠다. @WebMvcTest Application Context을 전체 로드해 사용하지 않고, Web 계층을 테스트하고 싶을 때 사용한다. Service, Repository 등 다른 dependency가 필요한 경우에 @MockBean으로 주입받아 테스트를 진행한다.

적용

공통으로 사용할 클래스

SimpleController

@RestController
@RequestMapping("/api/test")
public class SimpleController {

    @GetMapping("/")
    public ResponseEntity<String> getTest() {
        return ResponseEntity.ok("hello");
    }

    @PostMapping("/")
    public ResponseEntity<Map<String, String>> postTest(@RequestBody String request) {
        Map<String, String> body = new HashMap<>();
        body.put("response", request);
        return ResponseEntity.ok().body(body);
    }

    @GetMapping("/dto")
    public ResponseEntity<List<TestDto>> returnDtoTest() {
        TestDto testDto1 = TestDto.builder()
                .name("테스터1")
                .email("test1@test.co.kr")
                .build();
        TestDto testDto2 = TestDto.builder()
                .name("테스터2")
                .email("test2@test.co.kr")
                .build();
        List<TestDto> body = new ArrayList<>();
        body.add(testDto1);
        body.add(testDto2);
        return ResponseEntity.ok().body(body);
    }
}

MockMvc과 TestRestTemplate을

TestDto

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class TestDto {
    private String name;
    private String email;

    @Builder
    public TestDto(String name, String email) {
        this.name = name;
        this.email = email;
    }
}

webEnvironment별 테스트 클래스

MOCK

@AutoConfigureMockMvc
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)
class SimpleMockControllerTest {

    @Autowired
    public MockMvc mockMvc;

    @Test
    public void GET_테스트() throws Exception {
        mockMvc.perform(get("/api/test/"))
                .andExpect(status().isOk());
    }

    @Test
    public void POST_테스트() throws Exception {
        String request = "test";

        mockMvc.perform(post("/api/test/")
                        .content(request)
                        .contentType(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.response").value(request));
    }

    @Test
    public void DTO_리턴_테스트() throws Exception {
        mockMvc.perform(get("/api/test/dto")
                        .contentType(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.[0].name").value("테스터1"))        
                .andExpect(jsonPath("$.[1].name").value("테스터2"));
    }
}

RANDOM_PORT

@AutoConfigureMockMvc
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class SimpleRandomPortControllerTest {

    @Autowired
    public TestRestTemplate testRestTemplate;

    // 응답 Body를 JsonNode로 변환해주는 메소드
    public JsonNode readInfo(String content) {
        try {
            return new ObjectMapper().readTree(content);
        } catch (JsonProcessingException e) {
            throw new RuntimeException("JsonProcessingException");
        }
    }

    @Test
    public void GET_테스트() throws Exception {
        ResponseEntity<String> response = testRestTemplate.getForEntity("/api/test/", String.class);
        assertThat(response.getStatusCode().value()).isEqualTo(200);
    }

    @Test
    public void POST_테스트() throws Exception {
        String request = "test";

        ResponseEntity<String> response = testRestTemplate.postForEntity("/api/test/", request, String.class);
        JsonNode responseInfo = readInfo(response.getBody());

        assertThat(response.getStatusCodeValue()).isEqualTo(200);
        assertThat(responseInfo.get("response").asText()).isEqualTo(request);
    }

    @Test
    public void DTO_리턴_테스트() throws Exception {

        ResponseEntity<String> response = testRestTemplate.getForEntity("/api/test/dto", String.class);
        JsonNode responseInfo = readInfo(response.getBody());

        assertThat(response.getStatusCodeValue()).isEqualTo(200);
        assertThat(responseInfo.get(0).get("name").asText()).isEqualTo("테스터1");
        assertThat(responseInfo.get(1).get("name").asText()).isEqualTo("테스터2");
    }
}

참고

https://ict-nroo.tistory.com/96 https://www.inflearn.com/blogs/339

H2 연결

build.gradle

    runtimeOnly 'mysql:mysql-connector-java' // 개발 환경에서 사용하는 DB(MySQL)
    runtimeOnly 'com.h2database:h2' // 테스트 코드 작성시 사용할 DB(H2)

application.yml

• 위치: src/test/resources/application.yml
• H2에서 데이터베이스를 미리 생성해주어야 한다.

  spring:
  datasource:
    initialization-mode: always
    url: jdbc:h2:tcp://localhost/~/test
    username: sa
    password:
    driver-class-name: org.h2.Driver
  jpa:
    hibernate:
      ddl-auto: create
    properties:
      hibernate:
        format_sql: true
  logging.level:
  org.hibernate.SQL: debug

• jpa.hibernate.ddl-auto: create: 기존 테이블 삭제 후 다시 생성한다.
• jpa.properties.hibernate.format_sql: true: DB 쿼리를 포맷해 보기 좋게 보여준다.
• logging.level.org.hibernate.SQL: debug: 로그의 ?에 어떤 값이 들어갔는지 확인할 수 있다.

H2 DB를 In-Memory 방식으로 사용할 수도 있다.(링크 참조) spring.datasource.url에 jdbc:h2:mem을 작성해거나, spring.datasource의 값들을 다 삭제하면 된다.

Test Class

만약, MySQL을 사용하다가 DB를 분리했을 경우 java.lang.illegalstateexception: failed to load applicationcontext 에러가 발생할 수도 있다. 보통 H2 DB를 켜두지 않았거나, H2와 MySQL 연결에 혼동이 생겨 발생하는 에러인 듯 하다.

@AutoConfigureTestDatabase(connection = EmbeddedDatabaseConnection.H2)
public class XXXTest {
    // ...
}

테스트 클래스에 @AutoConfigureTestDatabase 어노테이션을 사용해 H2 DB와 연결할 것임을 명시해주면 된다.

Spring Boot 2.7.3 Java 11.0.9

상황

• Controller에서 @Valid 어노테이션을 사용해서

• Bean Validation(@NotNull)를 이용해 요청으로 받은 application/json 데이터를 검사

  // 예시
  public ResponseEntity<String> postComment(@RequestBody @Valid CommentDto commentDto) {
        // ...
  }

  // 예시
  public class RequestDto {
  
    @Getter
    @NoArgsConstructor(access = AccessLevel.PROTECTED)
    public static class CommentDto {
        @NotNull
        private Boolean isPublic;
        private String text;
    }
  }

• 아래처럼 요청을 보내게 됐을 때, MethodArgumentNotValidException 예외가 발생하기 때문에

  {
    "text": "abc"
  }

.m.m.a.ExceptionHandlerExceptionResolver : Resolved [org.springframework.web.bind.MethodArgumentNotValidException: Validation failed for argument [1] in public {Response_Return_Type} {Controller_Method}: [Field error in object '{DTO}' on field '{Field_Name}': rejected value [null]; codes [NotNull.requestDto.mobileIsPublic,NotNull.{Field_Name},NotNull.java.lang.Boolean,NotNull]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [{DTO}.{Field_Name}]; arguments []; default message [{Field_Name}]]; default message [널이어서는 안됩니다]] ]

• Response_Return_Type: org.springframework.http.ResponseEntity<java.lang.String>
• Controller_Method: postComment(CommentDto)
• DTO: CommentDto
• Field_Name: isPublic(예외 발생 원인)

• @RestControllerAdvice 어노테이션을 사용한 GlobalExceptionHandler를 이용해 예외 처리를 해준 상태였다.

  // 예시
  public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {
  
    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ErrorResponse> handleArgumentNotValidException(MethodArgumentNotValidException ex) {
        return ResponseEntity
                .status(HttpStatus.BAD_REQUEST); // 400 상태 코드 반환
    }
  }

발생한 에러

• 스프링부트 어플리케이션 실행시 BeanCreationException 발생

  org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'handlerExceptionResolver' defined in class path resource [org/springframework/boot/autoconfigure/web/servlet/WebMvcAutoConfiguration$EnableWebMvcConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.web.servlet.HandlerExceptionResolver]: Factory method 'handlerExceptionResolver' threw exception; nested exception is java.lang.IllegalStateException: Ambiguous @ExceptionHandler method mapped for [class org.springframework.web.bind.MethodArgumentNotValidException]: {public org.springframework.http.ResponseEntity {프로젝트명}.GlobalExceptionHandler.handleArgumentNotValidException(org.springframework.web.bind.MethodArgumentNotValidException), public final org.springframework.http.ResponseEntity org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler.handleException(java.lang.Exception,org.springframework.web.context.request.WebRequest) throws java.lang.Exception}

왜?

@ExceptionHandler에 이미 MethodArgumentNotValidException이 구현되어있기 때문에 GlobalExceptionHandler에서 동일한 예외 처리를 하게 되면, Ambiguous(모호성) 문제가 발생한다. 즉, MethodArgumentNotValidException 예외에 대해 어떤 방법을 사용해야 할 지 모르게 된다.

해결 방법

• 스택플로우 참고

• @ExceptionHandler 어노테이션을 사용하는 대신, 해당 핸들러(handleMethodArgumentNotValid)를 직접 오버라이드해서 사용한다.

  @RestControllerAdvice
  public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {
  
    @Override
    protected ResponseEntity<Object> handleMethodArgumentNotValid(MethodArgumentNotValidException ex,
                                                                  HttpHeaders headers,
                                                                  HttpStatus status,
                                                                  WebRequest request) {
        return super.handleMethodArgumentNotValid(ex, headers, status, request);
    }

  실행 결과

• 저는 에러 응답 형식을 일정하게 하기 위해 ErrorCode와 ErrorResponse를 생성했고,

  public enum ErrorCode {
    VALIDATION_FAILED(HttpStatus.BAD_REQUEST, "Validation failed for argument");
  
    private final HttpStatus httpStatus;
    private final String message;

  @Getter
  public class ErrorResponse {
    private final LocalDateTime timestamp = LocalDateTime.now();
    private final int statusCode;
    private final String error;
    private final String message;
  
    public ErrorResponse(ErrorCode errorCode) {
        this.statusCode = errorCode.getHttpStatus().value();
        this.error = errorCode.getHttpStatus().name();
        this.message = errorCode.getMessage();
    }
  }

• 오버라이딩한 handleMethodArgumentNotValid 핸들러를 아래와 같이 작성했습니다.

    // Bean Validation 예외 발생시
    @Override
    protected ResponseEntity<Object> handleMethodArgumentNotValid(MethodArgumentNotValidException ex, HttpHeaders headers, HttpStatus status, WebRequest request) {
        ErrorCode errorCode = ErrorCode.VALIDATION_FAILED;
        return ResponseEntity.status(errorCode.getHttpStatus())
                .body(new ErrorResponse(errorCode));
    }
  

- Postman에서 위와 똑같은 JSON 요청을 보내게 되면, 응답이 아래와 같이 출력됩니다.
![](https://velog.velcdn.com/images/u-nij/post/21a41411-91d4-43f2-8740-f82445a9ac54/image.png)

Spring Boot 2.7.3 Java 11.0.9

상황

• SecurityConfig의 securityFilterChain에서 .antMatchers("/api/user/**").authenticated()로 접근 제어
• JWT 토큰을 이용해 로그인을 구현했고, 특정 API에 접근하기 위해 Authorization Header에 Bearer {access-token} 값을 넣었다.

  발생한 에러

  org.springframework.security.authentication.InsufficientAuthenticationException: Full authentication is required to access this resource

왜?

• 로직에서 문제
  • Access Token을 검증하기 위한 필터(Filter)인 JwtAuthenticationFilter 에서 조건을 잘못 설정했다. 유효 기간만 제외하고 정상적인 Access Token에서 true를 반환시켰어야 했는데, 기간이 만료된 & 정상적인 토큰일 때 true를 반환시켰다.

해결 방법

로직 수정 (사실 로직 수정에 관련된 글이라 트러블 슈팅까지 남겨야 할까 생각이 들었지만, 저처럼 문제 찾는데 오랜 시간을 걸리는 분들이 계실까봐 작성하게 됐습니다..😅)

@RestController
@RequestMapping("/api/auth")
@RequiredArgsConstructor
public class AuthApiController {

    private final AuthService authService;
    private final UserService userService;
    private final BCryptPasswordEncoder encoder;

    private final long COOKIE_EXPIRATION = 7776000; // 90일

    // 회원가입
    @PostMapping("/signup")
    public ResponseEntity<Void> signup(@RequestBody @Valid AuthDto.SignupDto signupDto) {
        String encodedPassword = encoder.encode(signupDto.getPassword());
        AuthDto.SignupDto newSignupDto = AuthDto.SignupDto.encodePassword(signupDto, encodedPassword);

        userService.registerUser(newSignupDto);
        return new ResponseEntity<>(HttpStatus.OK);
    }

    // 로그인 -> 토큰 발급
    @PostMapping("/login")
    public ResponseEntity<?> login(@RequestBody @Valid AuthDto.LoginDto loginDto) {
        // User 등록 및 Refresh Token 저장
        AuthDto.TokenDto tokenDto = authService.login(loginDto);

        // RT 저장
        HttpCookie httpCookie = ResponseCookie.from("refresh-token", tokenDto.getRefreshToken())
                .maxAge(COOKIE_EXPIRATION)
                .httpOnly(true)
                .secure(true)
                .build();

        return ResponseEntity.ok()
                .header(HttpHeaders.SET_COOKIE, httpCookie.toString())
                // AT 저장
                .header(HttpHeaders.AUTHORIZATION, "Bearer " + tokenDto.getAccessToken())
                .build();
    }

    @PostMapping("/validate")
    public ResponseEntity<?> validate(@RequestHeader("Authorization") String requestAccessToken) {
        if (!authService.validate(requestAccessToken)) {
            return ResponseEntity.status(HttpStatus.OK).build(); // 재발급 필요X
        } else {
            return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build(); // 재발급 필요
        }
    }
    // 토큰 재발급
    @PostMapping("/reissue")
    public ResponseEntity<?> reissue(@CookieValue(name = "refresh-token") String requestRefreshToken,
                                     @RequestHeader("Authorization") String requestAccessToken) {
        AuthDto.TokenDto reissuedTokenDto = authService.reissue(requestAccessToken, requestRefreshToken);

        if (reissuedTokenDto != null) { // 토큰 재발급 성공
            // RT 저장
            ResponseCookie responseCookie = ResponseCookie.from("refresh-token", reissuedTokenDto.getRefreshToken())
                    .maxAge(COOKIE_EXPIRATION)
                    .httpOnly(true)
                    .secure(true)
                    .build();
            return ResponseEntity
                    .status(HttpStatus.OK)
                    .header(HttpHeaders.SET_COOKIE, responseCookie.toString())
                    // AT 저장
                    .header(HttpHeaders.AUTHORIZATION, "Bearer " + reissuedTokenDto.getAccessToken())
                    .build();

        } else { // Refresh Token 탈취 가능성
            // Cookie 삭제 후 재로그인 유도
            ResponseCookie responseCookie = ResponseCookie.from("refresh-token", "")
                    .maxAge(0)
                    .path("/")
                    .build();
            return ResponseEntity
                    .status(HttpStatus.UNAUTHORIZED)
                    .header(HttpHeaders.SET_COOKIE, responseCookie.toString())
                    .build();
        }
    }

    // 로그아웃
    @PostMapping("/logout")
    public ResponseEntity<?> logout(@RequestHeader("Authorization") String requestAccessToken) {
        authService.logout(requestAccessToken);
        ResponseCookie responseCookie = ResponseCookie.from("refresh-token", "")
                .maxAge(0)
                .path("/")
                .build();

        return ResponseEntity
                .status(HttpStatus.OK)
                .header(HttpHeaders.SET_COOKIE, responseCookie.toString())
                .build();
    }
}

• signUp: 회원을 등록한다. 중복 이메일에 대한 검사가 추가적으로 필요하지만, 우선 단순하게 진행하겠다. 원래는 UserService에서 암호화하려고 했지만, 순환 참조 문제로 BCryptPasswordEncoder를 Controller단으로 가져왔다.
• login: authService.login 메서드를 실행하고 토큰을 발급받는다. RT를 HTTP-ONLY Secure Cookie로, AT를 Authorization Header에 담아 보낸다.
• validate: AT를 재발급받을 필요가 없다면 상태 코드 OK(200)을 반환하고, 재발급받아야 한다면 401을 반환한다.
• reissue: validate 요청으로부터 UNAUTHORIZED(401)을 반환받았다면, 프론트에서 Cookie와 Header에 각각 RT와 AT를 요청으로 받아서 authService.reissue를 통해 토큰 재발급을 진행한다. 토큰 재발급이 성공한다면 login과 마찬가지로 응답 결과를 보내고, 토큰 재발급이 실패했을때(null을 반환받았을 때) Cookie에 담긴 RT를 삭제하고 재로그인을 유도한다.
• logout: authService.logout을 진행한 후, Cookie에 담긴 RT를 삭제한다.

Postman & Redis

회원가입

로그인

• Redis

재발급

로그아웃

• Redis

이상 Spring Boot에서 Redis와 Spring Security를 이용해 JWT를 구현해보고, Postman에서 테스트해보는 시간을 가졌다. 글을 쓰기까지 JWT에 대해 공부하고, 직접 구현하고, 디버깅해보면서 Spring Security의 Filter Chain과 Authentication Architecture가 돌아가는 방식에 대해 더 자세하게 알 수 있었다. 더 좋은 코드와 서비스를 위해 리팩토링할 부분이 남아 있지만, 성능을 위해 어떤 것을 고려하고 선택해야 하는지 조금이나마 공부해보았다. 이어서, OAuth2.0 OPEN API를 사용해보겠다.

GitHub

https://github.com/u-nij/Authentication-Using-JWT 지금까지 제가 작성한 코드를 깃허브 저장소에 남겨두었습니다.(글로 작성된 Spring Boot 버전과 약간 다릅니다.) 도움이 되셨다면 Star를 눌러주세요!😁✨

public class AuthDto {

    @Getter
    @NoArgsConstructor(access = AccessLevel.PROTECTED)
    public static class LoginDto {
        private String email;
        private String password;

        @Builder
        public LoginDto(String email, String password) {
            this.email = email;
            this.password = password;
        }
    }

    @Getter
    @NoArgsConstructor(access = AccessLevel.PROTECTED)
    public static class SignupDto {
        private String email;
        private String password;

        @Builder
        public SignupDto(String email, String password) {
            this.email = email;
            this.password = password;
        }

        public static SignupDto encodePassword(SignupDto signupDto, String encodedPassword) {
            SignupDto newSignupDto = new SignupDto();
            newSignupDto.email = signupDto.getEmail();
            newSignupDto.password = encodedPassword;
            return newSignupDto;
        }
    }

    @Getter
    @NoArgsConstructor(access = AccessLevel.PROTECTED)
    public static class TokenDto {
        private String accessToken;
        private String refreshToken;

        public TokenDto(String accessToken, String refreshToken) {
            this.accessToken = accessToken;
            this.refreshToken = refreshToken;
        }
    }
}

인증 과정에서 필요한 DTO를 작성했다. LoginDto와 SignUpDto는 비즈니스 니즈에 따라 필드들이 추가될 수 있다. encodePassword 메서드는 Controller에서 BCryptPasswordEncoder를 통해 password를 암호화한 후에 DTO를 재생성할 예정이기 때문에 작성했다.

UserService.class

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class UserService {

    private final UserRepository userRepository;

    @Transactional
    public void registerUser(AuthDto.SignupDto signupDto) {
        User user = User.registerUser(signupDto);
        userRepository.save(user);
    }
}

회원을 DB에 등록하기 위한 메서드이다.

AuthService.class

@Slf4j
@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class AuthService {

    private final JwtTokenProvider jwtTokenProvider;
    private final AuthenticationManagerBuilder authenticationManagerBuilder;
    private final RedisService redisService;

    private final String SERVER = "Server";

    // 로그인: 인증 정보 저장 및 비어 토큰 발급
    @Transactional
    public AuthDto.TokenDto login(AuthDto.LoginDto loginDto) {
        UsernamePasswordAuthenticationToken authenticationToken =
                new UsernamePasswordAuthenticationToken(loginDto.getEmail(), loginDto.getPassword());

        Authentication authentication = authenticationManagerBuilder.getObject()
                .authenticate(authenticationToken);
        SecurityContextHolder.getContext().setAuthentication(authentication);

        return generateToken(SERVER, authentication.getName(), getAuthorities(authentication));
    }

    // AT가 만료일자만 초과한 유효한 토큰인지 검사
    public boolean validate(String requestAccessTokenInHeader) {
        String requestAccessToken = resolveToken(requestAccessTokenInHeader);
        return jwtTokenProvider.validateAccessTokenOnlyExpired(requestAccessToken); // true = 재발급
    }

    // 토큰 재발급: validate 메서드가 true 반환할 때만 사용 -> AT, RT 재발급
    @Transactional
    public AuthDto.TokenDto reissue(String requestAccessTokenInHeader, String requestRefreshToken) {
        String requestAccessToken = resolveToken(requestAccessTokenInHeader);

        Authentication authentication = jwtTokenProvider.getAuthentication(requestAccessToken);
        String principal = getPrincipal(requestAccessToken);

        String refreshTokenInRedis = redisService.getValues("RT(" + SERVER + "):" + principal);
        if (refreshTokenInRedis == null) { // Redis에 저장되어 있는 RT가 없을 경우
            return null; // -> 재로그인 요청
        }

        // 요청된 RT의 유효성 검사 & Redis에 저장되어 있는 RT와 같은지 비교
        if(!jwtTokenProvider.validateRefreshToken(requestRefreshToken) || !refreshTokenInRedis.equals(requestRefreshToken)) {
            redisService.deleteValues("RT(" + SERVER + "):" + principal); // 탈취 가능성 -> 삭제
            return null; // -> 재로그인 요청
        }

        SecurityContextHolder.getContext().setAuthentication(authentication);
        String authorities = getAuthorities(authentication);

        // 토큰 재발급 및 Redis 업데이트
        redisService.deleteValues("RT(" + SERVER + "):" + principal); // 기존 RT 삭제
        AuthDto.TokenDto tokenDto = jwtTokenProvider.createToken(principal, authorities);
        saveRefreshToken(SERVER, principal, tokenDto.getRefreshToken());
        return tokenDto;
    }

    // 토큰 발급
    @Transactional
    public AuthDto.TokenDto generateToken(String provider, String email, String authorities) {
        // RT가 이미 있을 경우
        if(redisService.getValues("RT(" + provider + "):" + email) != null) {
            redisService.deleteValues("RT(" + provider + "):" + email); // 삭제
        }

        // AT, RT 생성 및 Redis에 RT 저장
        AuthDto.TokenDto tokenDto = jwtTokenProvider.createToken(email, authorities);
        saveRefreshToken(provider, email, tokenDto.getRefreshToken());
        return tokenDto;
    }

    // RT를 Redis에 저장
    @Transactional
    public void saveRefreshToken(String provider, String principal, String refreshToken) {
        redisService.setValuesWithTimeout("RT(" + provider + "):" + principal, // key
                refreshToken, // value
                jwtTokenProvider.getTokenExpirationTime(refreshToken)); // timeout(milliseconds)
    }

    // 권한 이름 가져오기
    public String getAuthorities(Authentication authentication) {
        return authentication.getAuthorities().stream()
                .map(GrantedAuthority::getAuthority)
                .collect(Collectors.joining(","));
    }

    // AT로부터 principal 추출
    public String getPrincipal(String requestAccessToken) {
        return jwtTokenProvider.getAuthentication(requestAccessToken).getName();
    }

    // "Bearer {AT}"에서 {AT} 추출
    public String resolveToken(String requestAccessTokenInHeader) {
        if (requestAccessTokenInHeader != null && requestAccessTokenInHeader.startsWith("Bearer ")) {
            return requestAccessTokenInHeader.substring(7);
        }
        return null;
    }

    // 로그아웃
    @Transactional
    public void logout(String requestAccessTokenInHeader) {
        String requestAccessToken = resolveToken(requestAccessTokenInHeader);
        String principal = getPrincipal(requestAccessToken);

        // Redis에 저장되어 있는 RT 삭제
        String refreshTokenInRedis = redisService.getValues("RT(" + SERVER + "):" + principal);
        if (refreshTokenInRedis != null) {
            redisService.deleteValues("RT(" + SERVER + "):" + principal);
        }

        // Redis에 로그아웃 처리한 AT 저장
        long expiration = jwtTokenProvider.getTokenExpirationTime(requestAccessToken) - new Date().getTime();
        redisService.setValuesWithTimeout(requestAccessToken,
                "logout",
                expiration);
    }
}

Refresth Token(이하 RT)과 Access Token(이하 AT)를 다루기 위해 생성한 Service단 클래스이다. 코드를 이렇게 작성한 이유와 주석 외의 추가 설명이 필요하다고 생각되는 부분을 적어보겠다.

큰 틀은 이렇게 된다.

• 요청 -> AT 검사 -> AT 유효 -> 요청 실행
• 요청 -> AT 검사 -> AT 기간만 만료 -> AT, RT로 재발급 요청 -> RT 유효 -> 재발급
• 요청 -> AT 검사 -> AT 기간만 만료 -> AT, RT로 재발급 요청 -> RT 유효X -> 재로그인

변수

• SERVER: RT를 생성한 후 Redis에 {key:RT({발급자}):{email}, value:{RT}} 형식으로 저장할 예정이다. OAuth2.0 OPEN API를 적용할 때 발급자에 Naver, Kakao 등 발급된 서버를 표시해두기 위해서이다. 자세한 내용은 나중에 OAuth2.0 OPEN API에 관련된 포스팅에서 다루겠다. 일단 우리 서버에서 발급된 RT는 {key:RT(Server):{email}, value:{RT}} 형식으로 Redis에 저장된다는 것만 기억하면 된다.
• requestAccessTokenInHeader: "Bearer {AT}"의 형식을 갖고 있다.

  resolveToken(String requestAccessTokenInHeader) 메서드를 통해 "Bearer {AT}"로부터 AT를 추출할 예정이다. Controller단에서 추출해 Service단으로 가져와도 크게 상관 없을 것이다. 하지만, 나중에 OAuth2.0 OPEN API에서 사용할 때 서버(Naver, Kakao 등)별로 Controller를 분리하게 될텐데 그 때의 반복되는 코드 작성을 피하고, Controller단과 Service단의 기능을 분리하기 위해서 이처럼 작성하게 되었다.

메서드

• login: Filter 과정을 거치고 생성된 UsernamePasswordAuthenticationToken으로부터 Authentication 객체를 생성해 SecurityContextHolder에 저장한다. generateToken 메서드를 통해 RT와 AT를 발급해 반환한다.

  DB에 저장된 인코딩된 값과 입력된 비밀번호를 어떻게 비교하는지

  

  login 메서드에서 사용자로부터 입력받은 email과 password 값을 이용해 UsernamePasswordAuthenticationToken을 생성하게 되고, AuthenticationManagerBuilder를 통해 사용자 인증을 진행하게 됩니다. AuthenticationManagerBuilder는 자신이 가지고 있는 인코더로 사용자로부터 입력받은 password 값, 즉 Credential을 암호화합니다.

  이 때, AuthenticationManagerBuilder의 defaultPasswordEncorder가 사용자가 회원가입할 때 사용했던 BCryptPasswordEncoder이기 때문에 입력된 비밀번호와 DB에 저장되어 있는 값과 비교가 가능하게 됩니다.

• validate: 만료일자만 만료된 유효한 토큰인지 검사하고, 해당할 경우에 true를 리턴한다.

• reissue: 요청으로 받은 AT와 RT를 검사한 후, 토큰을 재발급하는 메서드이다. AT로부터 Authentication 객체를 가져온다. SecurityContextHolder에 객체를 저장하기 전, 다음의 두 과정을 통과해야 한다.

  • Redis에 저장되어 있는 기존 Redis가 있어야 한다. 만약 없을 경우, 로그인이 만료되었다고 보고, null을 반환함으로써 재로그인을 요청한다.
  • 요청으로 받은 RT가 유효한지 검사하고, Redis에 저장된 기존 RT와 같은지 비교한다. 만약 유효하지 않거나 기존 RT와 다르다고 판단되면 RT가 탈취되었다고 결론 내리고, null을 반환함으로써 재로그인을 요청한다.

  두 과정을 거치고 난 후, Authentication 객체를 저장한다. 그리고, AT와 RT를 재발급하고 발급된 RT를 Redis에 저장한다.

• generateToken: Redis에 기존의 RT가 이미 있을 경우, 삭제한다. AT와 RT를 생성하고, Redis에 새로 발급한 RT를 저장한다.

• logout: Redis에 저장되어 있는 RT를 삭제하고, Redis에 로그아웃 처리한 AT 저장해 해당 AT를 이용한 요청을 방지한다.

@Slf4j
@Component
@Transactional(readOnly = true)
public class JwtTokenProvider implements InitializingBean {

    private final UserDetailsServiceImpl userDetailsService;
    private final RedisService redisService;

    private static final String AUTHORITIES_KEY = "role";
    private static final String EMAIL_KEY = "email";
    private static final String url = "https://localhost:8080";

    private final String secretKey;
    private static Key signingKey;

    private final Long accessTokenValidityInMilliseconds;
    private final Long refreshTokenValidityInMilliseconds;

    public JwtTokenProvider(
            UserDetailsServiceImpl userDetailsService,
            RedisService redisService,
            @Value("${jwt.secret}") String secretKey,
            @Value("${jwt.access-token-validity-in-seconds}") Long accessTokenValidityInMilliseconds,
            @Value("${jwt.refresh-token-validity-in-seconds}") Long refreshTokenValidityInMilliseconds) {
        this.userDetailsService = userDetailsService;
        this.redisService = redisService;
        this.secretKey = secretKey;
        // seconds -> milliseconds
        this.accessTokenValidityInMilliseconds = accessTokenValidityInMilliseconds * 1000;
        this.refreshTokenValidityInMilliseconds = refreshTokenValidityInMilliseconds * 1000;
    }

    // 시크릿 키 설정
    @Override
    public void afterPropertiesSet() throws Exception {
        byte[] secretKeyBytes = Decoders.BASE64.decode(secretKey);
        signingKey = Keys.hmacShaKeyFor(secretKeyBytes);
    }

    @Transactional
    public AuthDto.TokenDto createToken(String email, String authorities){
        Long now = System.currentTimeMillis();

        String accessToken = Jwts.builder()
                .setHeaderParam("typ", "JWT")
                .setHeaderParam("alg", "HS512")
                .setExpiration(new Date(now + accessTokenValidityInMilliseconds))
                .setSubject("access-token")
                .claim(url, true)
                .claim(EMAIL_KEY, email)
                .claim(AUTHORITIES_KEY, authorities)
                .signWith(signingKey, SignatureAlgorithm.HS512)
                .compact();

        String refreshToken = Jwts.builder()
                .setHeaderParam("typ", "JWT")
                .setHeaderParam("alg", "HS512")
                .setExpiration(new Date(now + refreshTokenValidityInMilliseconds))
                .setSubject("refresh-token")
                .signWith(signingKey, SignatureAlgorithm.HS512)
                .compact();

        return new AuthDto.TokenDto(accessToken, refreshToken);
    }


    // == 토큰으로부터 정보 추출 == //

    public Claims getClaims(String token) {
        try {
            return Jwts.parserBuilder()
                    .setSigningKey(signingKey)
                    .build()
                    .parseClaimsJws(token)
                    .getBody();
        } catch (ExpiredJwtException e) { // Access Token
            return e.getClaims();
        }
    }

    public Authentication getAuthentication(String token) {
        String email = getClaims(token).get(EMAIL_KEY).toString();
        UserDetailsImpl userDetailsImpl = userDetailsService.loadUserByUsername(email);
        return new UsernamePasswordAuthenticationToken(userDetailsImpl, "", userDetailsImpl.getAuthorities());
    }

    public long getTokenExpirationTime(String token) {
        return getClaims(token).getExpiration().getTime();
    }


    // == 토큰 검증 == //

    public boolean validateRefreshToken(String refreshToken){
        try {
            if (redisService.getValues(refreshToken).equals("delete")) { // 회원 탈퇴했을 경우
                return false;
            }
            Jwts.parserBuilder()
                    .setSigningKey(signingKey)
                    .build()
                    .parseClaimsJws(refreshToken);
            return true;
        } catch (SignatureException e) {
            log.error("Invalid JWT signature.");
        } catch (MalformedJwtException e) {
            log.error("Invalid JWT token.");
        } catch (ExpiredJwtException e) {
            log.error("Expired JWT token.");
        } catch (UnsupportedJwtException e) {
            log.error("Unsupported JWT token.");
        } catch (IllegalArgumentException e) {
            log.error("JWT claims string is empty.");
        } catch (NullPointerException e){
            log.error("JWT Token is empty.");
        }
        return false;
    }

    // Filter에서 사용
    public boolean validateAccessToken(String accessToken) {
        try {
            if (redisService.getValues(accessToken) != null // NPE 방지
                    && redisService.getValues(accessToken).equals("logout")) { // 로그아웃 했을 경우
                return false;
            }
            Jwts.parserBuilder()
                    .setSigningKey(signingKey)
                    .build()
                    .parseClaimsJws(accessToken);
            return true;
        } catch(ExpiredJwtException e) {
            return true;
        } catch (Exception e) {
            return false;
        }
    }

    // 재발급 검증 API에서 사용
    public boolean validateAccessTokenOnlyExpired(String accessToken) {
        try {
            return getClaims(accessToken)
                    .getExpiration()
                    .before(new Date());
        } catch(ExpiredJwtException e) {
            return true;
        } catch (Exception e) {
            return false;
        }
    }

}

토큰 생성

• Secret Key 값을 사용하기 전 미리 초기화하기 위해 InitializingBean 인터페이스를 상속받고 afterPropertiesSet메서드를 오버라이딩해 사용하겠다.
• 생성자에서 @Value 어노테이션을 이용해 application.yml에서 미리 설정해둔 값을 가져와 사용한다. application.yml에 적어둔 토큰들의 유효 기간 값의 단위가 seconds이기 때문에, 1000을 곱해 milliseconds로 변경해준다.
• createToken(String email, String authorities): 토큰 발급 메서드. User.email(Principal)값과 User.role 값을 매개변수로 받아 사용한다. 이전에 포스팅했던 claims의 종류들을 골고루 사용해보았다.

  Refresh Token에는 claims를 최소화했다. Access Token이든 Refresh Token이든 탈취되어 악용되었을 때 문제가 된다. 두 토큰이 같은 정보량을 가질 때, 비교적 짧은 시간 안에 유효기간이 만료되는 Access Token보다는 긴 유효기간을 가지는 Refresh Token이 탈취되었을 때 더 치명적이라는 생각이 들었다. 그리고, 사용자를 "인증"하는 용도로 사용되는 Access Token과 달리, Refresh Token은 Access Token의 "재발급"만을 위해 사용되기 때문에 claims를 최소화하는게 맞다고 생각했다.

  토큰 검증

• getClaims(String token): 토큰으로부터 Claims를 추출해 반환한다.
• getAuthentication(String token): 토큰으로부터 인증 정보 객체인 UsernamePasswordAuthenticationToken을 반환한다.
• getTokenExpirationTime(String token): 토큰으로부터 유효기간을 반환한다.

  토큰으로부터 정보 추출

• validateRefreshToken(String refreshToken): 토큰을 검증한다. 각 예외별로 log를 남기고 false를 반환한다.
• validateAccessToken(String accessToken): Filter에서 AT 검증을 위해 쓰인다. 기간이 만료됐을 경우에도 true를 반환한다.
• validateAccessTokenOnlyExpired(String accessToken): 유효기간만 만료된 유효한 토큰일 경우 true를 반환한다.

@RequiredArgsConstructor
@Configuration
@EnableRedisRepositories
public class RedisRepositoryConfig {

    private final RedisProperties redisProperties;

    // lettuce
    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory(redisProperties.getHost(), redisProperties.getPort());
    }

    // redis-cli 사용을 위한 설정
    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(redisConnectionFactory());
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new StringRedisSerializer());
        return redisTemplate;
    }
}

Redis의 연결을 정의하는 클래스이다. RedisConnectionFactory를 통해 내장 혹은 외부의 Redis와 연결한다. RedisTemplate를 통해 RedisConnection에서 넘겨준 byte 값을 객체 직렬화한다.

RedisTemplate을 열어보면 Hash, Set 등 다양한 방식을 사용해 Redis에 데이터를 저장하는 방법을 알 수 있다.

RedisService.class

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class RedisService {

    private final RedisTemplate<String, String> redisTemplate;

    @Transactional
    public void setValues(String key, String value){
        redisTemplate.opsForValue().set(key, value);
    }

    // 만료시간 설정 -> 자동 삭제
    @Transactional
    public void setValuesWithTimeout(String key, String value, long timeout){
        redisTemplate.opsForValue().set(key, value, timeout, TimeUnit.MILLISECONDS);
    }

    public String getValues(String key){
        return redisTemplate.opsForValue().get(key);
    }

    @Transactional
    public void deleteValues(String key) {
        redisTemplate.delete(key);
    }
}

Redis를 편히 사용하기 위해 메서드화했다.

• setValues(String key, String value): {key, value] 값을 저장한다.
• setValuesWithTimeout(String key, String value, long timeout): {key, value] 값을 유효시간(timeout)과 함께 저장할 수 있다. 단위는 토큰의 유효기간 단위와 동일하게 milliseconds로 지정했다.
• getValues(String key): key 값을 사용해 value 값을 가져온다.
• deleteValues(String key): key 값을 사용해 데이터를 삭제한다.

@Slf4j
@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtTokenProvider jwtTokenProvider;

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

        // Access Token 추출
        String accessToken = resolveToken(request);

        try { // 정상 토큰인지 검사
            if (accessToken != null && jwtTokenProvider.validateAccessToken(accessToken)) {
                Authentication authentication = jwtTokenProvider.getAuthentication(accessToken);
                SecurityContextHolder.getContext().setAuthentication(authentication);
                log.debug("Save authentication in SecurityContextHolder.");
            }
        } catch (IncorrectClaimException e) { // 잘못된 토큰일 경우
            SecurityContextHolder.clearContext();
            log.debug("Invalid JWT token.");
            response.sendError(403);
        } catch (UsernameNotFoundException e) { // 회원을 찾을 수 없을 경우
            SecurityContextHolder.clearContext();
            log.debug("Can't find user.");
            response.sendError(403);
        }

        filterChain.doFilter(request, response);
    }

    // HTTP Request 헤더로부터 토큰 추출
    public String resolveToken(HttpServletRequest httpServletRequest) {
        String bearerToken = httpServletRequest.getHeader("Authorization");
        if (bearerToken != null && bearerToken.startsWith("Bearer ")) {
            return bearerToken.substring(7);
        }
        return null;
    }
}

SecurityConfig.class에서 UsernamePasswordAuthenticationFilter 이전에 통과할 Filter이다. 인증(Authentication)이 필요한 요청(Request)이 오면 요청의 헤더(Header)에서 Access Token을 추출하고 정상 토큰인지 검사한다. jwtTokenProvider.validateToken(accessToken) 메서드를 통해 유효 기간을 제외하고 정상적인 Access Token인지 검사한다. 유효 기간만 제외하고 정상적인 토큰일 경우, 유저 모르게 Access Token을 재발급하고 로그인을 연장시킴과 동시에 다시 요청을 처리하도록 하기 위함이다.(Silent refresh) 이 작업을 진행하기 위해서는 프론트엔드에서 추가 작업이 필요하다. 재발급 API에 접근한 후, 응답에 따라 원래 처리할 요청 or 로그인으로 리다이렉트되게끔 해야 한다. logout 처리된 Access Token은 더이상 사용하지 못하게 하기 위해 Redis에 저장할 예정이기 때문에 Redis에 logout 여부를 확인하는 로직을 추가했다.

JwtAccessDeniedHandler.class

@Slf4j
@Component
public class JwtAccessDeniedHandler implements AccessDeniedHandler {

    @Override
    public void handle(HttpServletRequest request,
                       HttpServletResponse response,
                       AccessDeniedException accessDeniedException) throws IOException {

        response.setCharacterEncoding("utf-8");
        response.sendError(403, "권한이 없습니다.");
    }
}

SecurityConfig에 예외 처리를 위해 설정해놓은 클래스이다. 인증(Authentication)이 실패했을 때 실행된다. 예를 들자면, ROLE_ADMIN 권한이 있는 사용자가 필요한 요청에 ROLE_USER 권한을 가진 사용자가 접근했을 때 실행된다.

JwtAuthenticationEntryPoint.class

@Slf4j
@Component
public class JwtAuthenticationEntryPoint implements AuthenticationEntryPoint {

    @Override
    public void commence(HttpServletRequest request,
                         HttpServletResponse response,
                         AuthenticationException authException) throws IOException, ServletException {

        response.setCharacterEncoding("utf-8");
        response.sendError(401, "잘못된 접근입니다.");
    }
}

인가(Authorization)가 실패했을 때 실행된다. 예를 들자면, 로그인 된 사용자가 필요한 요청에 로그인하지 않은 사용자가 접근했을 때 실행된다.

@Entity(name = "users")
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "user_id")
    private Long id;

    private String email; // Principal

    private String password; // Credential

    @Enumerated(EnumType.STRING)
    private Role role; // 사용자 권한

    // == 생성 메서드 == //
    public static User registerUser(AuthDto.SignupDto signupDto) {
        User user = new User();

        user.email = signupDto.getEmail();
        user.password = signupDto.getPassword();
        user.role = Role.USER;

        return user;
    }
}

사용자 정보를 저장하거나 비즈니스 로직을 처리하기 위해서는 추가적인 필드, 메서드들을 구현해야 한다. 인증의 용도로 사용하는 UserDetails와 분리할 필요성을 느껴 별도로 클래스를 생성했다. AuthDto는 나중에 작성하겠다.

Role.class

@Getter
@RequiredArgsConstructor
public enum Role {
    ADMIN("ROLE_ADMIN", "관리자"),
    USER("ROLE_USER", "일반 사용자");

    private final String key;
    private final String title;
}

DB에 ROLE_이라는 접두어를 붙여 저장하고 싶지 않을 때 이처럼 사용할 수 있다. hasRole("ADMIN")이라고 작성시 UserDetailsService에서 Authorities를 가져와 확인할 때 자동으로 ROLE_이라는 접두어를 붙여 확인한다. SecurityConfig에서 리소스의 권한을 설정할 때 hasRole("ADMIN") 대신에 hasAuthority("ROLE_ADMIN")으로 사용해도 무방하다.

UserRepository.interface

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEmail(String email);
}

DB로부터 email 값을 이용해 User 객체를 불러오기 위한 메소드이다.

UserDetailsImpl.class

public class UserDetailsImpl implements UserDetails {

    private final User user;

    public UserDetailsImpl(User user) {
        this.user = user;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        Collection<GrantedAuthority> authorities = new ArrayList<>();
        authorities.add(() -> user.getRole().getKey()); // key: ROLE_권한
        return authorities;
    }

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

    @Override
    public String getPassword() {
        return user.getPassword();
    }


    // == 세부 설정 == //

    @Override
    public boolean isAccountNonExpired() { // 계정의 만료 여부
        return true;
    }

    @Override
    public boolean isAccountNonLocked() { // 계정의 잠김 여부
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() { // 비밀번호 만료 여부
        return true;
    }

    @Override
    public boolean isEnabled() { // 계정의 활성화 여부
        return true;
    }
}

유저의 정보를 가져오는 UserDetails 인터페이스를 상속하는 클래스이다. Authentication을 담고 있다. user.getRole().getKey()를 통해 사용자의 권한(Authorities)를 부여해 가져올 수 있다. Principal과 Credential로 사용할 필드를 각각 User.email, User.password로 정해두었다. 세부 설정은 현재로써 필요하지 않기 때문에 true로 반환하게만 해두었다.

UserDetailsServiceImpl.class

@Component
@RequiredArgsConstructor
public class UserDetailsServiceImpl implements UserDetailsService {

    private final UserRepository userRepository;

    @Override
    public UserDetailsImpl loadUserByUsername(String email) throws UsernameNotFoundException {
        User findUser = userRepository.findByEmail(email)
                .orElseThrow(() -> new UsernameNotFoundException("Can't find user with this email. -> " + email));

        if(findUser != null){
            UserDetailsImpl userDetails = new UserDetailsImpl(findUser);
            return  userDetails;
        }

        return null;
    }
}

DB에서 사용자의 정보를 직접 가져오는 인터페이스이다. loadUserByUsername(String username)을 오버라이드해 구현했다. 이 메소드를 사용해 UserDetails를 구현한 UserDetailsImpl 객체를 리턴해 인증 과정에 사용하게 된다.

Spring Boot와 React를 연동하기 위해 REST API 방식으로 구현할 예정이다. 사용자의 정보를 저장하기 위해 기본적으로 MySQL를 사용하고, Refresh Token을 저장하기 위해 Redis를 사용할 예정이다. Refresh Token을 가져오기 위해 토큰 검사가 필요할 때마다 DB에 쿼리를 날리는 것은 좋지 않다고 생각해 Redis를 사용하게 되었다.

Spring Boot 2.6.5 React.js java 11.0.9 Redis MySQL IDE Intellij

build.gradle

dependencies {
    // spring boot
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-validation'
    implementation 'org.projectlombok:lombok:1.18.20'
    // DB
    runtimeOnly 'com.h2database:h2'
    // spring security
    implementation 'org.springframework.boot:spring-boot-starter-security'
    // Redis
    implementation 'org.springframework.boot:spring-boot-starter-data-redis-reactive'
    // jwt
    implementation 'javax.xml.bind:jaxb-api'
    implementation 'io.jsonwebtoken:jjwt-api:0.11.1'
    runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.1'
    runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.1'
    // test
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'io.projectreactor:reactor-test'
    testImplementation 'org.springframework.security:spring-security-test'
}

application.yml

spring:
  redis:
    host: localhost
    port: 6379
  datasource: # local db
    url: jdbc:h2:tcp://localhost/~/test
    username: sa
    password:
    driver-class-name: org.h2.Driver
  jpa:
    hibernate:
      ddl-auto: create
    properties:
      hibernate:
        format_sql: true

logging.level:
  org.hibernate.SQL: debug

jwt:
  secret: {임의의 문자열을 Base64로 인코딩한 값}
  refresh-token-validity-in-seconds: 1209600 # 14일
  access-token-validity-in-seconds: 43200 # 12시간

Redis와 JWT를 사용하기 위한 값이다. JPA Debug, DB 설정과 같은 추가적인 값들은 따로 작성하지 않겠다.

• spring.redis: Redis 연결을 위한 설정 값.
• jwt.secret: 서명에 사용할 시크릿 키 값. HS512 알고리즘을 사용하기 때문에, Secret Key는 64Byte 이상 되어야 한다.
• jwt.refresh-token-validity-in-seconds, access-token-validity-in-seconds: 각각 Refresh Token과 Access Token의 유효 시간을 초(second) 단위로 나타낸 값.

Spring Security

인증(Authentication)과 인가(Authorization)

• 인증: 해당 사용자가 본인이 맞는지 확인하는 과정
• 인가: 해당 사용자가 요청하는 자원을 실행할 수 있는 권한이 있는가를 확인하는 과정

Spring Security는 기본적으로 인증 절차를 거친 후에 인가 절차를 진행하며, 인가 과정에서 해당 리소스에 접근 권한이 있는지 확인하게 된다. Spring Security에서는 이러한 인증과 인가를 위해 Principal(접근 주체)을 아이디로, Credential(비밀번호)을 비밀번호로 사용하는 Credential 기반의 인증 방식을 사용한다.

Authentication Architecture

Spring Security는 '인증'과 '권한'에 대한 부분을 필터(Filter) 흐름에 따라 처리한다. 요청이 들어오면, 인증과 권한을 위한 필터들을 통하게 된다. 유저가 인증을 요청할때 필터는 인증 메커니즘과 모델을 기반으로 한 필터들을 통과한다.

Client (request) → Filter → DispatcherServlet → Interceptor →  Controller

Filter는 Dispatcher Servlet으로 가기 전에 적용되므로 가장 먼저 URL 요청을 받지만, (웹 컨테이너에서 관리) Interceptor는 Dispatcher와 Controller 사이에 위치한다는 점에서 적용 시기의 차이가 있다. (스프링 컨테이너에서 관리)

1. 사용자가 로그인 정보와 함께 인증 요청을 한다. 2. AuthenticationFilter가 요청을 가로채고, 가로챈 정보를 통해 UsernamePasswordAuthenticationToken의 인증용 객체를 생성한다. 3. AuthenticationManager의 구현체인 ProviderManager에게 생성한 UsernamePasswordToken 객체를 전달한다. 4. AuthenticationManager는 등록된 AuthenticationProvider를 조회하여 인증을 요구한다. 5. 실제 DB에서 사용자 인증정보를 가져오는 UserDetailsService에 사용자 정보를 넘겨준다. 6. 넘겨받은 사용자 정보를 통해 DB에서 찾은 사용자 정보인 UserDetails 객체를 만든다. 7. AuthenticationProvider는 UserDetails를 넘겨받고 사용자 정보를 비교한다. 8. 인증이 완료되면 권한 등의 사용자 정보를 담은 Authentication 객체를 반환한다. 9. 다시 최초의 AuthenticationFilter에 Authentication 객체가 반환된다. 10. Authenticaton 객체를 SecurityContext에 저장한다.

Security Filter Chain

• SecurityContextPersistenceFilter - 요청(request)전에, SecurityContextRepository에서 받아온 정보를 SecurityContextHolder에 주입합니다.
• LogoutFilter - 주체(Principal)의 로그아웃을 진행합니다. 주체는 보통 유저를 말합니다.
• UsernamePasswordAuthenticationFilter - (로그인) 인증 과정을 진행합니다.
• DefaultLoginPageGeneratingFilter - 사용자가 별도의 로그인 페이지를 구현하지 않은 경우, 스프링에서 기본적으로 설정한 로그인 페이지를 처리합니다.
• BasicAuthenticationFilter - HTTP 요청의 (BASIC)인증 헤더를 처리하여 결과를 SecurityContextHolder에 저장합니다.
• RememberMeAuthenticationFilter - SecurityContext에 인증(Authentication) 객체가 있는지 확인하고 RememberMeServices를 구현한 객체의 요청이 있을 경우, Remember-Me(ex 사용자가 바로 로그인을 하기 위해서 저장 한 아이디와 패스워드)를 인증 토큰으로 컨텍스트에 주입합니다.
• AnonymousAuthenticationFilter - SecurityContextHolder에 인증(Authentication) 객체가 있는지 확인하고, 필요한 경우 익명 사용자로 Authentication 객체를 주입합니다.(Authentication이 Null인 것을 방지)
• SessionManagementFilter - 요청이 시작된 이후 인증된 사용자인지 확인하고, 인증된 사용자일 경우SessionAuthenticationStrategy를 호출하여 세션 고정 보호 메커니즘을 활성화하거나 여러 동시 로그인을 확인하는 것과 같은 세션 관련 활동을 수행합니다.
• ExceptionTranslationFilter - 필터 체인 내에서 발생(Throw)되는 모든 예외(AccessDeniedException, AuthenticationException)를 처리합니다.
• FilterSecurityInterceptor - HTTP 리소스의 보안 처리를 수행한다. 사용자가 요청한 request에 들어가고 결과를 리턴해도 되는 권한(Authorization)이 있는지를 검사합니다. 해당 필터에서 권한이 없다는 결과가 나온다면 위의 ExcpetionTranslationFilter필터에서 Exception을 처리해줍니다.

SecurityConfig.class

Spring Security 5.70 이후부터 WebSecurityConfigurerAdapter를 상속 받는 방식은 deprecated되었기 때문에, 공식 문서를 참고해 SecurityConfig를 작성해보았다.

@Configuration
@EnableWebSecurity // Spring Security 설정 클래스
@EnableGlobalMethodSecurity(securedEnabled = true)
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtTokenProvider jwtTokenProvider;
    private final JwtAccessDeniedHandler jwtAccessDeniedHandler;
    private final JwtAuthenticationEntryPoint jwtAuthenticationEntryPoint;

    @Bean
    public BCryptPasswordEncoder encoder() {
    // 비밀번호를 DB에 저장하기 전 사용할 암호화
        return new BCryptPasswordEncoder();
    }

    @Bean
    public WebSecurityCustomizer webSecurityCustomizer() {
        // ACL(Access Control List, 접근 제어 목록)의 예외 URL 설정
        return (web)
                -> web
                .ignoring()
                .requestMatchers(PathRequest.toStaticResources().atCommonLocations()); // 정적 리소스들
    }

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        // 인터셉터로 요청을 안전하게 보호하는 방법 설정
        http
                // jwt 토큰 사용을 위한 설정
                .csrf().disable()
                .httpBasic().disable()
                .formLogin().disable()
                .addFilterBefore(new JwtAuthenticationFilter(jwtTokenProvider), UsernamePasswordAuthenticationFilter.class)
                .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)

                // 예외 처리
                .and()
                .exceptionHandling()
                .authenticationEntryPoint(jwtAuthenticationEntryPoint) //customEntryPoint
                .accessDeniedHandler(jwtAccessDeniedHandler) // cutomAccessDeniedHandler

                .and()
                .authorizeRequests() // '인증'이 필요하다
                .antMatchers("/api/mypage/**").authenticated() // 마이페이지 인증 필요
                .antMatchers("/api/admin/**").hasRole("ADMIN") // 관리자 페이지
                .anyRequest().permitAll()

                .and()
                .headers()
                .frameOptions().sameOrigin();

        return http.build();
    }

    @Bean
    public AuthenticationManager authenticationManager(AuthenticationConfiguration authenticationConfiguration) throws Exception {
        return authenticationConfiguration.getAuthenticationManager();
    }

}

API별 권한 제어 방법

@EnableGlobalMethodSecurity(securedEnabled = true)로 사용할 수 있다. Controller에 @Secured("권한 이름") 어노테이션으로 설정이 가능하다.

@Secured("ROLE_ADMIN")
@GetMapping("/api/admin")
public ResponseEntity<String> adminTest() { {
    // ...
}

• UserDetailsImpl에 권한(Authority) 정보를 담아줄 수 있다.

  • 1개 이상 설정 가능

  • “권한 이름” 규칙

  • ROLE_로 시작해야 한다 (ex. ROLE_ADMIN, ROLE_USER)

    // 예시
    public class UserDetailsImpl implements UserDetails {
    
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        Collection<GrantedAuthority> authorities = new ArrayList<>();
        authorities.add(() -> user.getRole()); // key: ROLE_권한
        return authorities;
    }
    
    // ...
    }

CSRF(Cross Site Request Forgery)

사이트간 위조 요청으로, 정상적인 사용자가 의도하지 않은 위조 요청을 보내는 것을 의미한다. Spring Security는 CSRF protection 기능을 default로 설정한다. Spring Security는 이 기능을 사용해 GET 요청을 제외한, 상태를 변화시킬 수 있는 POST, PUT, DELETE 요청으로부터 CSRF를 보호한다. CSRF protection은 CSRF Token을 발급 후, 클라이언트로부터 요청을 받을 때마다 해당 요청을 검증하는 방식이다. HTML에 다음과 같은 CSRF Token이 포함되어야 요청을 받아들임으로써 위조 요청을 방지한다.

    <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>

Spring Security Documentation에서는 non-broswer client가 사용하는 서비스라면 CSRF를 disable하여도 좋다고 한다. 이 이유는 REST API를 이용한 서버라면, session 기반 인증과는 달리 stateless하기 때문에, 서버에 인증 정보를 보관하지 않는다. REST API라면 클라이언트는 권한이 필요한 요청을 하기 위해서 요청에 필요한 인증 정보를 OAuth2.0, JWT 토큰 등에 포함시켜야 한다. 따라서, 서버에 인증 정보를 저장하지 않기 때문에 불필요한 CSRF 코드를 작성할 필요가 없다. JWT 토큰을 사용할 것이기 때문에, http.csrf().disable()를 통해 Spring Security가 CSRF protection 기능을 사용하지 않게 했다.

Rest API 사용을 위한 설정

• httpBasic().disable(): Http basic Auth 기반의 로그인 인증 창. 비인증시 로그인폼 화면으로 리다이렉트한다. REST API 방식을 사용할 것이므로 사용하지 않는다.
• formLogin().disable() : 일반적인 로그인 방식, 즉 ID/Password 로그인 방식 사용을 의미한다. REST API 방식을 사용할 것이므로 사용하지 않는다.
• sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) : STATELESS로 세션 정책을 설정한다는 것은, 세션쿠키 방식의 인증 메커니즘 방식을 사용하지 않겠다는 것을 의미한다. 인증에 성공한 이후라도 클라이언트가 다시 어떤 자원에 접근을 시도할 경우, SecurityContextPersistenceFilter는 세션 존재 여부를 무시하고 항상 새로운 SecurityContext 객체를 생성하기 때문에 인증성공 당시 SecurityContext에 저장했던 Authentication 객체를 더 이상 참조 할 수 없게 된다.(참고)

예외 처리

.exceptionHandling()
.authenticationEntryPoint(jwtAuthenticationEntryPoint) //customEntryPoint
.accessDeniedHandler(jwtAccessDeniedHandler) // cutomAccessDeniedHandler

• authenticationEntryPoint: 401 에러 핸들링을 위한 설정
• accessDeniedHandler: 403 에러 핸들링을 위한 설정

리소스(URL)의 권한 설정

.authorizeRequests() // '인증'이 필요하다
.antMatchers("/api/mypage/**").authenticated() // 마이페이지 인증 필요
.antMatchers("/api/admin/**").hasRole("ADMIN") // 관리자 페이지
.anyRequest().permitAll()

우선 특정 리소스에 대해 권한을 설정할 수 있다.

• anyRequest(): 그 외 나머지 리소스들을 의미한다.
• authenticated(): 인증을 완료해야 접근을 허용한다.
• hasRole("권한"): 특정 레벨의 권한을 가진 사용자만 접근을 허용한다.(SecurityContext에 저장했던 Authentication 객체의 Authorities를 검사한다.)
• permitAll(): 인증 절차 없이 접근을 허용한다.

참고

Spring Security - Filter, FilterChain [Spring Security] Filter란? Spring Security의 구조(Architecture) 및 처리 과정 알아보기

JWT는 유저를 인증하고 식별하기 위한 토큰(Token) 기반 인증이다. 토큰 자체에 사용자의 권한 정보나 서비스를 사용하기 위한 정보가 포함된다. JWT를 사용하면 RESTful과 같은 무상태(Stateless)인 환경에서 사용자 데이터를 주고받을 수 있게 된다. 세션(Session)을 사용하게 될 경우에는 쿠키 등을 통해 사용자를 식별하고 서버에 세션을 저장했지만, JWT와 같은 토큰을 클라이언트에 저장하고 요청시 HTTP 헤더에 토큰을 첨부하는 것만으로도 단순하게 데이터를 요청하고 응답을 받아올 수 있다.

구조

JWT는 Header, Payload, Signature로 구성된다. 각 요소는 .으로 구분된다.

Header

JWT에서 사용할 타입(typ)과 해시 알고리즘(alg)의 종류가 담겨있다.

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

Payload

서버에서 첨부한 사용자 권한 정보와 데이터인 클레임(Claim) 담겨있다. 클레임은 Key/Value 형태로 된 값을 가진다. 저장되는 정보에 따라 Registered Claims, Public Claims, Private Cliams로 구분된다.

등록된 클레임(Registered Claims) iss: 토큰 발급자(issuer) sub: 토큰 제목(subject) aud: 토큰 대상자(audience) exp: 토큰 만료 시간(expiration) nbf: 토큰 활성 날짜(not before), 이 날이 지나기 전의 토큰은 활성화되지 않는다. iat: 토큰 발급 시간(issued at) jti: JWT 토큰 식별자(JWT ID), 중복 방지를 위해 사용하며, 일회용 토큰(Access Token) 등에 사용한다.

{
  "sub": "subject",
  "iss": "abc",
}

공개 클레임(Public Claims) 공개 클레임들은 충돌이 방지된 이름을 가지고 있어야한다. 주로 URI 형식으로 짓는다.

{
  "https://velog.io/jwt/public": true
}

비공개 클레임(Private Cliams) 클라이언트와 서버 협의하에 사용되는 클레임이다. 공개 클레임과는 달리 이름이 중복되어 충돌될 수 있기 때문에 유의해야 한다.

{
  "username": "kim"
}

Signature

Header, Payload를 Base64 URL-safe Encode 한 이후, Header에 명시된 해시함수를 적용하고, 개인키(Private key)로 서명한 전자서명이 담겨있다. 이는 Header, Payload가 변조되었는지 확인하기 위해 사용되는 중요 정보이며, JWT를 신뢰할 수 있는 토큰으로 사용할 수 있는 근거가 된다.

Base64 URL-safe Encode 웹으로 전송하기 위해 사용하는 문자가 Base64 형태의 문자이다. 일반적인 Base64 Encode 에서 URL 에서 오류없이 사용하도록 '+', '/' 를 각각 '-', '_' 로 표현한 것이다.

세션(Session)

사용자가 어떤 서버에 로그인을 하기 위해 ID를 입력했다고 가정했을 때, 서버는 입력받은 ID에 대한 "인증" 단계를 거치고, 서버 안의 세션 저장소에 해당 내용을 담은 세션을 저장한다. 이 저장된 것을 "세션ID"라고 한다.서버는 저장된 세션ID를 HTTP Response의 Cookie 값에 세팅해 사용자에게 보내게 된다. 이후에 사용자는 권한이 필요한 요청을 서버에 보낼 때 세션ID를 보내게 되고, 서버는 해당 세션ID가 세션 저장소에 있는지 확인하고 "인가"의 여부를 결정헌다. 예를 든다면, 서버가 세션을 사용할 때, 사용자는 로그인 상태를 유지하기 위해 세션ID를 쿠키 값으로 가지고 있어야 한다. 만약 로그인한 상태에서 쿠키 초기화를 하게 된다면, 로그인 상태를 유지하게 해주던 세션ID를 초기화한 것이 되기 떄문에 다시 로그인을 해야한다.

인증(Authentication): 접근자가 누구인지 확인하는 절차 인가(Authorization): 인증을 마친 접근자에게 권한을 허락하는 절차

세션의 문제점

이러한 세션 방식은 여러 대의 서버를 사용하게 될 때 문제가 발생한다. 세션 저장소는 로드 밸런싱을 했을 때 공유되지 않는다. 인가 절차를 거칠 때, 다른 서버로 접근하게 되면 인가가 불가능하게 된다. 즉, 1번 서버에서 발급된 세션ID를 가지고 2번 서버에서 인가 과정을 시도하는 것이 불가능하다. DB를 사용해서 해결이 가능하겠지만, 접근하는 것 자체에서 네트워크와 하드 디스크 IO 비용이 발생한다는 문제가 있다.

JWT와 세션의 차이점

JWT 토큰과 세션의 가장 큰 차이점은 "인가"에 대한 정보를 누가 담고 있냐이다. 세션은 서버의 세션 저장소에 해당 인증 내용을 담지만, JWT 토큰은 토큰 안에 인증 내용을 담고 있다. 사용자가 요청을 했을 때 토큰만 확인하면 되므로 세션 관리가 필요 없어진다. 따라서, JWT 토큰을 활용하면 각각 로드 밸런싱된 서버에 토큰 검증 클래스나 메소드만 있다면 인가 과정을 해결할 수 있다.

참고

https://pronist.dev/143 https://velog.io/@jjy5349/%EC%84%B8%EC%85%98%EA%B3%BC-JWT-%ED%86%A0%ED%81%B0-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0-2%ED%8E%B8 https://koonsland.tistory.com/57

기본적으로 HTTP 프로토콜 환경은 Connectionless, Stateless한 특성을 가지기 때문에, 서버는 클라이언트가 누구인지 매번 확인해야 한다.

• Connectionless: 클라이언트가 요청을 한 후 응답을 받으면 연결을 끊어버린다.
• Stateless: 통신이 끝나면 상태 정보를 유지하지 않는다.

세션과 쿠키는 이러한 특성을 해결하기 위해 사용된다. 만약 세션과 쿠키를 사용하지 않는다면, 사용자는 페이지를 이동할 때마다 로그인을 다시 해야 한다.

쿠키(Cookie)

쿠키는 클라이언트의 로컬에 저장되는 Key/Value 형태를 가진 작은 데이터이다. 클라이언트에 300개의 쿠키를 저장할 수 있으며, 하나의 도메인당 20개의 값만 가질 수 있다. 하나의 쿠키 값은 4KB까지 저장한다. 클라이언트가 요청을 보내면, 서버에서 쿠키를 생성해 HTTP Header에 쿠키를 포함해 응답한다. 브라우저가 종료되어도 쿠키의 만료 기간이 남아있다면 클라이언트에서 보관하고 있다. 클라이언트가 같은 요청을 보내게 될 경우 HTTP Header에 쿠키를 함께 보낸다. 서버에서 이전 상태 정보를 변경할 필요가 있을 때 쿠키를 업데이트하고, 변경된 쿠키를 HTTP Header에 포함해 응답을 보낸다.

세션(Session)

클라이언트가 서버에 접속하게 되면, 서버는 클라이언트를 구분하기 위해 고유한 세션ID를 부여하고, 이 세션ID를 서버 측에 저장한다. 클라이언트는 쿠키를 사용해 세션ID 데이터를 가지고 있고, 서버에 요청을 보낼 때 해당 데이터를 같이 서버에 전달한다. 서버는 전달받은 세션ID를 이용해 클라이언트 정보를 가져와 적절한 응답을 보낼 수 있게 된다. 또, 클라이언트가 서버에 접속해 브라우저를 종료할 때까지 인증 상태를 유지할 수 있다. 세션이 쿠키보다 보안면에서 우수하지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.

쿠키와 세션의 차이

참고

https://interconnection.tistory.com/74 https://devuna.tistory.com/23

ControllerAdvice

• Spring은 전역적으로 ExceptionHandler를 적용할 수 있는 @ControllerAdvice와 @RestControllerAdvice 어노테이션을 제공하고 있다.

• @ControllerAdivce는 여러 컨트롤러에 대해 전역적으로 ExceptionHandler를 적용해준다. 다음과 같이 에러를 핸들링하는 클래스를 만들어 어노테이션을 붙여주면 에러 처리를 위임할 수 있다.

  • 만약 특정 클래스에만 제한적으로 적용하고 싶다면, @RestControllerAdvice의 basePackages 등을 설정함으로써 제한할 수 있다

• @RestControllerAdvice는 @ControllerAdvice와 달리 @ResponseBody가 붙어 있어 응답을 Json으로 내려준다.

  ResponseEntityExceptionHandler 추상 클래스

• Spring은 스프링 예외를 미리 처리해둔 ResponseEntityExceptionHandler를 추상 클래스로 제공하고 있다.

• ResponseEntityExceptionHandler에는 스프링 예외에 대한 ExceptionHandler가 모두 구현되어 있으므로 @ControllerAdvice 클래스가 이를 상속받게 하면 된다.

• 이 추상 클래스를 상속받지 않는다면 스프링 예외들은 DefaultHandlerExceptionResolver가 처리하게 되는데, 그러면 예외 처리기가 달라지므로 클라이언트가 일관되지 못한 에러 응답을 받지 못하므로 ResponseEntityExceptionHandler를 상속시키는 것이 좋다.

• 또한 이는 기본적으로 에러 메세지를 반환하지 않으므로, 스프링 예외에 대한 에러 응답을 보내려면 handleExceptionInternal 메소드를 오버라이딩 해야 한다.

  적용 예시

  @RestControllerAdvice // 전역 예외 처리
  public class GlobalExceptionHandler extends ResponseEntityExceptionHandler { // 추상 클래스 상속
  
    // NotFoundAccountException 발생시 에러 처리
    @ExceptionHandler(NotFoundAccountException.class)
    public ResponseEntity<?> handleNotFoundEntity(NotFoundException e) {
        return handleExceptionInternal(e.getExceptionCode());
    }
  }

handleExceptionInternal 메소드

ResponseEntityExceptionHandler의 handleExceptionInternal() 메소드를 오버라이딩하여 응답을 커스터마이징할 수 있다.

ControllerAdvice를 사용함으로써 얻을 수 있는 이점

• 하나의 클래스로 모든 컨트롤러에 대해 전역적으로 예외 처리가 가능하다.
• 직접 정의한 에러 응답을 일관성 있게 클라이언트에게 내려줄 수 있다.
• 별도의 try-catch문이 없어 코드의 가독성이 높아진다.

ControllerAdvice 사용시 주의해야 할 점

• 한 프로젝트당 하나의 ControllerAdivce만 관리하는 것이 좋다.
• 만약 여러 ControllerAdvice가 필요하다면 basePackages나 annotations 등을 지정해야 한다.
• 직접 구현한 Exception 클래스들은 한 공간에서 관리한다.

예외 처리 흐름

1. ExceptionHandlerExceptionResolver: 에러 응답을 위한 Controller나 ControllerAdvice에 있는 ExceptionHandler를 처리함

   1. 예외가 발생한 컨트롤러 안에 적합한 @ExceptionHandler가 있는지 검사한다.
   2. 컨트롤러의 @ExceptionHandler에서 처리가 가능하다면 처리하고, 그렇지 않으면 ControllerAdivce로 넘어간다.
   3. ControllerAdvice 안에 적합한 @ExceptionHandler가 있는지 검사하고, 없으면 다음 처리기로 넘어간다.

2. ResponseStatusExceptionResolver: Http 상태 코드를 지정하는 @ResponseStatus 또는 ResponseStatusException를 처리함

   1. @ResponseStatus가 있는지 또는 ResponseStatusException인지 검사한다.
   2. 맞으면 ServletResponse의 sendError()로 예외를 서블릿까지 전달하고, 서블릿이 BasicErrorController로 요청을 전달한다.

3. DefaultHandlerExceptionResolver:  스프링 내부의 기본 예외들을 처리한다.

   1. Spring의 내부 예외인지 검사하여, 맞으면 에러를 처리하고 아니면 넘어간다.

4. 적합한 ExceptionResolver가 없으므로 예외가 서블릿까지 전달되고, 서블릿은 SpringBoot가 진행한 자동 설정에 맞게 BasicErrorController로 요청을 다시 전달한다.

@RestControllerAdvice 적용

• View를 사용하지 않고 Rest API로만 사용하기 때문에 @RestControllerAdvice를 사용하겠다.

  예외 케이스 관리

• 클라이언트에게 보내줄 에러 코드를 한 곳에서 관리할 수 있다.

• 에러 이름과 HTTP 상태 및 메세지를 가지고 있는 Enum Class이다.

  @Getter
  @RequiredArgsConstructor
  public enum ErrorCode {
  
    /*
     * 400 BAD_REQUEST: 잘못된 요청
     */
    BAD_REQUEST(HttpStatus.BAD_REQUEST, "Invalid request."),
  
    /*
     * 401 UNAUTHORIZED: 인증되지 않은 사용자의 요청
     */
    UNAUTHORIZED_REQUEST(HttpStatus.UNAUTHORIZED, "Unauthorized."),
  
    /*
     * 403 FORBIDDEN: 권한이 없는 사용자의 요청
     */
    FORBIDDEN_ACCESS(HttpStatus.FORBIDDEN, "Forbidden."),
  
    /*
     * 404 NOT_FOUND: 리소스를 찾을 수 없음
     */
    NOT_FOUND(HttpStatus.NOT_FOUND, "Not found."),
  
    /*
     * 405 METHOD_NOT_ALLOWED: 허용되지 않은 Request Method 호출
     */
    METHOD_NOT_ALLOWED(HttpStatus.METHOD_NOT_ALLOWED, "Not allowed method."),
  
    /*
     * 500 INTERNAL_SERVER_ERROR: 내부 서버 오류
     */
    INTERNAL_SERVER_ERROR(HttpStatus.INTERNAL_SERVER_ERROR, "Server error.");
  
  

private final HttpStatus httpStatus;
private final String message;

}

### 에러 응답 형식 지정
- 실제 사용자에게 JSON 형식으로 보여주기 위한 에러 응답 형식을 지정한다.
``` java
@Getter
public class ErrorResponse {
    private final LocalDateTime timestamp = LocalDateTime.now();
    private final int statusCode;
    private final String error;
    private final String message;

    public ErrorResponse(ErrorCode errorCode) {
        this.statusCode = errorCode.getHttpStatus().value();
        this.error = errorCode.getHttpStatus().name();
        this.message = errorCode.getMessage();
    }
}

에러 코드 정의

• 발생한 예외를 처리해줄 에러 클래스(Exception Class)를 추가한다.

• RuntimeException을 상속받아 언체크 예외로 활용한다.

  @Getter
  @RequiredArgsConstructor
  public class RestApiException extends RuntimeException {
    private final ErrorCode errorCode;
  }

  전역 예외 처리

• @ExceptionHandler: 발생한 특정 예외를 잡아 하나의 메소드에서 공통 처리할 수 있게 한다.

• @RestControllerAdvice: 프로젝트 전역에서 발생하는 모든 예외를 잡아준다.

• 모든 예외를 잡은 후에, Exception 종류별로 메소드를 공통 처리할 수 있다.

  @RestControllerAdvice
  public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {
  
    /*
     * Developer Custom Exception: 직접 정의한 RestApiException 에러 클래스에 대한 예외 처리
     */
    @ExceptionHandler(RestApiException.class)
    protected ResponseEntity<ErrorResponse> handleCustomException(RestApiException ex) {
        ErrorCode errorCode = ex.getErrorCode();
        return handleExceptionInternal(errorCode);
    };
  
    // handleExceptionInternal() 메소드를 오버라이딩해 응답 커스터마이징
    private ResponseEntity<ErrorResponse> handleExceptionInternal(ErrorCode errorCode) {
        return ResponseEntity
                .status(errorCode.getHttpStatus().value())
                .body(new ErrorResponse(errorCode));
    }
  }

  테스트

  Controller에서 무조건 BAD_REQUSEST 응답을 내리는 코드를 작성해보았다.

  @RestController
  @RequestMapping("/api")
  public class NaverLoginApiController {
    @GetMapping("/test")
    public ResponseEntity<?> test() {
        throw new RestApiException(ErrorCode.BAD_REQUEST);
    }
  }

  Postman에서 GET "http://localhost:8080/api/test" 실행,

참고

https://mangkyu.tistory.com/204 https://bcp0109.tistory.com/303 https://velog.io/@evelyn82ny/Exception-handling-using-RestControllerAdvice

에러(Error)

• 메모리가 부족하는 등과 같이 시스템이 비정상적인 상황인 경우에 사용
• 주로 JVM에서 발생시키기 때문에 애플리케이션 코드에서 잡아서는 안되며, 잡아서 대응할 수 있는 방법도 없다.
• 시스템 레벨에서 특별한 작업을 하는게 아니라면, 이러한 에러 처리는 하지 않아도 된다.

예외(Exception)

• Error와 달리 애플리케이션 코드에서 예외가 발생하였을 경우에 사용된다.
• Exception은 다시 체크 예외(Check Exception)와 언체크 예외(Uncheck Exception)로 구분된다.
• 스프링 프레임워크가 제공하는 선언적 트랜잭션(@Transactional)안에서 에러 발생 시, 체크 예외는 롤백(Rollback)이 되지 않고, 언체크 예외는 롤백이 된다.

체크 예외(Check Exception)

• RuntimeException 클래스를 상속받지 않은 예외 클래스들이다.
• 체크 예외는 복구 가능성이 있는 예외이기 때문에, 반드시 예외를 처리하는 코드를 함께 작성해야 한다.
  • try catch :해당 메소드에서 처리
  • throw: 호출한 곳에서 처리하도록 상위로 넘김
• 대표적으로 IOException, SQLException, ClassNotFoundException 등이 있으며, 예외를 처리하기 위해서는 catch 문으로 잡거나 throws를 통해 메소드 밖으로 던질 수 있다. 만약 예외를 처리하지 않으면 컴파일 에러가 발생한다.

언체크 예외(Uncheck Exception)

• RuntimeException 클래스를 상속받는 예외 클래스들은 복구 가능성이 없는 예외들이므로 컴파일러가 예외처리를 강제하지 않는다. 그래서  언체크 예외라고 불리는데, 언체크 예외는 Error와 마찬가지로 에러를 처리하지 않아도 컴파일 에러가 발생하지 않는다.
• 즉, 런타임 예외는 예상치 못했던 상황에서 발생하는 것이 아니므로 굳이 예외 처리를 강제하지 않는다.
• RuntimeException에는 대표적 NullPointerException이나 IllegalArgumentException 등과 같은 것들이 있다. 

예외 처리 방법

예외 복구

• 예외 상황을 파악하고, 문제를 해결해서 정상 상태로 돌려놓는 것이다.

예외 처리 회피

• 예외 처리를 직접 처리하지 않고, 자신을 호출한 곳으로 던져버리는 것이다.
• 해당 예외를 처리하는 것이 자신이 해야될 일이 아니라고 느껴진다면, 다른 메소드에서 처리하도록 넘겨줄 때 사용한다.

예외 전환

• 예외 처리 회피와 마찬가지로, 예외를 복구할 수 없는 상황에 사용된다.
• 예외 처리 회피와 다르게, 적절한 예외로 변환하여 던진다.
• 목적
  • 의미 있고 추상화된 예외로 바꾸는 경우
    • 중복되는 ID로 회원 가입을 요청한 경우, SQLException이 발생한다. 이 에러를 그대로 던지면, 서비스 계층에서는 왜 예외가 발생한건지 파악하기 힘들기 때문에, DuplicatedUserIdException과 같은 예외로 바꿔서 던져 상황에 따른 복구 작업을 시도할 수 있게 한다.
  • 런타임 예외로 포장하여(언체크 예외로 변경하여) 불필요한 처리를 줄여주는 경우
    • 복구하지 못할 예외라면 불필요하게 체크할 필요가 없기 때문에, 애플리케이션 로직 상에서 런타임 예외로 포장하여 던지고, 자세한 로그를 남기거나 알림을 주는 등의 방식으로 처리한다.

참고

http://plus4070.github.io/nhn%20entertainment%20devdays/2017/01/22/Exception/ https://mangkyu.tistory.com/152