[Nest.js 학습일기] Session & Token 이론

Session & Token

둘 다 사용자의 로그인 상태를 유지하는 인증수단으로 사용한다. 단, 둘의 방식엔 차이가 있는데 이를 확인해보자.

Session

• 특수한 ID 값으로 구성되어 있다.
• 서버에서 생성되며, 클라이언트는 쿠키 형태로 저장된다.
• Session ID를 같이 서버측에 보내면 사용자가 누구인지 판단할 수 있다.
• DB에 Session ID가 저장되어 있다.
  • 요청이 있을 때 마다 DB를 확인해야한다.
  • 서버측에 데이터가 저장되어 클라이언트에 이용자 정보 노출 위험도 낮다.
  • DB에 저장해야하므로 Horizontal Scaling이 어렵다.

JWT Token

• 유저의 정보를 Base64로 인코딩된 String 값에 저장한다.
  • Header, Payload, Signature로 구성되어있다.
• 서버에서 생성되며 클라이언트에 저장된다.
• Token ID를 확인해 사용자를 판단한다.
• DB에 저장되지 않고 Signature 값을 통해 검증 가능하다.
  • 즉, 매번 DB를 볼 필요 없기에 Horizontal Scaling이 상대적으로 쉽다.
  • 정보가 모두 토큰에 담겨있기에 탈취 가능성 있다.

	Session	JWT Token
저장위치	서버	클라이언트
서버로 보내는 정보	쿠키	토큰
유저 정보 DB 확인 여부	필요	Payload에 들어있는 정보만 필요한 경우 불필요
클라이언트 측 인증정보 확인 가능 여부	불가능	가능

Refresh & Access Token

• 둘다 JWT 기반이다.
• 짧은 유효기간의 Access Token과 상대적으로 긴 유효기간의 Refresh Token을 활용해 탈취 당하는 경우 오래 사용하지 못하도록 한다.
  • +) Refresh Token의 경우 사용 빈도가 낮아 탈취 가능성 낮다.

사용방법

Access Token은 API 요청 검증용 토큰으로 유저정보 수정, 채용 공고 지원 인원 확인 등 자격 확인에 사용한다. Header에 담아 서버측에 보내면 자격을 확인한다. 토큰이 만료된 경우엔 Refresh Token을 활용해 Access Token을 재발급 받는다.

토큰 발급 과정

1. Client => Server
   • 'username:password'값을 base64 인코딩 후 authorization 헤더에 'Basic $token' 형태로 전송

2. 이를 받은 서버는 검증 과정을 거치고

3. 토큰을 전송한다 (refresh + access)

Refresh Token 사용 과정

1. Client => Server
   • authorization: "Bearer $refreshToken"값을 헤더에 담아 서버에 요청

2. 이를 받은 서버는 검증 과정을 거치고

3. 토큰을 재발급한 이후 전송한다 (access)

Access Token 사용 과정

API 요청하는 경우 사용하므로 DB에 접근해서 데이터를 가져오는 과정까지 진행한다.

1. Client => Server
   • authorization: "Bearer $accessToken"값을 헤더에 담아 서버에 요청

2. 이를 받은 서버는 검증 과정을 거치고

3. 유효하다면 API 요청에 해당하는 작업을 수행한 후

4. 데이터 응답을 전송한다.

Refreshing Logic (Access Token 사용 API 요청시 만료된 경우)

1. 만료된 것을 확인한다면 서버는 만료 응답을 보낸다.

2. 이를 확인한 클라이언트 측은 재발급을 요청하고 발급받은 Access Token으로 재요청한다.

3. 데이터 응답을 받는다.