사전 지식

HTTP는 본래 정보를 유지하지 않는 statless한 특성을 가져, 각 통신의 상태가 저장되지 않기 때문에 웹사이트에서 인증을 관리하기 위한 방법이 필요하다.

유저가 어떤 사이트를 이용 중일 때 유저의 권한이 필요할 때 마다 재로그인을 요구한다면 사용성이 떨어지고 매우 비효율적이기 때문이다.

stateless
무상태.
즉, 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미.

따라서 이러한 HTTP의 특성 때문에 서버를 프로그래밍 할 때 인증과 인가를 어떻게 해야 할 지가 이슈❗

인증 & 인가

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

ex) 회원가입, 로그인

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

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

ex) 내가 작성한 글 수정하기, 내 아이디로 좋아요, 댓글 작성

• 인가를 하기 위해서는 반드시 인증이 선행되어야한다!
• 내 계정으로’만’ 할 수 있는 활동을 시도할 때 허가 해주는 것
  
  

그러면 어떤 사이트나 서비스에서 인증과 인가를 하기 위해사용자의 로그인 상태를 서버가 인지할 수 있도록 하는 방법이 뭐가 있을까🧐?

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

이 때 로그인을 하고 이용하는 사용자와 그렇지 않은 사용자가 있는데,

서버는 각 요청마다, 이를 보낸 사용자가 로그인 과정을 거친 상태인지 허용을 해줄지 말지를 결정해서 응답 해줘야 한다.

이 때 사용자가 로그인을 하면 서버는 세션을 출력한다.

세션(Session)
컴퓨터 공학에서 세션은 ‘장치 간의 정보 교환’을 의미하며
서버에 ‘로그인이 되어있음’이 지속 되는 상태도 ‘세션’이라고 한다.

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가지 데이터를 이어 붙인 것으로, 각 부분 마다 갖고 있는 데이터가 다르다.

    header: 토큰을 어떻게 검증(Verify)하는가에 대한 내용을 담고 있다.

    payload: 토큰에 담긴 사용자 정보 등의 데이터가 저장 되어있다.
    누가 누구에게 발급했는지, 유효기간, 사용자에게 이 토큰을 통해 공개하기 원하는 내용(ex:사용자의 닉 네임, 서비스 상의 레벨, 관리자 여부 등)

    ⇒ 따라서 사용자가 받아서 갖고 있는 토큰 자체에 이런 정보들이 들어 있으므로, 서버가 요청마다 데이터베이스에서 찾아야 할 것들이 줄어든다.

    signature: 부호화 시킨 header와 payload를 가지고 발급해준 서버가 지정한
    secret key로 암호화 시켜 토큰을 변조하기 어렵게 한다.
    

• 서버는 토큰을 검증 하고, 요청에 응답한다.

장점

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

단점

• 암호화가 풀릴 가능성을 배제할 수 없다.
  => 암호화가 풀리더라도 토큰을 사용할 수 없도록 만료기간을 짧게 설정한다.
  (짧게는 5, 6분. 길게는 1시간)
• payload 자체는 암호화 되지 않고 base64로 인코딩한 데이터이므로, 중간에 payload를 탈취하면 디코딩을 통해 데이터를 볼 수 있다. 따라서 JWE를 통해 암호화 하거나, payload에 중요한 데이터를 넣지 않아야 한다.

  Base64
  직역하면 64진법이라는 뜻으로, 8비트 이진 데이터
  (ex 실행파일, ZIP 파일 등)를 문자 코드에 영향을 받지 않는 공통 ASCII 영역의 문자들로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식

  
  
• 참고 사이트
  1. Session 기반 인증 방식 | millo's tech blog (millo-l.github.io)
  2. Session 기반 인증과 Token 기반 인증 :: Jins' Dev Inside (tistory.com)
  3. JSON Web Token Introduction - jwt.io
  4. TIL 50 | JWT 원리와 장단점 (velog.io)