0. 프로젝트 목적

 

목적

여태까지 모든 프로젝트에서

JWT 토큰과 OAuth를 사용해서 인증 기능을 구현했었다. 그래서 이번에는 JWT가 아닌 Session 인증을 사용해서 예제 프로젝트를 만들어보려고 한다.

시작하기에 앞서, 각 인증 방식의 장단점을 비교해보자.

토큰 인증 방식

아래는 Glims 프로젝트에서 테스트용으로 발급한 JWT 토큰이다.

eyJ0eXAiOiJqd3QiLCJhbGciOiJIUzUxMiJ9
.eyJzdWIiOiJ3bnN2eTYwN0BuYXZlci5jb20iLCJpYXQiOjE2ODQyMzQxMzcsImV4cCI6MTY4NDMyNDEzNywid
G9rZW5fdHlwZSI6ImFjY2Vzc190b2tlbiIsInJvbGUiOiJST0xFX1VTRVIifQ
.kZNkxiSoy5OpdWhqyJS0x0ru3HcjVkL0UwTRXAuQFpKSowj9_Be3BIrX_3D5nPWcpjR0AePYTC3U7wgUOCDrow

 

장점

 

확장이 간편, 서버의 부하가 적다.

Scale-out 할 때 Session은 모든 서버에서 Session 정보를 공유해야 하기 때문에 별도로 Session Storage를 두어야 한다. Cache나 DB를 쓴다. 하지만 토큰은 서버에서 클라이언트가 보낸 토큰의 Signature만 확인하면 되기 때문에 별도의 저장소를 둘 필요가 없다. 게다가 Session의 경우 사용자가 여러명 있을 경우 서버에서 관리하기 때문에 부담이 커지지만, 토큰 인증 방식은 사용자가 많이 늘어나도 서버의 부담이 전혀 증가하지 않는다.

 

구현이 간편하다

클라이언트에서 필요한 정보를 가지고 있는 것이기 때문에 Http의 Stateless를 활용할 수 있다. 더불어 별도의 저장소가 필요 없어 라이브러리와 몇 가지 클래스만으로 편리하게 도입할 수 있다.

단점

(기본적으로 토큰은 주로 access token과 refresh token을 나누어서 관리한다.)

 

보안에 취약한 측면이 있다.

1. 해커에게 탈취당할 경우 access token을 즉시 만료시킬 수가 없다.(refresh token은 가능하다)
2. 단지 Baes64로 인코딩되어 있기 때문에 payload에 민감한 정보가 담기면 안된다. 즉, 해커가 탈취할 경우 payload 정보를 Base64로 디코딩하여 확인 가능하다.

Glims 토큰을  jwt.io  에서 그대로 디코딩한 결과

 

토큰이 너무 비대하다

Session 인증 방식과 비교 했을 때 여러가지 정보가 토큰에 담겨 있기 때문에 매 요청마다 훨씬 더 많은 네트워크 트래픽을 사용한다. Session ID는 한자리 수 바이트 단위인데 반해 토큰은 보시다시피 몇십배의 크기다.

세션 인증 방식

비교는 상대적이기 때문에, 토큰 인증 방식의 장단점을 뒤집으면 된다.

결론

 

서로 장단점이 있기 때문에 정답은 없다. 애플리케이션의 Context에 따라 정하면 될듯하다. 하지만 많은 서비스에서 Session을 기반으로 인증하기 때문에 한 번은 시도할 필요가 있다고 느꼈다. 그리고 또 하나는 캐시 서버(Redis)를 써보고 싶었는데 세션 저장소로 활용하는 것이 제일 만만해 보였기 때문이다.

목표

 

세션 기반으로 소셜 로그인 구현 + Redis에 세션 저장

1. Spring Security로 소셜 혹은 일반 로그인, 로그아웃 기능 구현
2. Spring Session 으로 인증 및 인가
3. Session Storage를 3가지 방식으로 구현
   1. 인메모리 저장(?)
   2. DB에 저장(h2)
   3. Redis에 저장

2023.05.16