[Spring 분석] 세션과 토큰(Session, Token)

Session을 이용한 서버기반의 인증방식이 많이 사용되어왔으나, 규모나 한계로 인하여 Token을 이용한 토큰기반의 인증방식이 많이 사용되고 있다고 합니다. 이번에 Session, Token의 동작원리 및 장단점을 살펴보도록 하겠습니다.

 

1. Session(세션) : 서버기반의 인증방식
사용자가 인증할때, 서버가 사용자정보를 저장하는데 이를 Session(세션)이라고 부릅니다.

[동작원리]

 서버기반의 인증방식은 서버 측에서 사용자정보를 기억하고 있어야합니다. 사용자정보를 기억하기 위해서는 Session을 유지해야하고, Session은 메모리,디스크,DB등을 통해 관리합니다. 서버기반의 인증방식은 클라이언트로 부터 요청을 받으면, 클라이언트는 상태를 계속 유지하고 그 정보를 서비스에 이용합니다. 이러한 서버를 Staeful서버라고 합니다.

 

[동작]

 사용자가 로그인 > Session에 사용자정보 저장 > 서비스 제공시 Session에 저장된 사용자 정보 사용

 

[단점]

1. 세션 관리

   세션은 주로 메모리에 저장하는데, 로그인 중인 사용자가 늘어날 경우 RAM에 부하가 걸리게 됩니다.  이러한 문제로 DB에 저장하기도 는데, 역시 DB에 부하가 걸릴 수 있음을 인지해야합니다.

 

2. 확장성

   관리하는 서버가 확장될 경우, 세션도 분산시키는 시스템을 설계해야하는데 해당 과정은 매우 어렵고 복잡하다고 합니다.

 

3. CORS(Cross-Origin Resource Sharing)

   세션을 관리할때 주로 사용하는 쿠키는 단일 도메인, 서브 도메인에서만 작동하도록 설계되어있다고 합니다.

그렇기에 쿠키를 여러 도메인에서 관리하는 것은 번거롭습니다.

 

2. Token(토큰) : 토큰기반의 인증방식

[동작원리]

토큰기반의 인증방식은 더이상 사용자의 인증 정보를 서버나 세션에 유지하지 않고, 클라이언트측에서 보내주는 토큰을 사용하여 작업을 처리합니다. 즉 서버 기반의 인증시스템과는 달리 상태를 유지하지 않으므로 Stateless구조를 갖습니다. 그러므로 로그인되어있던 안되어있던 던 상관없이 시스템확장이 가능합니다.

 

[동작]

사용자 로그인 > 서버측에서 검증 > 정확하다면 사용자에게 토큰발급 > 사용자는 받은 토큰을 저장해두고, 서버 요청시마다 토큰도 함께 전달(헤더에 포함) > 서버는 요청이 들어오면 토큰 검증하고, 요청에 응답

 

[장점]

1. Stateless와 확장성

 토큰기반의 인증방식은 상태를 유지할 필요없는 Stateless이며, 클라이언트와 서버의 연결고리가 필요없어 확장에 용이합니다. 

(OAuth의 경우 Facebook, Google 등과 같은 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.)

 

2. 보안성

   더이상 쿠키를 전달하지 않으므로, 쿠키사용에 의한 취약점이 사라집니다.

 

3. CORS문제 해결

  토큰을 사용한다면 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리할 수 있다. 이런 구조를 통해 assests 파일(Image, html, css, js 등)은 모두 CDN에서 제공하고, 서버 측에서는 API만 다루도록 설게할 수 있다.

 

최근에는 Json 포맷을 이용하는 JWT(Json Web Token)을 주로 사용한다고 합니다.