세션 인증과 토큰 인증

여기에서 말하는 인증이란 우리가 흔히 접하는 "로그인" 을 생각하면 된다. 

이렇게 인증을 거친 뒤로는 허가된 페이지에 기본적으로 모두 접근이 가능해야 하고 

Stateless 한 HTTP의 특성상 인증이 완료된 상태를 유지하기 위한 매개체가 필요하다.

 

이런 매개체로 과거 많이 사용되던 것이 세션이다.

Tomcat 같은 서블릿 컨테이너를 사용할 경우 기본적으로 우리가 아무 것도 하지 않아도

클라이언트의 최초 요청 처리시 JSESSIONID 라는 값이 클라이언트 Cookie에 셋팅되고

이후 요청마다 해당 값이 Request에 포함되어 클라이언트 식별이 가능해진다.

이를 통해 서버에서는 클라이언트 별로 유니크하게 구분된 세션저장소를 활용할 수 있게 되고

이곳에 인증이 완료된 상태를 저장해놓고 활용하게 된다.

 

그런데 상용서비스의 경우 하나의 서버만으로 서비스를 제공하는 것은 무리가 있기 때문에

일반적으로 다수의 서버로 구성된 분산시스템으로 구성된다.

이렇게 되면 클라이언트와 서버 사이에 스위치가 추가되어 라우팅 혹은 로드벨런싱 처리 되기 때문에

최초 세션에 인증정보가 저장된 서버에서 지속적으로 요청이 처리된다는 보장이 없기 때문에

각 서버마다 생성되는 세션 정보 공유가 필요해진다.

이에 Tomcat 같은 서블릿컨테이너에서는 세션클러스터링이라는 세션 공유 기능을 지원한다.

 

하지만 이렇더라도 문제는 남아있다.

세션은 서버에 저장되는 데이터이기 때문에 

인증정보가 실제 서비스를 처리하는 서버의 메모리에 저장된다는 것인데

이렇게 되면 동시접속자가 많아질수록 별다른 로직을 수행하지 않는데도

메모리 부족현상이 발생할 수 있다.

그런데 그렇다고 무작정 메모리를 늘리자니 동시접속자가 적을 때에는

불필요하게 FullGC 시간만 증가하는 문제가 생기게 된다.

 

물론 동시접속자가 많을거 같은 시간에만 한시적으로 메모리를 늘리고

동시접속자가 줄어들면 다시 메모리를 줄이면 되겠지만

서비스 처리에 필요한 메모리와 세션저장을 위한 메모리는

비례하지 않는 경우가 대부분이기 때문에 에초에 별도의 세션저장소를 두는 편이 낫다.

 

보편적으로 많이 쓰이는 별도 세션저장소는 Redis로 

스프링에서는 세션 클러스터링을 지원하는 Spring-Session 이라는 모듈을 제공하고

이를 통해 세션과 Redis를 연동하면 된다.

 

하지만 이 역시 단점은 있다.

세션을 저장하기 위한 별도의 미들웨어(Redis)가 필요하기 때문에 관리포인트가 늘어나고

이를 확장할 때에도 정보가 유실되지 않도록 주의가 필요하다.

또한 인증여부를 체크하기 위해 매 요청마다 세션저장소를 조회를 해야 하는 점도 있다.

이에 이러한 인증정보를 에초에 서버에 저장할 필요가 없는 토큰인증방식이 있다.

 

세션인증방식이 A유저가 로그인을 통해 인증이 완료되면

A가 인증이 완료되었다 는 세션정보를 특정 저장소에 저장해놓고

이후 A가 다시 접근할 때 해당 세션정보 읽어와서 인증여부를 체크하는 방식이라면

토큰인증방식은 A유저가 로그인을 통해 인증이 완료되면

클라이언트로 A가 인증이 완료되었다 는 토큰을 발급하고

클라이언트에서는 이를 특정 공간에 저장해두었다가

서버 요청시마다 Authentication header 에 해당 토큰을 함께 전달하는 방식이다.

서버에서는 토큰 유효성 검증을 통해 A가 인증이 완료되었다 는 것을 확인하고 서비스를 제공하게 된다.