처음 구현해보는 access, refresh token 발급 로직(Spring)

https://github.com/versatile0010/Couphone-Server

|| Couphone, 쿠폰을 폰 안에!

백엔드 개발자가 되기로 마음먹은 뒤로

 

처음으로 참여한 프로젝트이다.

 

나는 Spring 경험이 아주 적었고

 

본 프로젝트 기간이 1개월 반 정도로 짧았기 때문에

 

전체적인 완성도가 많이 떨어지는 것 같아 많이 아쉬웠다.

 

처음으로 프로젝트에 참여하다 보니 모든 부분에서 상당히 막막한 감정을 느낄 수 밖에 없었는데,

 

운이 좋게도 이것저것 직접 구현해볼 수 있게 되어서

 

개인적으로는 얻어가는 점이 꽤 많았다고 생각한다.

 

여튼,

 

처음으로 프로젝트에 참여하며 느꼈던 막막함과 해결 과정을 되새기며

 

" 처음으로 구현해보는 " 이라는 시리즈로 블로그에 삽질한 기록을 남겨볼 생각이다. 

 

 첫 번째 주제는 처음으로 구현해보는 access token, refresh token 발급 로직이다.

 

( 대략 7 개 정도의 주제를 계획하고 있다. )

---

 

1. 세션 기반 인증 방식이란?

이전에 스터디에서 인증/인가에 대해서 공부해보았다.

 

인증 방식에는 크게 2 가지가 존재한다.

 

백엔드에서는 세션 기반의 인증 시스템을 구축할 수도 있고, 토큰 기반의 인증 시스템을 구축할 수도 있겠다.

 

 

세션 기반의 인증 방식은 사용자의 정보를 서버의 세션 저장소에 저장하는 것이다.

 

사용자가 로그인을 하면, 관련 인증 정보를 세션 저장소에 저장하고

 

사용자에게 Session ID 를 발급한다. 

 

Session ID 는 브라우저에 쿠키 형태로 저장되어 관리된다.

 

브라우저에서는 인증 절차를 마친 매 요청마다 HTTP cookie 헤더에 Session ID 를 포함하여 서버에 전송한다.

 

서버는 전달받은 Session ID 에 해당하는 세션 정보가 세션 저장소에 존재한다면 해당 사용자가 인증되었다고 판단한다.

 

이러한 세션 기반의 시스템은 클라이언트로부터의 정보를 기억하기 위해 세션을 계속 유지해야 한다. (Stateful 하다.)

 

이러한 특징은 서버를 확장하는 데에 있어 불리하다.

 

또한 서버에서 클라이언트 인증 정보를 모두 저장하고 있으려면 클라이언트 수가 늘어남에 따라

 

정보를 어디에 어떻게 저장해야 할 지에 대한 추가적인 논의가 발생하게 될 것이다.

 

추가적으로 중간에 제 3 자에 의해 session id 가 탈취되면, 

 

인증된 클라이언트가 아님에도 그런 것 처럼 서버에 접근할 수 있다는 것 또한 문제점이 된다.

 

이러한 단점을 극복하기 위해 토큰 기반의 인증 방식이 널리 사용되고 있다.

---

2. 토큰기반 인증

토큰 기반 인증 방식은 인증 정보를 클라이언트 토큰의 형태로 가지고 있는다. 

 

 

대표적으로 사용되는 토큰은 JWT 인데,

 

사용자가 가지고 있는 토큰을 HTTP 의 Authorization 헤더에 포함시켜 보내면

 

서버 측에서는 해당 토큰이 유효한지, 그리고 만료되지 않았는지를 확인한 뒤

 

토큰에 암호화되어 담겨져 있는 사용자 인증 정보를 확인하여 인증/인가를 수행한다.

 

JWT 의 형태는 아래와 같으며 필요에 따라 커스터마이징 할 수 있다.

 

https://jwt.io/

 

세션 기반 방식에서는 session id 만 넘기면 되었다면

 

토큰 기반 방식에서는 위와 같이 긴 문자열을 넘겨야 하므로

 

더 많은 네트워크 트래픽을 사용한다.

 

토큰이 탈취되면 사용자 정보가 노출될 우려 또한 존재한다. (이는 refresh token 을 도입하며 개선 가능)

 

그럼에도 토큰 기반 인증 방식이 현재 대세 인 이유는 바로 확장성 때문이라고 할 수 있다.

 

대용량 데이터를 처리하기 위해서 단일 서버의 성능을 높이는 데에는 한계가 있기 때문에 서버의 개수를 늘리는 방향(Scale out)으로 튜닝하는데,

 

토큰 기반 인증 방식은 세션 기반의 인증 방식과 달리 인증 정보가 토큰에 저장되므로 Scale out 에 유리하다.

 

세션 기반의 인증 방식은 서버 내부의 세션 저장소에 인증 정보를 저장했었는데, Scale out 됨에 따라 서버가 늘어나면 세션 정보를 어떻게 관리할 지에 대한 큰 번거로움이 존재한다.

 

---

3. JWT

 

Header

-  JWT 헤더에는 토큰의 타입과 해싱 알고리즘 방식이 저장된다.

 

PayLoad

-  PayLoad 에서는 토큰에서 사용할 정보 조각인 Claim 이 담겨져있다.

-  기본적으로 sub(토큰 제목), exp(만료 시간), iat(발급 시간) 등이 담겨져 있다.

-  필요하다면 추가적인 정보를 Claim 에 넣어둘 수 있으나,  토큰의 길이가 길어짐에 따라 네트워크 부하가 증가하기 마련이므로 불필요한 정보를 최대한 지양하는 것이 좋다.

 

Signature 

-  Signature 에는 토큰 인코딩/유효성 검증 시 사용하는 고유한 암호화 코드가 담겨져 있으며,

-  손상되면 유효하지 않은 토큰으로 판단한다.

 

---

4. Access Token, Refresh Token 

토큰 역시 탈취되면 인증/인가되지 않은 제 3자로부터 서버 리소스가 노출될 수 있는 위험성이 존재한다.

 

이를 최대한 예방하기 위해 토큰의 종류를 2 가지로 구분하여 생성하는 방법이 있다.

 

Access token

- 유효기간이 매우 짧은 토큰(30분 이하)으로 로그인 시 서버에서 클라이언트으로 반환한다.

 

Refresh token

- 유효기간이 긴 토큰(7일 정도)으로 클라이언트로 반환하지 않고, 서버 내부 DB 에서 관리한다.  

 

토큰 탈취의 위험은 서버 - 클라이언트 간 통신 과정에서 존재하는데,

 

클라이언트로 응답하는 Access token 의 만료기간을 매우 짧게 설정함으로써

 

탈취되더라도 위험성이 적도록 하는 방법이다.

 

본 프로젝트에서도 Access token , Refresh token 방식으로 인증/인가 시스템을 구축하였다.

 

인증 관련하여 전체적인 Flow 는 아래 아키텍쳐에서 처럼 상당히 복잡하다.

 

사실 이번 프로젝트에서도 전체적인 내용 전체를 이해하지는 못하고 구현하긴 했었다..

 

아래 구조는 조만간 스프링 시큐리티를 공부하며 새로운 포스팅에서 정리해보고자 한다..!

 

본 프로젝트에서 구현한 간단한 내용만 소개해보도록 하겠다.

 

먼저, 사용자 Login 요청이 들어오면

신규 회원이면 회원 가입 처리하고, 기존 회원이면 로그인을 수행한다.

 

해당 API 는 Token 검증을 하지 않는다. 

 

signin 이 호출되면 UsernamePasswordAuthenticationToken 을 발급받는다.

 

( 보통 email 과 password 를 사용하지만, 본 프로젝트에서 password 를 사용자로부터 입력받지 않음에 따라 email 과 name 을 사용하게 되었다. )

 

그리고 AuthenticationToken 을 AuthenticationManager 에게 전달하여 인증 정보를 만든다.

 

곧이어 SecurityContextHolder  에 사용자의 인증 정보를 저장한다.

 

이후 JwtProvider 에 사전에 구현해둔 generateAccessToken, generateRefreshToken 메서드에 인증 정보를 넘겨주어

 

accessToken 과 refreshToken 을 생성한다.

 

refresh token 은 DB 에 저장하고,

 

accessToken 은 사용자에게 반환한다.

 

---

중요한 것은 아래 코드이다.

 

로그인을 제외한 모든 Http 요청은 TokenAuthenticationFilter 에 전달되도록 구현하였다.

 

해당 필터에서는 access token / refresh token 관련 로직을 수행하고

 

필요 시 재발급 등을 수행한다.

 

@Slf4j
@RequiredArgsConstructor
public class TokenAuthenticationFilter extends OncePerRequestFilter {
    private final JwtTokenProvider jwtProvider;
    private final RefreshTokenService tokenService;
    private final static String HEADER_AUTHORIZATION = "Authorization";
    private final static String TOKEN_PREFIX = "Bearer ";

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        if (permitAllUrl.of(request.getRequestURI())) {
            filterChain.doFilter(request, response);
            return;
        }
        String accessToken = resolveToken(request, HEADER_AUTHORIZATION); // 1. 사용자가 보낸 토큰을 확인

        if (StringUtils.hasText(accessToken) && jwtProvider.validateToke(accessToken) == JwtCode.ACCESS) {
            // Access token 이 유효하면
            Authentication authentication = jwtProvider.getAuthentication(accessToken);
            SecurityContextHolder.getContext().setAuthentication(authentication); // security context 에 인증 정보 저장
            log.info("Access Token 은 아직 유효합니다.");
        } else if (StringUtils.hasText(accessToken) && jwtProvider.validateToke(accessToken) == JwtCode.EXPIRED) {
            // 2-1. Access token 이 만료되었다면
            log.info("Authorization 필드에 담겨진 Access Token 이 Expired 되었습니다!");
            String refreshToken = null;

            // 2-2. jwt token 으로부터 userId 를 찾고, 해당 userId 에 대한 refreshToken 을 탐색
            Long userId = jwtProvider.getUserIdFromExpiredToken(accessToken);
            log.warn(userId.toString());
            refreshToken = jwtProvider.getRefreshToken(userId);

            // refresh token 이 존재하고 유효하다면
            if (StringUtils.hasText(refreshToken) && jwtProvider.validateToke(refreshToken) == JwtCode.ACCESS) {
                // access token 재발급
                log.info("해당 회원 ID 에 대한 Refresh token 이 존재하고 유효합니다.");
                log.info("Access token 을 재발급하여 반환합니다.");

                Authentication authentication = jwtProvider.getAuthentication(refreshToken);

                String newAccessToken = jwtProvider.generateAccessToken(authentication);
                SecurityContextHolder.getContext().setAuthentication(authentication);

                response.setHeader(HttpHeaders.AUTHORIZATION, newAccessToken);
            } else if (StringUtils.hasText(refreshToken) && jwtProvider.validateToke(refreshToken) == JwtCode.EXPIRED) {
                // refresh token 이 존재하지만 만료되었다면
                log.warn("해당 회원 ID 에 대한 Refresh token 이 존재하지만, 만료되었습니다.");
                throw new JwtExpiredTokenException(EXPIRED_TOKEN);
            }
            if (refreshToken == null) {
                // refresh token 이 존재하지 않으면
                log.warn("해당 회원 ID 에 대한 Refresh token 이 존재하지 않습니다.");
                throw new JwtNoTokenException(TOKEN_NOT_FOUND);
            }
        }
        filterChain.doFilter(request, response);
    }

    public String resolveToken(HttpServletRequest request, String header) {
        String bearerToken = request.getHeader(header);
        if (StringUtils.hasText(bearerToken) && bearerToken.startsWith(TOKEN_PREFIX)) {
            return bearerToken.substring(TOKEN_PREFIX.length());
        }
        return null;
    }
}

https://github.com/KUIT-Couphone/Couphone-Server/pull/18

feat: JWT Authentication 로직 개선 및 예외처리 보완 by versatile0010 · Pull Request #18 · KUIT-Couphone/Couphone-Se

token 검증이 필요하지 않는 path (e.g. /auth/login ) 에 대해서는 token 유효성을 검사하지 않고 넘어간다.

 

access token 이 유효하면 (유효하지 않으면 InvalidTokenException)

 

인증 정보를 저장한다. (끝)

 

access token 이 유효하지만 만료되었다면

 

-  3.1 jwt에서 userId 를 꺼낸다.
-  3.2 해당 userId 에 대한 refresh token 이 유효하면 access token 을 재발급하고 Authorization header 에 담아서 반환한다.
-  3.3 해당 userId 에 대한 refresh token 이 존재하지 않으면 JwtNoTokenException
-  3.4 해당 userId 에 대한 refresh token 이 존재하지만 만료되었다면 JwtExpiredTokenException

 

 

---

 

 

References

1. https://do5do.tistory.com/14

[Spring] Spring Security + JWT

2. https://goldenrabbit.co.kr/product/springboot3java/

[되기] 스프링 부트 3 백엔드 개발자 되기(자바 편) - 골든래빗

3. https://product.kyobobook.co.kr/detail/S000001019679

스프링 부트와 AWS로 혼자 구현하는 웹 서비스 | 이동욱 - 교보문고

4. https://mangkyu.tistory.com/57

[SpringBoot] SpringBoot로 SpringSecurity 기반의 JWT 토큰 구현하기