[Etc] JWT(Json Web Token)

1. JWT

JWT는 상호 간에 정보를 JSON 개체로 안전하게 전송하기 위한 방법을 개방형 표준(RFC 7519) 입니다.

정보는 디지털 서명을 통해 신뢰성을 가지도록 하며 HMAC 알고리즘을 이용한 보안 방식과 RSA 또는 ECDSA 암호화 방식을 사용한 public/private key 페어 방식을 사용합니다.

 

JWT는 대표적으로 Authrization, Information Exchange 에 사용되는데 header와 payload를 사용하여 서명을 계산하므로 컨텐츠가 변조되지 않았는지 확인이 가능합니다.

 

 

2. 구조

JWT는 Header, Payload, Signature 로 구성되어있고 지정한 알고리즘으로 인코딩 된 형태를 하고 있습니다.

 

Header

헤더에는 일반적으로 토큰 유형(typ)과 사용되는 서명 알고리즘(alg)의 두 부분으로 구성됩니다.

{
  "alg": "HS256",
  "typ": "JWT"
}

 

Json 형태의 헤더를 Base64Url로 인코딩 되어 JWT의 첫 번째 부분을 구성하게 됩니다.

 

Payload

Payload는 클레임(Claim)을 포함하고 있는데

클레임은 일반적으로 엔티티(typically, the user)와 추가적인 데이터로 이루어져 있습니다.

클레임의 유형은 대표적으로 Registered claims, Public Claims, Private Claims 세 가지 유형이 있습니다.

(Okta에서는 Custom claims 를 추가적으로 정의하고 있어 일반적으로는 위 유형을 기본으로 하고 있습니다.)

 

a. Registered claims

이미 정의된 유형의 클레임 집합이며, 필수 값은 아니지만 권장되는 클레임모음입니다.

• iss (issuer) : JWT 발행자
• sub (subject) : 한글로 번역하면 주제이지만 어떤 의미로 사용되고있는지 살펴보면 특정 값, 예를들어 중복되지 않는 이메일 같은 값들을 넣는다고 한다. 예제를 보면 숫자 형태의 String 값이 들어가 있는데 String을 HashCode로 표현하는것 같습니다.
• aud (audience) : JWT 수신자
• exp (expiration time) : 토큰이 만료되는 시간
• nbf (not before time) : 특정 시간 전에는 승인을 하지않는 시간
• iat (issued at time) : 토큰이 발행된 시간
• jti (JWT ID) : 일회성 토큰인 경우 사용되는 값, 토큰의 고유 식별자를 나타내며 재사용을 방지하도록 합니다.

 

b. Pubilc claims

이름, 이메일과 같은 일반 정보가 포함될 수 있는 공개 사용을 위한 사용자 지정 클레임 모음입니다.

공개 클레임을 생성하는 경우 네임스페이스가 중복되지 않도록 IANA JSON Web Token Claims Registry에 등록하거나 네임스페이스를 포함하는 URI로 정의해야합니다.

{
  {url}: true,
  ...
}

 

c. Private claims

상호 간의 동의 또는 협의에 의해 생성된 맞춤 클레임 모음입니다.

Public claims 와 다른 점은 공개 정보가 아니기에 일반적인 클라이언트-서버 간 Web API 와 같은 느낌으로 보면 될듯합니다.

 

 

Signature

Signature를 생성하려면 인코딩된 Header, Payload와 Secret Key 를 헤더에서 지정된 알고리즘을 기반으로 만들어야합니다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

 

메세지가 도중에 변경되지 않았는지를 확인하는데 사용되며,

개인 키로 서명된 토큰의 경우 JWT를 보낸 사람이 누구인지 확인할 수 있습니다.

 

아래 예시를 보면 secret 값으로 hello와 world를 주었을때 signature 부분이 바뀌는 것을 볼수 있습니다.

 

 

header와 payload 부분에 따라서도 변경 되기 때문에 Signature 의 Secret Key 를 알아내기 어렵지만,

 

간혹 JWT 예제에 보면 [your-secret-key] 처럼 복사해서 바로 사용하는 경우가 많아 역으로 토큰에 대입하여 토큰을 풀어버리는 경우가 있기 때문에 Secret Key 는 꼭 복잡한 문자열 값으로 바꾸는 것을 권장합니다.

 

 

3. 장단점

서비스마다 상황이 다 다르고 기존 세션 방식과 토큰 방식의 차이가 있고 장 단점이 있기 때문에

JWT의 경우 어떤 장단점이 있는지 인지를 하고 사용하는 것이 좋습니다.

 

장점

• 데이터 위변조를 방지한다.
• 세션과 다르게 Stateless 상태로 인증 처리가 가능하다. (요청 시 토큰을 주고 받기 때문)
• Payload에 데이터가 들어있기 때문에 타 애플리케이션과도 호환이 용이하다.

 

단점

• 인증 정보가 많아지면 그만큼 네트워크 부하가 커진다.
• Payload 의 정보가 암호화 되는 것이 아니기에 보안이 취약할수 있다.
• 탈취된 토큰에 대한 처리가 어렵다.

 

JWT의 장점 중 하나인 Stateless 상태로 사용이 가능하다는 점인데,

 

대표적으로 많이 사용되는 Access, Refresh Token 방식에서 Refresh Token 이 유효한 토큰인지 Database에 조회하는 수가 많다면 세션을 사용하는 것보다 서버에 부하를 주기 때문에 이런 부분에서 유효기간은 어떻게 가져갈 것인지 또 어떻게 토큰을 주고 받을 것인지 생각해야할 부분이 많아집니다.

 

 

4. 마무리

이제는 계정은 간편로그인으로 인증은 JWT로 하는게 일반화 되는 추세이지만, 여전히 취약 부분이 존재하기 때문에 구현하면서 어떻게 하면 좀 더 안전하고 성능 상 유리할지 항상 고민 되는 부분인 것 같습니다.

 

 

5. 참고자료

https://jwt.io/

JWT.IO

https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-claims

Auth0