카테고리 없음

세션 기반 인증과 토큰 기반의 인증의 차이에 대해 설명하세요

JUNGKEUNG 2024. 6. 13. 23:03
반응형

인증 & 인가


 

인증(Autenticaion): 유저가 누구인지 확인하는 절차

 

  • 특정 서비스에 일정 권한이 주어진 사용자임을 아이디와 패스워드를 통해 인증 받는 것
  • 회원가입, 로그인

 

 

인가(Authorization): 유저의 요청에 대한 권한을 확인하고 허가 해주는 것

 

  • 인가를 하기 위해서는 반드시 인증이 선행되어야한다!
  • 내 계정으로’만’ 할 수 있는 활동을 시도할 때 허가 해주는 것
  • ex) 내가 작성한 글 수정하기, 내 아이디로 좋아요, 댓글 작성

 

지금도 서버는 웹사이트에서 무수한 사용자들의 요청에 응답해주고 있다.

이 때 로그인을 하고 이용하는 사용자와 그렇지 않은 사용자가 있는데, 서버는 각 요청마다, 이를 보낸 사용자가 로그인 과정을 거친 상태인지 허용을 해줄지 말지를 결정해서 응답 해줘야 한다. 이 때 사용자가 로그인을 하면 서버는 세션을 출력한다.

 

 

 

Session 기반 인증 방식


세션 기반 인증을 위해 Session과 Cookie가 사용되며, 다음과 같이 진행된다.

 

 

 

절차


  • 유저가 로그인을 하면 서버 메모리 상에 세션이 저장된다.
    (이 때 세션을 구분하기 위해 Seesion Id를 기준으로 정보를 저장한다.)
  • 클라이언트의 브라우저에 쿠키로 Session Id가 저장된다.쿠키: 브라우저에 저장되는 정보
  • 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송한다.
  • 서버는 클라이언트가 보낸 Session Id와 서버 메모리를 관리하고 있는 Session Id를 비교해서 일치하면 인가(Authorization)를 수행 해준다.

 

 

장점


  • 서버에 저장하기 때문에 관리가 매우 편하고 효율적이다.
  • 구현이 명확하며 실제 서버에서 로그인 상태를 확인하기 유용하다.

 

 

단점


  • 서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로, 클라이언트 수가 많으면 메모리나 DB에 부하가 심하다 (DB의 과부하)

 

  • 멀티 디바이스 환경(모바일, 공동 사용 등)에서 로그인 시 중복 로그인 처리가 되지 않는 등의 신경 써야 할 부분들이 발생한다.

 

  • 사용자가 많아지는 경우 로드 밸런싱을 사용한 서버 확장을 이용해야 하는데 이 때 세션의 관리가 어려워진다.로드 밸런싱(Load Balancing) 서버가 처리해야 할 업무 혹은 요청(Load)을 여러 대의 서버로 나누어(Balancing)처리하는 것을 의미한다.

 

따라서 세션을 사용하게 될 경우 이러한 단점들로 인해 관리하는 것이 어렵기 때문에 고안된 것이 ‘토큰 방식’이다.

 

 

 

토큰 기반 인증 방식(JWT)


Token 기반 인증의 방법으로 많은 웹 서버들은 JWT(Json Web Token)를 사용한다.

 

 

Token 기반 인증 방식과 Session 기반 인증 방식의 가장 큰 차이점은 유저의 정보가 서버에 저장되지 않으며, 서버는 유저 인증한다고 많은 일들을 하지 않아도 된다.

 

 

 

 

절차


  • 유저가 로그인을 요청하고 id, pw 정보가 유효하다면 서버에서 Secret Key를 사용해서 유저에게 토큰을 발급한다.
  • 클라이언트는 발급 받은 토큰을 저장하고, 서버에서 요청 할 때 마다, 해당 토큰을 함께 서버에 전달한다.
    • 사용자가 받는 토큰의 생김새
       
    • 인코딩 또는 암호화된 3가지 데이터를 이어 붙인 것으로, 각 부분 마다 갖고 있는 데이터가 다르다.payload: 토큰에 담긴 사용자 정보 등의 데이터가 저장 되어있다.
      누가 누구에게 발급했는지, 유효기간, 사용자에게 이 토큰을 통해 공개하기 원하는 내용(ex:사용자의 닉 네임, 서비스 상의 레벨, 관리자 여부 등)signature: 부호화 시킨 header와 payload를 가지고 발급해준 서버가 지정한
      secret key로 암호화 시켜 토큰을 변조하기 어렵게 한다.
    • ⇒ 따라서 사용자가 받아서 갖고 있는 토큰 자체에 이런 정보들이 들어 있으므로, 서버가 요청마다 데이터베이스에서 찾아야 할 것들이 줄어든다.
    • header: 토큰을 어떻게 검증(Verify)하는가에 대한 내용을 담고 있다.
    • 서버는 토큰을 검증 하고, 요청에 응답한다.

 

 

 

장점


  • 클라이언트에 토큰이 저장되어 있기 때문에 서버의 메모리에 부담이 되지 않으며 Scale에 있어 대비책을 고려할 필요가 없다.

 

  • 멀티 디바이스 환경에 대한 부담이 없다.

 

 

 

단점


  • 암호화가 풀릴 가능성을 배제할 수 없다.
    => 암호화가 풀리더라도 토큰을 사용할 수 없도록 만료기간을 짧게 설정한다. (짧게는 5, 6분. 길게는 1시간)

 

  • payload 자체는 암호화 되지 않고 base64로 인코딩한 데이터이므로, 중간에 payload를 탈취하면 디코딩을 통해 데이터를 볼 수 있다. 따라서 JWE를 통해 암호화 하거나, payload에 중요한 데이터를 넣지 않아야 한다.

 

 

총 정리


1) 세션 기반 인증

 

  • 사용자 인증 후 서버 측에서 세션을 유지된다.
  • 이 세션은 서버 측에서 관리되며, 클라이언트 측에는 세션 식별자가 쿠키로 저장된다.
  • 사용자가 로그인하면 서버는 사용자의 인증 정보를 기반으로 세션을 생성하고 관리한다.
  • 사용자가 로그아웃하거나 세션이 만료되면 세션은 삭제된다.
  • 서버에 저장되는 세션 정보로 인해 서버의 자원이 사용될 수 있으며, 확장성이 제한될 수 있습니다.

 

 

2) 토큰 기반 인증

  • 사용자 인증 후 서버는 토큰을 발급하고, 클라이언트는 이 토큰을 저장합니다.
  • 보통 JWT(JSON Web Token)와 같은 형식으로 토큰이 구성된다.
  • 이 토큰은 클라이언트 측에서 관리되며, 서버는 토큰을 확인하여 인증을 수행합니다.
  • 서버에서 세션을 관리하지 않기 때문에 서버의 부하가 줄어들고, 확장성이 높아집니다. 토큰은 보안적으로 서명되어 있어 변조가 어렵습니다.
  • 토큰은 만료 기간을 가질 수 있고, 이를 통해 보안 수준을 더욱 향상시킬 수 있습니다.

 

Scrip


세션 기반 인증은 서버가 사용자 상태를 관리하고 세션 ID를 사용하며, 클라이언트는 세션 정보를 직접 접근할 수 없다. 토큰 기반 인증은 클라이언트가 사용자 상태를 관리하고 액세스 토큰을 사용하며, 서버는 토큰을 검증한다. 토큰 기반 인증은 분산 시스템에서 용이하며, 서버 부하가 적지만, 선택은 애플리케이션 요구사항과 보안 고려사항에 따라 달라진다.

 

 

 

참고자료


https://dev-dobim.tistory.com/93

https://simgee.tistory.com/35