JWT

jwt.io/introduction

JWT.IO

발번역 주의!

 

JWT(JSON Web Token)란?

 

오픈 스탠다드이다.

파티들 간에 안전하게 정보를 JSON object로서 전송하는 컴팩트하지만 할건 다 해주는 방법이다.

그 정보들은 인증되고 믿을수 있다. 그것이 디지털로 서명되기 때문이다.

JWT들은 secret을 사용함으로써 인증된다. (HMAC 알고리즘과 함께)

혹은 RSA나 EXDSA를 사용하는 public/private 키 쌍을 사용할 수도 있다.

 

JWT가 파티들간 비밀을 제공하기 위해 암호화될 수 있다고 하지만, 우리는 서명된 토큰들에 집중할 것이다.

서명된 토큰들은 그 안에 포함되어 있는 클레임들의 무결성을 인증할 수 있다.

반면에 암호화된 토큰들은 클레임들을 다른 파티들로부터 숨긴다.

토큰들이 public/private 키쌍을 사용함으로써 서명되면 signature는 오직 그 private key를 들고 있는 파티만이 그것을 서명한 파티라는 것을 인증한다.

 

JWT를 언제 쓰나요?

 

허가

JWT를 쓰는 가장 흔한 예시이다.

유저가 한 번 로그인하면, 각각의 후속적 요청이 그 유저를 경로, 서비스, 리소스들로 (각각을 허가하는 토큰들과 함께) 접근할 수 있게 허가하는 JWT를 포함할 것이다.

싱글 사인 온은 오늘날 JWT를 널리 사용하는 피처이다.

고정비용이 작아서 상이한 도메인들 사이에서 그것의 기능이 쉽게 쓰일 수 있다.

 

정보교환

JSON Web Token은 파티들 간에 안전하게 정보를 전송하는 좋은 방법이다.

JWT가 서명될 수 있기 때문에(가령, public/private key를 사용함으로써) 당신은 전송자의 신원을 확인할 수 있다.

이외에도, 헤더와 페이로드를 사용함으로써 시그니처가 계산되기 때문에, 당신은 내용이 변경되지는 않았는지 확인할 수 있다.

 

쓰다보니 여기서부터 존댓말 주의 ㅋㅋ

 

JSON Wen Token 구조는?

JSON Web Token은 세 개의 파트로 구성되어있습니다. 각 파트는 점으로 분리됩니다.

• Header
• Payload
• Signature

그래서 JWT는 아래와 같이 생겼습니다.

xxxxx.yyyyy.zzzzz

 

Header

헤더는 전형적으로 두개의 파트로 구성됩니다.

토큰의 타입(JWT), 그리고 서명에 사용되는 알고리즘입니다. 알고리즘에는 HMAC SHA256 혹은 RSA 등이 있습니다.

 

예를 들어

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

이렇게 되면 이 JSON은 JWT의 첫번째 파트로 인코딩된 Base64Url이 됩니다.

 

Payload

토큰의 두번째 부분입니다. 클레임을 담고 있죠.

클레임은 엔티티와 관련된 선언들입니다.(전형적으로 user) 그리고 추가적인 데이터와 관련된 선언이구요.

 

클레임의 세 가지 타입이 있습니다 : registered, public, private

 

Registered claims: 미리 정의된 클레임들의 셋입니다. 

필수적인건 아니지만 추천됩니다. 유용하고 호환이 잘되는 클레임들의 셋을 제공하기 위해 말이죠.

그 중에선 iss(issuer), exp(expiration time), sub(subject), aud(audienced) 등등이 있습니다.

 

Public claims: JWT를 사용하는 사람들에 의해 마음대로 정의될 수 있습니다. 충돌을 피하기 위해 그들은 IANA JSON Web Token Registry 혹은 충돌방지 네임스페이스를 포함한 URI로 정의되어야 합니다.

 

Private claims : 커스텀 클레임입니다. registered 혹은 public 클레임 어느 쪽도 아닌 Private 클레임을 사용하는 것에 동의하는 파티들간에 정보를 공유하기 위해 만들어졌습니다. 

 

payload의 예시는 다음과 같을 수 있습니다.

{
  "sub": "1234567890",
  "name:": "John Doe"
  "admin": true
}

이 페이로드는 이제 JSON Web Token의 두번째 부분이 되도록 인코딩된 Base64Url이 됩니다.

 

Signature

시그니처 부분을 만들기 위해서는 인코딩된 헤더, 인코딩된 페이로드, 시크릿, 헤더에서 구체화된 알고리즘을 취해야 하며 그것을 서명해야 합니다.

예를 들어 당신이 HMAC SHA256 알고리즘을 쓰고 싶다면, 그 시그니처는 다음과 같이 만들어질 수 있습니다.

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

이 시그니처는 메시지가 도중에 변경되지 않았다는 것을 확인하는데 쓰입니다.

그리고 private key로 서명된 토큰의 경우, JWT의 송신자가 누군지도 확인할 수 있습니다.

 

다 함께 모아보면

이전의 인코딩된 헤더와 페이로드를 가지고 있는 JWT입니다. 그것은 secret과 함께 서명됩니다.

 

 

JSON Web Tokens를 왜 써야 하나요?

Single Web Token(SWT)나 Security Assertion Markup Language Tokens(SAML)과 비교해서 JWT가 어떠한 이점이 있는지 알아봅시다.

JSON은 XML보다 덜 장황합니다. 인코딩된 사이즈 또한 더 작고 SAML보다 더 컴팩트합니다. HTML과 HTTP 환경에서 JWT는 좋은 선택이 됩니다.

 

보안에 좋습니다. SWT는 HMAC 알고리즘을 사용하여 공유된 시크릿과 대칭적으로만 서명될 수 있습니다. 하지만 JWT와 SAML 토큰은 X.509 증명서 형태의 public/private key 쌍을 사용할 수 있습니다. 애매한 보안 구멍을 소개하지 않고 XML을 XML 디지털 시그니처로 서명하는 것은 매우 어렵습니다. JSON에 서명하는 단순함과 비교했을 때요.

 

JSON parser는 대부분의 프로그래밍 언어에서 흔합니다. 왜냐하면 그들은 객체들을 직접 연결하기 때문입니다. 반대로, XML은 내추럴한 document-to-object 매핑이 없습니다. 이래서 SAML assertion보다 JWT와 일하기 더 쉽습니다.

 

사용법에 관하여, JWT는 Internet 규모에 사용됩니다. 이래서 JSON Web Token은 다양한 플랫폼, 특히 모바일에서의 client-side 프로세싱에서 이점이 있습니다.