[Spring] Spring Security + OAuth2.0 + JWT Token을 활용한 소셜로그인 총정리 - (1) 배경 지식 이해하기, 전체 그림 살펴보기

 

 

 

 

 

🙋🏻 서론

NEO 토이 프로젝트를 진행하면서 소셜 로그인 기능을 구현하게 되었습니다.

인터넷 상의 많은 글을 읽고, 도움을 많이 받았으나 정보가 한데 모여있지 않고 본인이 개인적으로 이해가 되지 않는 부분이 많아 나중에 다시 구현할 경우를 대비해 글로 작성하기로 마음을 먹었습니다.

 

부족한 내용이 있을 수 있지만 더 좋은 내용이 있다면 댓글로 달아주시면 감사하겠습니다.

좋은 피드백은 언제나 환영이며, 제 글이 소셜로그인을 구현하려는 누군가에게 좋은 도움이 되었으면 합니다.

 

글의 진행은 다음과 같은 순서로 이어질 예정입니다.

1. 배경지식 이해하기, 전체 그림 살펴보기 (OAuth2, JWT Token, 프로젝트 전체 도식화)
2. Naver, Kakao, Google에 프로젝트를 OAuth2 Client로 설정하기
3. Spring OAuth2.0 Client를 활용한 OAuth2.0 클라이언트 백엔드 구현
4. Redis와 JWT 토큰을 사용한 우리 서비스에 대한 인증과 인가와 구현
5. OAuth2.0과 테스트 코드, Spring REST Docs 작성

 

 

💜 NEO 프로젝트에 대한 간단한 설명

소셜 로그인 적용과 인증 및 인가 적용 방식은 프로젝트 별로 천차만별입니다. 따라서 앞으로의 내용에 있어서 차이가 있을 수 있기에, 우리 프로젝트에 대해 간단히 설명하고 비슷한 상황이라면 제가 적용한 내용을 참고로 여겨주시면 감사하겠습니다.

- NEO는 웹이 아닌, iOS 애플리케이션입니다.
- 백엔드를 별도로 두고 있으며, 백엔드를 통해 OAuth2 사용자 인증을 받습니다 (백엔드가 OAuth2.0 Client)
- OAuth2 사용자 인증을 통해 사용자 정보를 얻고 1차 회원가입을 진행합니다
- 추후에 사용자 추가 정보를 입력 받아 1차 회원가입된 사용자에 대해 정보를 추가 업데이트 할 수 있도록 설계합니다.
- 로그인 된 사용자에게 OAuth2 AccessToken을 직접 주지 않고, 백엔드에서 자체적으로 발급하는 JWT Token을 지급합니다.
- JWT Token은 Access Token과 Refresh Token으로 제공됩니다.

 

 

🏝 프로젝트 환경

NEO에서 사용된 dependency입니다. 환경에 있어서 주의할 점은 크게 두 가지입니다.

- NEO에서 사용한 JWT 라이브러리는, auth0:java-jwt 라이브러리와 io:jsonwebtoken:jjwt 라이브러리 중 auth0:java-jwt를 선택

- Spring Security 6.1.2 버전이기 때문에, 인터넷 상의 대다수의 자료(구버전)에 비해 Security Config 파트에서 다른 코드가 존재합니다. (비교적 최신버전이기 때문에 이전에 사용되던 method가 대부분 deprecated, 함수형 프로그래밍에 맞는 메소드로 대부분 바뀜.)

- Java 17
- SpringBoot 3.1.2
- 'com.auth0:java-jwt:4.2.1'
- 'spring-boot-starter-data-redis:3.1.2'
- 'spring-boot-starter-security:3.1.2' (spring-security-web, spring-security-config:6.1.2)
- 'spring-boot-starter-oauth2-client:3.1.2' (spring-security-oauth2-client, oauth2-jose:6.1.2)

 

 

😎 OAuth2.0

✅ OAuth2.0이란?

 

'OAuth(Open Authorization)'는 인터넷 사용자들이 비밀번호를 제공하지 않고, 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는, 접근 위임을 위한 개방형 표준을 의미합니다.

 

사용자의 아이디와 비밀번호 없이 접근 권한을 위임받을 수 있다는 것은, 로그인 및 개인정보 관리 책임을 'Third-Party Application(google, kakao, naver 등)'에 위임할 수 있다는 것으로, 로그인 및 개인정보 관리에 대한 책임을 위임하는 것뿐만 아니라, 부여받은 접근 권한을 통해 서드파티 프로바이더가 가지고 있는 사용자의 리소스 조회 등의 기능을 수행할 수 있습니다.

 

흔히 우리에게는 '소셜 로그인'으로 잘 알려져 있습니다. 예를 들어 '번개장터' 애플리케이션에서는,

 

위와 같이 '번개장터'의 독자적인 폼 로그인을 진행하지 않더라도, '카카오, 페이스북, 네이버'와 같은 서드파티 프로바이더들에게 인증 과정을 위임하고, 사용자를 식별해냅니다. 

 

그 중, OAuth2라고 불리우는 이유는 당연히도 이전 버전이 존재하기 때문에 '2'라는 명칭이 붙었겠죠? 2010년 IETF에서 'OAuth 1.0' 공식 표준안이 RFC 5849로 발표되었으며, OAuth의 세션 고정 공격을 보완한 'OAuth 1.0a'를 거쳐, 현재는 OAuth의 구조적인 문제점을 해결하고, 핵심 요소만을 차용한 유사 프로토콜 WRAP(Web Resource Access Protocol)을 기반으로 발표한 'OAuth 2.0(RFC 6749, RFC 6750)'가 많이 사용되고 있습니다.

 

따라서 우리는 이러한 OAuth2.0을 통해 서드 파티 프로바이더에게 인증과 인가를 위임함으로써, 클라이언트(OAuth2 Client)에 접근 토큰(OAuth2 Access Token)을 발급하는 것에 대한 구조로 이해할 수 있습니다.

 

 

✅ OAuth2.0에서 사용하는 단어 정리

OAuth2.0에서 사용되는 단어들에 대해 정리를 해보았습니다. 

단어	설명	추가 설명
Resource Owner	리소스 소유자, 쉽게 표현하면 특정 서드파티 애플리케이션의 회원이면서, 우리의 서비스를 이용하고자 하는 사용자를 의미합니다.	서드파티 프로바이더의 보호된 자원에 접근할 수 있는 자격을 부여해 주는 주체이며, OAuth2 프로토콜 흐름에서는 Client를 인증하는 역할을 수행합니다. 해당 인증이 완료되면 권한 서버를 거쳐 권한 획득 자격을 Client에게 부여하게 됩니다.
Client	클라이언트, OAuth2와 연관된 서버(Authorization Server, Resource Server)에 대한 접근을 요청하는 서비스를 의미합니다.	'클라이언트'라는 이름 때문에 혼동이 있을 수 있지만, OAuth2 Server에 요청을 보내는 주체가 OAuth2 Client가 되므로, 해당 프로젝트에서는 NEO 백엔드 서버가 Client에 해당합니다.
Provider, Server	프로바이더, OAuth2 서버(Authorization + Resource)를 구현함으로써 OAuth2 서비스를 제공하는 서드파티 제공자를 의미합니다.	대표적으로 naver, kakao, google, facebook, github, okta 등이 있습니다.
Authorization Server	권한 서버, Resource Owner를 인증하며 Client에게 Access Token을 발급해줍니다.	구성에 따라 Authorization Server와 Resource Server는 아키텍쳐 변동 가능
Resource Server	자원 서버, 사용자의 보호된 자원을 소지하고 있는 서버로 권한 서버에서 우선 Access Token을 받아야 접근이 가능합니다.	구성에 따라 Authorization Server와 Resource Server는 아키텍쳐 변동 가능
Authorization Grant	권한 획득 자격, Resource Server에 접근 가능한 AccessToken을 발급 받기 이전에 발급 받는 권한 승인 코드입니다.	자세한 설명은 아래 "OAuth2.0 Authorization Code Grant 방식"
Access Token	접근 토큰, 해당 접근 토큰을 통해 Resource Server로부터 Resource Owner의 정보를 획득할 수 있습니다.	NEO에서 별도로 발급하는 JWT Access Token이 존재하므로, 두 개념을 분리하기 위해 글에서는 'OAuth2 Access Token'으로 부르도록 하겠습니다.

 

 

 

✅ OAuth2.0 Authorization Code Grant 방식

 

https://wildeveloperetrain.tistory.com/247

 

Authorization Code Grant 방식은 OAuth2.0에서 가장 보편적으로 사용되는 인증 방식입니다.

위의 인증 방식 도식화 그림을 살펴보면, 총 프로세스는 다음과 같습니다.

 

🙋🏻 Authorization Code Grant Process

1. OAuth2.0 Client(NEO 백엔드)가 Authorization Server에 접근 권한을 요청(API 요청)합니다.
1-1. 요청 시 발급한 client_id, redirect_url, response_type=code를 쿼리 파라미터로 포함한 요청을 보냅니다.
1-2. 프로바이더가 제공하는 자체 로그인 폼 팝업을 출력하게 됩니다. (ex. 카카오 로그인 폼, 네이버 로그인 폼 등.)

2. Resource Owner가 프로바이더가 띄운 로그인 폼을 통해 로그인을 시도합니다.
2-1. Authorization Server는 권한 부여 코드 요청 시 전달받은 redirect_uri로 Authorization Code(권한 부여 승인 코드)를 전달합니다.
2-2. 권한 부여 승인 코드를 통해 사용자 인증 및 자원서버에 접근할 때 필요한 OAuth2 Access Token을 획득할 수 있습니다.

3. 권한 부여 승인 코드를 가지고, Authorization Server에 OAuth2 Access Token을 효청합니다.
3-1. 요청 시 발급한 client_id, redirect_url, grant_type, code(권한 부여 승인 코드)를 쿼리 파리미터로 포함한 API 요청을 보냅니다.
3-2. 성공적으로 인증되면, OAuth2 Access Token을 전달합니다.

4. OAuth2 Access Token을 소지한 Client는 Resource Server에게 보호하고 있는 Resource Onwer의 사용자 자원을 요청합니다.

 

 

🤔 Access Token을 획득하는 과정에서 Authorization Code 발급 과정이 들어간 이유?

[내용 출처 : https://wildeveloperetrain.tistory.com/247]

Authorization Code를 발급받는 과정이 생략되고 OAuth2 Access Token을 바로 발급받는다면,
Authorization Server는 권한 부여 코드 요청 시 전달받은 redirect_uri로 OAuth2 Access Token을 전달해야 합니다.

Redirect URI을 통해 데이터를 전달하는 방법은 URI 자체에 데이터를 실어 전달하는 방법 밖에 없으며, 이 방법을 사용하면 중요한 데이터인 OAuth2 Access Token이 브라우저를 통해 바로 노출되게 됩니다.

Authorization Code 발급 과정이 추가된 경우, redirect uri로 전달된 Authorization Code(2-1)를 백엔드 레벨에서 해당 승인 코드를 포함한 API 요청으로 OAuth2 Access Token을 발급받을 수 있습니다. 

이 과정을 통해 백엔드 사이에서 OAuth2 Access Token이 전달되기 때문에 액세스 토큰의 탈취 위험이 줄어드는 등, 다른 방식에 비해 보안적으로 안전하다는 특징이 있습니다.


<Authorization Code Grant 방식 예시>
Redirect URI: https://api.neo.com/callbackURL
파라미터로 Authorization Code를 전달합니다. 예: https://api.neo.com/callbackURL?code=abc123
(code는 노출되어도 덜 위험)

<Implicit Grant 방식 예시>
Redirect URI: https://api.neo.com/callbackURL
Access Token이 바로 URI에 포함됩니다. 예: https://api.neo.com/callbackURL#access_token=xyz456
(OAuth Access Token이 직접 노출)

 

 

NEO는 Spring OAuth2 Client를 사용하면서 위와 같은 Authorization Code Grant 방식을 사용했습니다.

이 방식 외에도 3가지 방식이 더 있는데, 추가적으로 알고 싶은 분들은 아래의 링크를 참고하시기 바랍니다.

OAuth, OAuth2 개념과 동작 방식 정리

 

 

✅ Spring OAuth2 Client?

 

Spring에서는 Security와 함께 OAuth2 Client 라이브러리가 존재합니다. OAuth2 Client 라이브러리는 OAuth2 Client로써 구현해야 하는 대부분의 내용을 쉽게 구성할 수 있도록 도와주는 라이브러리입니다.

 

프로바이더 로그인 폼으로 이동시켜주는 엔드포인트 자동 생성 부터, 권한 부여 승인 코드를 기반으로 Access Token 발급 받기 기능을 상세한 구현 없이 쉽게 사용할 수 있으며, OAuth2 Access Token을 사용해 자원서버로부터 받은 자원을 다루는 서비스를 추가 구현하기만 하면 위의 프로세스를 모두 손쉽게 만들 수 있습니다.

 

만약 OAuth2 Client 라이브러리가 없다면 각 프로바이더들의 API Docs를 확인해서, 각 과정에 해당하는 API를 직접 통신하려 RestTemplete나 WebClient를 사용하고, 엔드포인트 생성을 위한 컨트롤러 생성 등의 클래식한 구현이 필요할 것입니다.

 

따라서 OAuth2 Client 라이브러리를 사용하면 소셜 로그인 기능을 개발하기가 더욱 수월해집니다.

Spring OAuth2 Client가 하는 역할은 뒤에 이어지는 포스팅에서 확인하실 수 있습니다.

 

 

🔧 JWT Token

✅ JWT Token이란?

 

JWT(Json Web Token)은 말 그대로 웹에서 사용되는 JSON 형식의 토큰에 대한 표준 규격입니다. 주로 사용자의 인증(authentication) 또는 인가(authorization) 정보를 서버와 클라이언트 간에 안전하게 주고 받기 위해서 사용됩니다.

 

NEO에서는 OAuth2.0을 통해 OAuth2 Access Token을 획득하고 나면, 해당 Access Token을 우리 NEO 서비스에 인가할 때 사용하지 않고 별도의 JWT Access Token을 발급하여 사용할 예정입니다.

 

https://jwt.io/

 

위는 JWT 토큰의 구조입니다. Encoded와 Decoded 파트를 나눠서 봅시다.

 

🤔 Encoded

 JWT 토큰에 필요한 내용들을 담아 인코딩 된 긴 문자열로, 보통 우리가 JWT 토큰을 '전달'의 범위에서 얘기할 때 이 인코딩된 JWT 토큰을 의미합니다.

서버에서 클라이언트에게 인코딩 된 JWT 토큰을 전달할 때는 HTTP의 Authorization 헤더 혹은 Body에 담아서 전달하며,

클라이언트에서 서버로 JWT 토큰을 전달할 때 해당 문자열을 Authorization Header에 앞에 "Bearer "라는 문자열을 추가해 서버로 전달하는 것이 일반적입니다.

 

잘 보면, 인코딩된 JWT 토큰은 각 파트가 '.'으로 구분되어 있으며 각각 헤더, 페이로드, 시그니처 순서대로 인코딩 된 모습을 볼 수 있습니다. 그림의 색상을 보면 좀 더 확연히 알 수 있습니다.

 

 

🤔 Decoded

JWT 토큰의 구성 요소로 인코딩 되기 전의 JWT 토큰의 모습입니다. JWT 토큰을 생성할 때 위와 같이 Header, Payload, Signature의 3요소를 구성해 만들게 되며, 인코딩 된 JWT 토큰을 Decode하면 역시나 Header, Payload, Signature의 값을 획득할 수 있습니다.

 

- 헤더(Header)

해당 토큰 스스로에 대한 메타데이터를 저장합니다. 일반적으로 인코딩 알고리즘인 'alg'와 토큰의 유형인 'typ'를 포함합니다.

 

- 페이로드(payload)

토큰에 삽입하고자 하는 데이터를 의미합니다. JWT 토큰은 정해진 인코딩 알고리즘에 의해 쉽게 디코딩됩니다. 누구나 JWT 토큰에 대해 쉽게 정보를 열람할 수 있으므로 페이로드에는 가능한 누구인지 식별 가능한 최소한의 데이터만을 넣어야 하는 것이 중요합니다.

여기서 클레임(claim)이라는 개념이 나오는데, 쉽게 표현하면 페이로드에 추가되는 정보 조각의 단위라고 이해할 수 있습니다.

예를 들어, JWT 토큰을 생성할 때 각 사용자를 구별할 수 있는 '이메일'에 대한 정보를 넣고 싶다고 가정합니다. 

그렇다면 JSON 변환이 가능한 key-value의 형태로 해당 조각을 삽입하는 것입니다.

예를 들어 아래와 같이 말이죠.

{
      "sub": "1234567890",
      "email": "aaaaa1234@gmail.com",
}

위와 같은 페이로드는 'sub'와 'email' 두 개의 클레임으로 이루어졌다고 표현할 수 있습니다.

 

- 시그니쳐(Signature)

시그니쳐는 헤더와 페이로드를 각각 Base64 인코딩을 거친 문자열과 백엔드 서버가 소지하고 있는 Secret Key를 포함해서 다시 인코딩한 긴 문자열을 의미합니다. 이렇게 만들어진 시그니쳐는 JWT 토큰에 포함이 되며, 추후 JWT 토큰의 유효성을 검증할 때 사용됩니다.

Secret Key는 시그니쳐의 일부를 구성하게 되는 문자열로 랜덤한 문자열로 개발자가 생성해서 사용하면 됩니다. 인터넷 상의 Key Generator를 사용하기 보다, 키보드를 랜덤하게 길게 입력해 구성하는 것이 좋습니다.

일반적으로 Springboot 프로젝트에서 Secret Key를 application.yml에 별도로 저장해 노출되지 않도록 합니다.

 

 

✅ Access Token과 Refresh Token

 

JWT Access Token은, JWT를 사용해 특정 서비스에 접근이 가능하도록 인증/인가의 역할을 할 수 있도록 만드는 매개체입니다.

위의 JWT Token에 대한 내용을, 어떻게 새롭게 생성하고 어떻게 해당 토큰을 검증하는지를 그림으로 살펴보며 JWT Token이 어떻게 Access Token로 활용될 수 있는지 살펴보도록 하겠습니다.

 

우선, JWT 토큰을 생성하는 과정입니다.

 

위에서 설명한 내용대로, 헤더와 페이로드에 내용을 채워넣게 되고 시그니쳐는 이렇게 입력된 헤더 + 페이로드 + 시크릿 키를 기반으로 생성됩니다. 그리고 JWT Token은 헤더와 페이로드와 시그니쳐를 인코딩해 만들어지게 됩니다.

이렇게 만들어진 JWT Token은 클라이언트에게 Authorization 헤더 혹은 Body로 전달합니다.

그렇다면 클라이언트는 해당 JWT Token을 안전한 방법으로 보관을 하고 있다가, 서버의 API를 사용하기 위해 요청과 함께 헤더에 해당 토큰을 담아서 전송을 하게 됩니다.

 

 

 

서버에 도착한 JWT Token은 검증 과정을 거치게 됩니다. 검증 과정은 아래와 같습니다.

1. 서버에 도착한 JWT Token을 디코딩합니다.
2. 클라이언트로부터 받은 JWT 토큰의 시그니쳐를 '원본 시그니쳐'라고 지칭합니다.
3. 클라이언트로부터 받은 JWT 토큰의 헤더와 페이로드를 얻어옵니다.
4. 서버에 저장된 secret key를 가지고 '테스트 시그니쳐'를 생성해냅니다.
5. 원본 시그니쳐와 테스트 시그니쳐를 서로 비교합니다.
    5-1. 두 서명이 같다면 검증 통과입니다.
    5-2. 두 서명이 다르다면 검증 실패입니다. (헤더 혹은 페이로드 위조 등)

 

서버는 요청과 헤더에 포함된 JWT 토큰을 가지고 우리가 아는 사용자인지, 해당 사용자가 이 서비스에 접근할 권한이 있는지 판단해야 합니다. 그리고 그러한 과정을 JWT 토큰을 검증하는 것으로 대체할 수 있습니다.

JWT 토큰을 검증했을 때 유효하다면 우리 서비스가 만들어낸 토큰이므로(시크릿 키가 노출되지 않는 이상) 인증을, 페이로드에 사용자 역할을 포함한다면 인가 역시 JWT 토큰을 통해 구현이 가능하게 됩니다.

 

따라서 이러한 방식으로 만들어진 JWT 토큰은 Access Token으로써 활용할 수 있는 것입니다.

 

JWT 토큰을 사용하면 서버에 별다른 인증 정보 저장 공간이 없더라도 자체적으로 인증/인가가 가능합니다.

이러한 점은 세션과 다른 굉장한 차별점으로 작용해 JWT Token 방식이 인기를 얻었습니다.

 

하지만 이런 Access Token에도 단점은 있습니다.

해당 Access Token이 다른 누군가에게 탈취되어 사용한다면 서버에서는 해당 토큰에 대한 정보를 별도로 저장하지 않기 때문에, 서버로 들어온 요청이 다른 사용자가 탈취해서 사용하는 것인지, 실제 사용자가 사용하는 것인지 구별하지 못합니다.

물론 Access Token의 관리를 제대로 못한 클라이언트에게 잘못이 있지만, 탈취가 의심되는 상황에 별도의 저장 공간이 없다면 서버측에서도 후속 조치가 어렵습니다.

 

이러한 단점을 최소화하기 위해 나온 아이디어가 바로, "Access Token의 만료시간을 짧게 설정해서 탈취가 되더라도 피해를 최소화 하자"라는 아이디어입니다.

해당 방법은 효과적이지만, 단순히 Access Token의 유효기간을 짧게 설정한다면 기간이 만료될 때마다 새로 로그인을 하는, 불편한 사용자 경험을 안겨주게 됩니다.

 

그래서 추가된 개념이 바로, 'Refresh Token'입니다.

클라이언트가 로그인을 하면, 서버는 Access Token과 Refresh Token을 같이 지급합니다. 여기서 두 토큰의 만료기간은, Access Token이 훨씬 짧고 Refresh Token은 만료 기간이 긴 구조로 이루어져있습니다.

 

어느 순간, Access Token이 만료되고 사용자는 해당 토큰으로 서버에 요청을 보냅니다. 서버는 만료된 사실을 알아차리고, 요청을 반려합니다. 이때 다시 로그인을 유도하지 않고 Refresh Token을 함께 요구합니다. Refresh Token이 유효하고 Access Token이 만료되었다면 새로운 Access Token을 발급해주는 구조죠.

 

이런 방법을 사용한다면 잦은 로그인을 유도하지 않고, 탈취된 Access Token에 대해서 최소한의 피해로 줄일 수 있습니다.

물론 이 방법 역시 Refresh Token도 함께 탈취가 된다면 서버 측에서는 손 쓸 방법이 없습니다. (토큰 정보에 대한 내용의 저장 공간이 없는 경우.)

 

 

✅ Refresh Token의 종류

 

Refresh Token은 크게 두 가지로 구현할 수 있습니다.

 

🙋🏻 1. 기존 JWT(Claim) 방식의 Refresh Token

기존의 JWT 토큰을 활용해서 Refresh Token을 만들 수 있습니다. 기존에 생성하던 방식 그대로 생성이 가능하며, 만료기한 역시 쉽게 설정할 수 있습니다. Access Token과는 별개로 새로운 Access Token을 발급 받기 위한 토큰이 존재 의의이므로 Access Token에 들어갔던 일부 클레임 역시 제거해도 됩니다. 

다만 Access Token과 Refresh Token이 모두 탈취되었을 경우에는 별도로 손 쓸 방법이 없습니다. 여전히 JWT 토큰은 Stateless 하니까 말이죠. 

 

🙋🏻 2. UUID를 활용한 Refresh Token

UUID를 랜덤하게 생성해 해당 문자열을 Refresh Token으로 사용하는 방법이 있습니다. 다만 UUID는 JWT 토큰이 아니기 때문에 자체로 만료 시간을 결정할 수 없습니다. 따라서 해당 방법을 사용한다는 것은 곧 서버에 별도의 토큰 저장 공간을 마련한다는 의미와 동일합니다. 

 

NEO에서는 2번, UUID를 활용한 Refresh Token을 선택했고, 저장 공간으로는 Redis를 선택했습니다.

선택 사유는, 우선 인메모리 key-value 캐시로서 색인 속도에서 이점을 얻을 수 있으며 Redis 캐시에 데이터가 언제까지 저장될 지 만료기간을 선택할 수 있어 토큰과 비슷한 구조로 설계할 수 있다는 점이 좋게 작용했습니다.

 

이와 같이 Refresh Token이 서버에서 별도 스토리지로 관리된다면, 특정 토큰의 접근을 막는 'black list' 구현을 통해 보안을 더욱 더 강화할 수 있습니다.

예를 들어 Logout 이후에도 아직 만료시간이 지나지 않은 토큰에 대해 접근을 막는 것도 가능해지죠.

 

 

✅ 그럼 세션을 사용하는 것과 별반 다를 것이 없네요?

 

이 의견에 있어서 너무나도 동의합니다. JWT 토큰을 사용하는 가장 큰 이유는 "인증 정보를 별도로 저장하는 공간이 없어도 된다, stateless하다"이기 때문에 이러한 장점이 퇴색되어 결국에는 세션을 사용하는 것과 큰 차이가 없어보입니다.

 

기존의 JWT 토큰은 stateless 하기 때문에 확장성이 굉장히 좋았습니다. 서버가 여러대로 늘어나더라도 별도의 세션 서버가 없기 때문에 세션 서버를 신경 쓸 필요가 없었기 때문이죠. 그러나 별도로 저장하는 공간이 생겼다는 것은 이러한 점을 앞으로 고려해야 한다는 것입니다.

 

따라서 이러한 구현을 회의적인 시각으로 보시는 개발자분들도 많이 보았습니다.

그럼에도 JWT Token + UUID Refresh Token in Redis의 방식으로 구현하면 가질 수 있는 장점에 대해 생각해보자면,

일반적인 세션 방식에 비해 세션 서버에 대한 '요청' 자체를 줄일 수 있다는 점에 포인트를 주고 싶습니다.

세션 방식은 세션 ID를 담은 쿠키와 요청을 함께 전송하고 해당 세션 ID를 기반으로 세션 서버의 스토리지를 확인합니다. 즉, 세션 서버에 해당 사용자의 정보를 얻어오는 요청이 한 번, 본래 클라이언트가 원하는 요청이 한 번 일어나게 됩니다.

 

그러나 JWT Token + UUID Refresh Token in Redis 방식의 경우, JWT Access Token에 대해서는 Redis가 별도로 관리하지 않습니다. 따라서 토큰 자체의 유효성 검사만으로 본래 요청을 행할 것인지 반려할 것인지를 정할 수 있습니다.

 

만약 세션 서버의 요청 역시 부담이 가는 프로젝트라면 유효하게 작용할 수 있을 것 같습니다.

물론 이러한 점보다 다른 포인트를 훨씬 중요하게 여긴다면 다른 방법을 선택하는 것이 해당 서비스에 더욱 어울릴 것이라고 생각합니다.

아직 경험이 많지 않은 개발자라 어떤 서비스에 어떤 방식을 선택하는 것이 최선인지 다양한 의견을 듣고 싶고, 좋은 경험을 쌓고 싶다는 생각이 들 뿐이네요.

 

소프트웨어 공학에서 '은탄환은 없다' 라는 말이 있습니다.

울버린, 늑대인간, 드라큘라와 같은 괴물들에게 은탄환(one seeks bullets of silver)은 한번에 무력화 시킬 수 있는 최고의 도구이다.
- Fred Brooks, 『Silver Bullet-Essence and Accidents of Software Engineering』

토큰 방식은 세션 방식을 대체하기 위해 나온 개념이지만, 역시나 은탄환은 아녔습니다. 

다음에 기회가 된다면 세션 방식도 한 번 구현해보면서 각각의 장점을 좀 더 체감하고 싶네요.

 

 

☕️ 전체 프로세스 도식화

 

아래의 그림은 NEO에서 사용된 전체 프로세스를 표현한 그림입니다. 표현력의 문제로 약간의 차이가 있을 수 있으므로 참고만 부탁드립니다.

 

Figma

 

 

☕️ 연관 포스트

업데이트 예정..
[⚙️ Trouble Shooting] - [TS] Spring Security + Spring OAuth2 Client 적용 과정 중 발생한 문제 트러블 슈팅

 

 

☕️ Reference

https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-claims
https://wildeveloperetrain.tistory.com/247
https://stackoverflow.com/questions/31309759/what-is-secret-key-for-jwt-based-authentication-and-how-to-generate-it