세션 기반 인증, JWT 기반 인증

😄 세션기반 인증

• 실제 인증정보는 서버에 저장된다.
• 사용자가 로그인하면 해당 인증정보를 서버의 세션저장소에 저장한다.
• 이때, 고유 세션값인 SessionId를 발급해줘서 이를 쿠키형식으로 저장한다.
• Session ID는 브라우저 단위로 저장되고, 브라우저 종료 시 제거된다.

장점

• 세션은 쿠키헤더에 세션ID만 넣어보내면 되므로 트래픽도 적다.
• 서버에서 인증정보를 관리하므로 보안 측면에서 유리하다. (탈취당하더라도, 세션을 무효처리하면 됨)

단점

• 한 서비스가 아닌 여러서비스에서 요청을 처리할때 문제가된다.
  • 브라우저별로 SessionId가 발급되므로 세션 불일치 문제를 겪게되기때문이다.

해결방안

• Sticky Session, Session Clustering, 세션 스토리지 외부 분리

 

😀 JWT 기반 인증

• 인증정보를 클라이언트에서 들고있는 방식이다.
• 인증정보가 토큰형식으로 브라우저의 로컬스토리지(쿠키)에 저장된다.
• 토큰 내용이 위변조 됐는지 서버에서 확인처리한다.

장점

• 서버에서 인증방식을 저장하지않으므로 stateless한 상태를 유지하므로 높은 확장성을 가지고 있다.

단점

• 토큰 특성상 누구나 내용을 확인할수있어 민감정보를 담을수없다.
• 중간에 탈취하면 피해받을수밖에 없다.
• 서버에서 로그아웃을 관리가 어렵다.

해결방안

• access token (인증정보를 담고있는 토큰) , refresh token (토큰발급을 위한 토큰)
• Refresh Token이란 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 토큰이다.
• Access Token은 탈취 당하면 정보가 유출되는건 동일하나, 유효기간이 짧기에 조금더 안전하다는 뜻이다.
• refresh token은 주로 서버사이드에 저장(DB)하여 리프레시 토큰이 만료되기전까지 회원은 계속 로그인이 유지되는 상태가 된다.
  • 이때 디비는 주로 redis에 저장한다. (레디스는 기본적으로 데이터의 유효기간(time to live)을 지정할 수 있기때문)

로그아웃 구현방식

• 블랙리스트 방식
  • 서버사이드에 저장했던 리프레시 토큰을 지우고, 블랙리스트 DB를 하나로 만들어서 원래 유효시간과 access token을 저장한다.
  • 이후에 동일한 토큰으로 또 요청이오면 블랙리스트에 해당 토큰이 있는지 확인한 후 없으면 응답한다.

 

 

 

 

출처

세션 기반 인증과 토큰 기반 인증 (feat. 인증과 인가)

로그인 방식에 대해 알아보자