SMALL
  • JWT에 대한 간단한 정의
  • 기존 서버 기반 인증의 문제점 ( MSA 환경 )
  • JWT의 세부 구조 

 

JWT는 JSON Web Token의 약자로 

클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가를 위해 사용하는 토큰이다. 

URL에 대해 안전한 문자열로 구성되어 있어서 HTTP 어디든 ( URL, Header.. ) 토큰 정보가 위치할 수 있다.

 

기존의 권한 인증 인가는 대부분 서버 기반으로 이루어져 있었다. 

서버 기반의 권한 인증 인가는 MSA ( MicroService Architecture)에 적합하지 않아 그의 대안으로 JWT가 등장하였다.


기존 서버 기반 인증의 문제점

사용자 수가 늘어날수록 세션에 담아야 할 정보가 함께 증가하기 때문에 메모리 과부하 문제가 발생한다.

많은 트래픽을 감당하기 위해 프로세스를 늘리거나 서버 장비를 추가하는 경우 확장이 쉽지 않다.

쿠키는 단일 도메인 및 서브 도메인에서만 작동하기 때문에 여러 도메인에서 관리하는 것은 번거롭다.

즉, 서버 기반 인증인 세션과 쿠키는 MSA환경에 적합하지 않다.

 


JWT 인증 과정에 대한 간략 Flow

  • 사용자 로그인
  • 서버 : 사용자 정보 인증 -> 맞는 경우 클라이언트에게 signed token 발급 
    ( signed tocken : 정상 토큰인지 증면된 signature를 담고 있는 토큰) 
  • 클라이언트 : 서버로부터 받은 토큰 저장, 서버에 요청할 때마다 토큰을 서버에 전달
  • 서버 : 요청이 올 때마다 함께 전달된 토큰 검증 

JWT의 구조 

header, payload, signature로 이루어져 있고, 각각의 정보는 "."을 통해서 구분된다.

각각의 정보는 Base64 URL-Safe 인코딩 된 문자열이다.

header . payload . signature 

 

Header에는 JWT를 어떻게 검증하는가에 대한 내용을 담고 있다. 

{
    "type" : "JWT", // 토큰의 타입
    "ALG" : "H256" // 서명 시 사용하는 알고리즘 ( HMAC SHA256, RSA ) 
}

headerStr = Base64.encodeBase64URLSafeString(objectMapper.writeValueAsBytes(header));

Payload에는 토큰에 담을 정보가 포함되어있다.

토큰은 클레임으로 이루어져 있으며 "name : value" 쌍으로 이루어져 있다.

토큰 안에는 여러 개의 클레임을 넣을 수 있으며 크게 세 분류로 나눌 수 있다.

  • registered claim : 서비스에서 필요한 정보들이 아닌, 토큰에 대한 정보들을 담기 위해 이름이 이미 정해진 클레임이다.
  • public claim : 사용자 정의 클레임으로 공개용 정보를 위해 사용된다. 충돌 방지를 위해 URL 포맷을 이용해야 한다.
  • private claim : 서버와 클라이언트 사이에 임의로 지정한 정보를 저장하기 위해 만들어진 사용자 지정 클레임
{
    "iss": "joojoo.com",
    "exp": "1485270000000",
    "https://joojoo.com/jwt_claims/is_student": true,
    "userId": "11025454527102",
    "username": "joojoo"
}

payloadStr = Base64.encodeBase64URLSafeString(objectMapper.writeValueAsBytes(payload));

 

Signature에는 헤더의 인코딩 값, payload의 인코딩 값을 합친 후 주어진 비밀키로 해쉬를 하여 생성된 값이 들어있다. 

HMACHASH256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secretKey)

 

 

 

 

LIST

+ Recent posts