JWT는 Json Web Token의 약자로 JSON 웹 토큰은 Json을 이용해 정보를 안전하게 다루기 위한 개방형 표준 (RFC 7519) 방법입니다. JWT는 크게 헤더, 내용, 서명으로 나뉘어지며 .
으로 각 부분을 구분합니다. 각 부분은 전부 base64로 인코딩되어 사용됩니다.
헤더는 일반적으로 다음과 같이 구성됩니다.
{ "typ":"JWT", "alg":"HSA256", }
typ : 데이터 타입입니다. 여기선 당연히 JWT입니다.
alg : 해쉬 알고리즘입니다. 서명 부분을 암호화하는데 쓰입니다.
iss : 이 데이터의 발행자를 뜻합니다. iat : 이 데이터가 발행된 시간을 뜻합니다. exp : 이 데이터가 만료된 시간을 뜻합니다. sub : 토큰의 제목입니다.
payload에 들어갈 정보들은 claim이라 부릅니다. 이 claim들은 크게 세 종류로 나뉩니다.
첫 번째는 등록된 클레임(registered claims)입니다. 사전 정의되어 있고 필수적으로 사용할 필요는 없지만 강력하게 사용이 권고되는 것들입니다. 이 주소에서 자세히 볼 수 있습니다.
iss
: 이 데이터의 발행자를 뜻합니다.
iat
: 이 데이터가 발행된 시간을 뜻합니다.
exp
: 이 데이터가 만료된 시간을 뜻합니다.
sub
: 토큰의 제목입니다.
aud
: 토큰의 대상입니다.
nbf
: 토큰이 처리되지 않아야 할 시점을 의미합니다.
이 시점이 지나기 전엔 토큰이 처리되지 않습니다.
jti
: 토큰의 고유 식별자입니다.
두 번째는 공개 클레임(public claims)입니다. 사용자 마음대로 쓸 수 있으나 충돌 방지를 위해 여기에 정의된대로 사용하는 게 좋습니다. 그렇지 않다면 URI 형식으로 키를 정해야 합니다.
세 번째는 비공개(private claims)입니다. 통신을 주고받는 당사자들끼리 협의해서 자유롭게 키와 값을 정할 수 있습니다.
서명은 다음과 같은 방법으로 만들어집니다.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
JWT는 주로 인증과정에 많이 쓰입니다. 여기서 JWT를 사용하는 이유는 여러 면에서 인터넷 환경에 SWT(Simple Web Token)과 SAML(Security Assertion Markup Language Tokens)보다 더 적합하기 때문입니다. JSON은 XML보다 단순하기 때문에 용량도 작고 간편합니다. 따라서 XML 기반의 SAML 방식보다 크기가 작습니다. 보안 측면에서 SWT방식은 대칭키 방식인 HMAC 방식으로 해싱하지만 JWT와 SAML 토큰은 x.509인증서 형식의 공개키/개인키 방식을 쓸 수 있습니다. 인증 과정에서 대칭키 방식은 인증 확인자가 같은 키로 데이터를 만들어 다른 인증 확인자에게 잘못 사용할 수 있는 문제가 있습니다. 또한 인증 과정은 확인자가 데이터를 생성할 필요 없이 확인만 하면 되기 때문에 공개키/개인키 방식이 적합합니다. 또한 JSON은 그 구조상 대부분 언어에서 객체로 바로 변환될 수 있기 때문에 대부분의 언어에서 지원하고 있습니다. XML로는 대부분 언어와 JSON처럼 바로 객체에 매핑되기 어렵다는 점도 JWT 사용에 한몫합니다.
이 글 내용의 대부분은 두 번째 참조 링크 내용의 번역입니다. 개인 공부 정리 목적으로 작성되어 잘못된 점이 있을 수 있으며 여기에 대한 지적은 댓글로 남겨주시면 감사하겠습니다.
https://velopert.com/2389
https://jwt.io/introduction/
https://meetup.toast.com/posts/239
https://cryptocat.tistory.com/3
http://wiki.hash.kr/index.php/%EB%8C%80%EC%B9%AD%ED%82%A4_%EC%95%94%ED%98%B8_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98