JWT vs SESSION

JWT

JWT는 일반적으로 클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가(Authorization)를 위해 사용하는 토큰이다. 많은 언어에서 지원하며 JWT 시스템에서 발급된 토큰은, 토큰에 대한 기본정보, 전달할 정보 그리고 토큰이 검증됐다는 것을 증명해주는 SIGNATURE를 포함하고 있다.

 

구조

HEADER.PAYLOAD.SIGNATURE

HEADER는 JWT를 검증하는데 필요한 정보를 가진 JSON 객체는 Base64 URL-Safe 인코딩 된 문자열이다. 헤더(Header)는 JWT를 어떻게 검증(Verify)하는가에 대한 내용을 담고 있다. 참고로 alg는 서명 시 사용하는 알고리즘이고, kid는 서명 시 사용하는 키(Public/Private Key)를 식별하는 값이다.

{
  "alg": "HS256", // 사용된 해싱 알고리즘
  "typ": "JWT" // 토큰의 타입
}

위 예제를 JWT 사이트 내에서 테스트해보면 "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"의 결과를 얻을 수 있다.

 

PAYLOAD는 JWT의 내용이다. 페이로드(Payload)에 있는 속성들을 클레임 셋(Claim Set)이라 부른다. 클레임 셋은 JWT에 대한 내용(토큰 생성자(클라이언트)의 정보, 생성 일시 등)이나 클라이언트와 서버 간 주고받기로 한 값들로 구성된다. 이는 name / value의 한 쌍으로 이루어져 있으며 토큰에는 여러 개의 클레임 들을 넣을 수 있다.

클레임 구분	설명
등록된 클레임(register)	서비스에 필요한 정보가 아닌 토큰에 대한 정보를 담음
공개 클레임(public)	말 그대로 협의하에 서버, 클라이언트 간 공개된 정보, 충돌 주의
비공개 클레임(private)	서버, 클라이언트 협의하에 사용되는 정보

 

SIGNATURE은 점(.)을 구분자로 해서 헤더와 페이로드를 합친 문자열을 서명한 값이다. 서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 성성하고 Base64 URL-Safe로 인코딩한다.

 

단점

 - 토큰 자체에 payload가 존재한다.

    - base64로 인코딩만 된 데이터로 디코딩을 통해 데이터를 볼 수 있다. -> accessToken, refreshToken을 사용해 보안 강화.

 - 토큰의 크기가 커질 수 있다.

 - 중간에 탈취된 토큰을 expire 할 수 없다. -> 강제적인 삭제를 할 수 없음.

 

SESSION

세션 또한 JWT만큼 많이 사용되는 기술이다. JWT와 가장 큰 차이점은 저장소를 두고 인증 여부를 확인한다. User가 로그인을 하면 해당 User가 맞는지 확인 후 session을 생성한다. 그리고 유저에게는 sessionId을 리턴한 뒤 이후 요청에서는 cookie에 저장된 sessionId을 활용하여 인증을 유지한다.

 

동작방식

 

단점

 - 데이터 저장을 서버에 하면서 서버가 부하를 느낄 수 있다.

 - 저장소가 한곳 ?

    - 마찬가지고 저장소가 SPOF가 될수 있다.

 - 저장소가 여러곳 ?

    - 세션을 유지시키기 까다롭다.

 

ref

https://jwt.io

JWT.IO