JWT와 session의 개념 및 차이점 정리

jellyjw·2023년 1월 11일
study
4
post-thumbnail

개요

  • 로그인 방식을 지원하는 대표적인 두 가지 방식 Session과 JWT 개념에 대한 정리

JWT (Json Web Token)

Authentication vs Authorization
image

Authentication (인증): 로그인과 같이 사용자 혹은 프로세스의 신원을 확인하는 프로세스
Authorization (권한부여): 누가 무엇을 할 수 있는지 결정하는 규칙, JWT가 유용하게 사용되는 시나리오 중 하나

Session 방식

Session 방식
image
  1. 클라이언트가 로그인을 위해 인증 정보를 서버에 전송
  2. 서버는 메모리에 사용자를 저장하고, 세션 아이디를 쿠키로 전달
  3. 클라이언트는 쿠키에 저장된 세션 아이디를 이용하여 요청
  4. 서버는 일치하는 세션 아이디를 메모리에서 검색한 후 응답

Q. 서버 인증 기반의 문제점?

  • 세션을 DB에 저장해서 탐색하기 때문에 유저가 늘어날 수록 서버의 램이 과부하
  • 여러 개의 프로세스를 돌리거나 서버 컴퓨터를 추가하는 것이 용이하지 않음
  • 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있어 여러 도메인에서 관리하기 번거로움

JWT (Json Web Token)

  • JWT (Json Web Token) 은 JSON 개체로 안전하게 전송하기 위한 국제 표준 (RFC 7519)
  • 디지털 서명이 되어 있으므로 확인하고 신뢰할 수 있음
JWT 방식
image
  1. 클라이언트가 로그인을 위해 인증 정보를 서버에 전송
  2. 서버는 secret 정보를 이용하여 JWT를 생성하고, 클라이언트에게 전달
  3. 클라이언트는 로컬 혹은 브라우저에 저장해두었던 JWT를 이용하여 요청
  4. 서버는 JWT가 일치하는지 확인한 후, 응답

JWT 구조

  • 크게 3개의 점으로 구분된 3가지 부분으로 구성된다.
    • Header
    • Payload
    • Signature
xxxxx.yyyyy.zzzzz
  • Header
    • 헤더는 토큰 타입과 어떤 알고리즘이 쓰였는지를 나타낸다.
{
  "alg": "HS256",
  "typ": "JWT"
}

이 json은 Base64Url로 인코딩된 JWT의 첫번째 부분

  • Payload

    • 토큰의 두번째 부분은 사용자 및 정보가 담겨있는 payload 부분
    • payload에 담긴 정보는 인코딩만 되어 있기 때문에 누구라도 디코딩하여 확인할 수 있으므로 중요한 정보를 담으면 보안상 위험

  • Signature

    • 마지막 Signature 영역을 생성하려면 인코딩된 header, 인코딩된 payload, secret, 헤더에 지정된 알고리즘을 이용하여 해싱한다.
    • 만약 어느 하나라도 일치하지 않으면 완전히 다른 값을 갖게 된다.

토큰 작동 방식

  • 로그인하면 JSON 웹 토큰이 반환
  • 토큰은 자격 증명이므로 보안 문제를 방지하기 위해 세심한 주의 필요
  • 일반적으로 토큰을 필요 이상으로 오래 보관해서는 안 되며, 또한 보안이 취약하기 때문에 민감한 세션 데이터를 브라우저 저장소에 저장해서는 안됨
  • 앱에서는 설치된 앱 별로 안전한 저장 공간이 제공되지만 웹에서는 세션 인증이 나은 선택일 수도 있다.

Q. Token 인증방식의 장점?

  • 무상태와 확장성, token은 클라이언트쪽에만 저장되므로 staeless 하며, 서버를 확장하기에 적합한 환경을 제공
  • 쿠키를 사용함으로 인해 발생하는 보안 취약점이 사라짐
  • 토큰을 사용하여 다른 서비스에도 권한 공유

Session vs JWT 차이점

  • 서버에 인증 정보를 저장하지 않는다는 점이 상이
  • 클라이언트의 요청마다 인증을 위해 DB를 탐색하는 과정이 필요하지 않고, 저장 공간도 필요하지 않음

CSRF의 이슈

  • Cross site Request Forgery
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com
<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

CSRF의 보완책

  • CSRF 토큰 - CSRF 토큰은 서버 측 응용 프로그램에서 생성하고 클라이언트와 공유하는 고유한 비밀 및 예측 불가능한 값

    • 양식 제출과 같은 중요한 작업을 수행할 때 클라이언트는 요청에 올바른 CSRF 토큰을 포함하여 전달

  • SameSite 쿠키 - SameSite는 웹 사이트의 쿠키가 다른 웹 사이트에서 발생하는 요청에 포함되는 시기를 결정하는 브라우저 보안 메커니즘

    • 중요한 작업을 수행하기 위한 요청에는 일반적으로 인증된 세션 쿠키가 필요하므로, 적절한 SameSite 제한으로 인해 공격자가 사이트 간에 이러한 작업을 트리거 X

  • Referer 기반 검증 - 일부 응용 프로그램은 HTTP Referer 헤더를 사용하여 CSRF 공격을 방어

    • 일반적으로 요청이 응용 프로그램의 자체 도메인에서 발생했는지 확인함
profile
jellyjw
남는건 기록뿐👩🏻‍💻
이전 포스트

기술면접 준비 (3)

다음 포스트

번들링과 웹팩

0개의 댓글