alclssha 2022. 12. 26. 02:03

JWT

  • Json Web Token의 약자
  • Json 포맷을 이용해 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token
  • 모바일이나 웹의 사용자 인증을 위해 사용하는 암호화된 토큰을 의미
  • 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달
  • JWT 정보를 request에 담에 사용자용 정보 열람, 수정 등 개인적인 작업 등을 수행 가능하게 함

 

*) Claim 기반 : Claim이라는 사용자에 대한 프로퍼티나 속성을 이야기 함, 토큰 자체가 정보를 가지고 있는 방식

 

JWT구조

  • JWT는 세 파트로 나뉨
  • 각 파트는 .(점)으로 구분
  •  aaaaa.bbbbb.ccccc 이런식으로 표현
  • URL에서 파라미터로 사용할 수 있도록 URL_Safe한 Base64url 인코딩을 사용
  • 생성된 토큰은 HTTP통신을 할 때 Authorization이라는 key의 value로 사용
  • 일반적으로 value에는 Bearer이 앞에 붙여짐

 

 

Header

토큰의 헤더는 typ과 alg 두가지 정보로 구성
  • alg : Signature를 해싱하기 위한 알고리즘을 지정
    • Signature 및 토큰 검증에 사용
    • ex) RSA, HS256 등
  • typ : 토큰의 타입을 지정
    • ex) JWT
{
	"alg": "RSA",
    	"typ": JWT
}

 

 

Payload

토큰의 페이로드에는 토큰에서 사용할 정보의 조각들인 Claim이 담김
Claim은 총 3가지로 나뉘고, Json 형태로 다양한 정보를 넣을 수 있음

 

Registered Claim(등록된 클레임)

토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터
모두 선택적으로 작성 가능
JWT를 간결하게 하기 위해 key는 모두 길이 3의 String

 

  • iss: 토큰 발급자(issuer)
  • sub: 토큰 제목(subject)
  • aud: 토큰 대상자(audience)
  • exp: 토큰 만료 시간(expiration), NumericDate 형식
    • ex) 1480849147370
  • nbf: 토큰 활성 날짜(not before)
    • 이 날이 지나기 전의 토큰은 활성화되지 않음
  • iat: 토큰 발급 시간(issued at)
    • 토큰 발급 이후의 경과 시간을 알 수 있음
  • jti: JWT 토큰 식별자(JWT ID)
    • 중복 방지를 위해 사용
    • 일회용 토큰(Access Token) 등에 사용

 

Public Claim(공개 클레임)

  • 사용자 정의 클레임
  • 공개용 정보를 위해 사용
  • 충동방지를 위해 URI포맷을 이용
{
	"https://gkdlstod.tistory.com": true
}

 

Private Claim(비공개 클레임)

  • 사용자 정의 클레임
  • 서버와 클라이언트 사이에 임의로 지정한 정보를 저장
{
	"token_type": access
}

 

 

Signature

토큰을 인코딩하거나 유효성 검증을 할 때 사용되는 고유한 암호화 코드

만들어낸 Header와 Payload의 값을 각각 Base64Url로 인코딩

인코딩한 값을 비밀 키를 이용해 Header에서 정의한 알고리즘으로 해싱

이 값을 다시 Base64Url로 인코딩하여 생성

 

 

장점

  • 사용자 인증에 필요한 모든 정보를는 토큰 자체에 포함되어 있기 때문에 별도의 인증 저장소가 필요하지 않음
    • 서버자원을 절약
    • 인증과정에 효율적
    • 서버 부하를 줄이기 좋은 방식
  •  쿠키를 전달하지 않아도 됨으로써 쿠키 사용시 발생하는 취약점을 보안
  • JSON 코드 언어로 생성되어 용량이 작기 때문에, 두 개체 사이에서 매우 빠르게 전달
  • 거의 모든 곳에서 토큰 생성이 가능하고, 서버에서 토큰을 확인할 필요가 없어짐

 

단점

  • Self-contained
    • 토큰 자체에 정보를 담고 있으므로 토큰을 보낼 때 위험성 존재
  • 토큰 길이
    • 토큰의 Payload에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있음
  • Payload 인코딩
    • Payload 자체는 암호화 된 것이 아니라, BASE64로 인코딩 된 것
    • 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 함
  • Stateless
    • JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능
    • 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 함
  • Tore Token
    • 토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 함

 

 

기존의 인증/인가 방식과의 차이

  • 서버 기반 인증 기존의 인증 시스템에서는 서버측에서 유저들의 정보를 세션에 기억하고 있어야 함
  • 세션을 유지하기 위해서는 메모리/디스크/DB 시스템에 이들을 담음

 

  • 토큰 기반 시스템은 stateless함
  • 유저의 인증 정보를 서버나 세션에 담아두지 않음
  • 인증정보를 서버에 담아둠으로써 발생하는 많은 문제점들이 해결됨

 

 

JWT의 사용

  1. 회원인증
    • JWT를 사용하는 가장 흔한 경우
    • 사용자가 로그인 -> 서버는 사용자 기반으로한 토큰 발급
    • 그 후 사용자가 서버에 요청 할 때마다 JWT를 포함하여 전달
    • 서버 클라이언트에서 요청 받을때 마다, 해당 토큰이 유효하고 인증되었는지 검증
    • 사용자가 요청한 작업에 권한이 있는지 확인하고 작업을 처리
  2. 정보 교류
    • JWT가 두 개체 사이에서 안정성있게 정보를 교환하기 때문에 사용
      • 정보가 서명이 되어있기 때문에 중간에 바뀌었는지, 보낸 사람이 바뀌었는지 등을 검증 가능