[CSSU] JWT(JSON Web Token)

 

두 번째 주제 - JWT(JSON Web Token)

1. RFC 문서 내용

 

간단히 요약하면, 두 그룹간에 JWT를 통해 디지털 서명이나 무결성 보호를 한다.

음.. 위에서 보면 JWS / JWE 등 어려운 설명이 많다. 이제 차차 알아갈거니까 지금은 그냥 보고 넘어가자.

"API 통신을 위해 인증된 사용자인지 체크하는 토큰이 JWT"

라는 것만 일단 알고 밑으로 내려가자.

 

※ RFC란 Request for Comments의 약자로써, 컴퓨터 네트워크 공학 등에서 인터넷 기술에 적용 가능한 새로운 연구, 혁신, 기법 등을 아우르는 메모를 나타낸다. JWT는 RFC의 Internet Standard에 속한다.

※ Internet Standard란 RFC의 종류로써, 이런 종류들이 있다.

오늘은 RFC에 대해서 정리하는 것이 아니니까 더 알아보고 싶은 분은 여기 참고^^

ktword.co.kr/abbr_view.php?nav=&m_temp1=177&id=420

RFC [정보통신기술용어해설]

 

2. JWT 토큰이란 무엇일까?

 (1) JWT란 JSON 객체로 된 정보를 치밀하고 독립적인 방법으로 서로 간에 안전하게 전송하는 것을 말한다.

 (2) JWT는 디지털적으로 서명되어 안전한데, HMAC 알고리즘의 암호화나 RSA, ECDSA 공개/개인키방식을 사용하여 서명된다.

 (3) 토큰으로 무결성을 확인할 수 있지만, 개인키를 보유한 서버빼고 모두에게 데이터를 숨긴다.

위의 세 가지가 JWT의 공식사이트에 나온 요약이다.

이걸 보면 아직 잘 모르겠다. 특히 2번이 문제인데, 어떻게 서명되어서 어떻게 암호화되어 안전하게 되는지 알아보자.

 

 (2) - 1. MAC

  HMAC을 알려면 MAC부터 알아야한다. MAC이 무엇일까?

  MAC은 Message Authentication Code로써, 메세지 인증에 쓰이는 작은 크기의 정보이다.

  아... 이걸 공부하니까 해시함수의 정확한 요약 정의를 알겠넹 ㅎ;; - 안에서 어떻게 움직이는지도 한번 알아봐야겠다.

※ 해시함수란? 임의의 길이를 가진 메세지를 일정 길이(n비트)의 메세지로 변환하는 함수 - 대표적인 예로 SHA256이 있다.

  자, 이 MAC은 어떤 한 메세지를 통해서 만들어진다.

  송신자는 MAC 알고리즘과 시크릿 키 값으로 메세지 값을 MAC으로 만들어낼 수 있다.

  그러면 이 MAC과 메세지를 같이 수신자에게 보낸다.

  수신자는 해당 메세지를 수신자가 가지고 있는 MAC 알고리즘과 시크릿 키 값으로 MAC을 만들어 내고,

  송신자에게 받은 MAC과 수신자가 만들어 낸 MAC이 같은지를 비교하게 된다.

  같다면 정상적인(인증된) 송수신이라는 것을 알게 된다.

 

위키가 짱이쥬?

그림 출처: https://en.wikipedia.org/wiki/Message_authentication_code

Message authentication code - Wikipedia

 

 (2) - 2. HMAC

 HMAC은 해시라는 것이 MAC에 붙은 것이다.

 해쉬 키와 알고리즘을 통해 MAC을 만들어내고 메세지와 MAC을 비교하는 것!

 MAC과 해시를 이해한다면 HMAC의 개념은 따라온다고 보면 된다.

 

3. JWT! 그래서 뭐라고?

 위는 요약을 한번 보고 자그만 설명을 덧붙였을 뿐이다.

 그럼 JWT는 뭘까? 사실, 우리가 주로 쓰고 있는 JWT는 JWS이다.

 이 말이 무엇이냐면, JWT는 종류가 여러 개라는 말이다.

 JWT는 추상클래스라고 보면 된다. 현재 나뉘는 JWT는 JWS와 JWE가 있다.

 우리는 주로 JWS를 사용하고 있어서 몰랐을 뿐이다.

 그래서 JWS와 JWE의 차이만 알고, JWS인 JWT를 사용한다고 말하면 될 것 같다.

 

 (1). JWS vs JWE

  (1)-1. 구조

  일단 구조부터 다르다. JWS는 JOSE header, payload, signature 구조로 되어 있다면,

  JWE는 JOSE header, Encrypted Key, Initialization vector, Additional Authentication Data (AAD), Ciphertext, JWE Authentication Tag구조로 되어있다.

  (1)-2. 표현 형식

   "xxxxx.xxxxxx.xxxxxx" 형식과 "xxxxx.xxxxxx.xxxxxx.xxxxxx.xxxxxx" 형식의 다른점을 찾으면 알 수 있다.

   구조가 JWS 3개, JWE 6개로 다르다보니, 각 파트마다 닷(.)으로 구분한다. 그래서 닷(.)의 개수를 보면 바로 구분 가능하다.

   하지만 위에서 보면 오른쪽의 닷으로 나뉘어져있는 것은 5개이다.

   이는 마지막 나뉘어진 부분에 Ciphertext, JWE Authentication Tag가 같이 처리되기 때문이다.

  (1)-3. 각 파트의 역할 및 차이점

   음... 잘 모르겠다. JWS의 헤더, 페이로드, 서명을 JWE가 나눠서 저렇게 구분을 하는건데, 보안적으로 더 뛰어나다는 소리도 있다.

   이번엔 JWS를 끝까지 파헤쳐볼 것이기 때문에 JWE는 이정도만 알고 넘어가자. 더 알고 싶은 사람은 밑의 문서를 보면 된다.

https://datatracker.ietf.org/doc/html/rfc7516

rfc7516

 

 (2). JWS 구조 파헤치기

 앞서 말했듯이 JWS는 세 가지로 나뉜다.

 "JOSE Header", "Payload", "Signature"

공식문서를 참조해서 파헤쳐보자!

https://jwt.io/introduction

JWT.IO

  (2)-1. Header

  헤더에는 "typ"과 "alg"라는게 들어간다.

  "typ"은 어떤 유형(데이터 타입)인지를 나타내는 것이고 "alg"는 어떤 알고리즘을 적용할지 정하는 곳이다.

  대표적으로 RS256(RSA SHA256 - 공개키 방식)과 HS256(HMAC SHA256 - 대칭키 방식)을 쓴다.

  다 작성되면 Base64Url 인코딩을 한다.

  (2)-2. Payload

  페이로드도 이런 형식으로 작성되는데, 안에 있는 키값들은 정해져 있다.

  정해져 있는 것을 클레임 셋이라고 하는데, 이 클레임 셋들을 사용해서 작성하는게 낫다.

  위에 "name"과 "admin"은 클레임 셋이 아닌데도 들어가 있는걸 보면 클레임 셋이 아니라도 작성은 할 수 있는 것 같다.

  마찬가지로 다 작성되면 Base64Url 인코딩을 한다.

  ※참고: 밑에는 정해진 클레임 셋을 볼 수 있다.

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1

rfc7519

  (2)-3. Signature

  마지막 서명은 이런 형식이다. 위의 헤더와 페이로드를 인코딩한 것을 시크릿(솔팅 비슷한 개념)을 추가하여

  시크릿 키를 알고 있는 사람인지 판별할 수 있게 만든다.

  즉, 밑의 서명이 정확해야 이 키는 진정한 JWT라고 볼 수 있는 안전장치인 셈이다.

 

이렇게 JWT를 만들 수 있는데, 실제로 해볼 수 있는 사이트가 있다.

https://jwt.io/#debugger-io 

JWT.IO

 

위 사이트에 들어가면 밑의 사진처럼 해볼 수 있으니 한 번 경험하고 코딩하길 권장한다.

 

좀 더 알아볼 점은 Base64URL 인코딩에 대해서 알아보면 좋을 것 같다.

다음 주제는 Base64URL 인코딩일 수도? ㅎㅎ

 

부족한 점이나 틀린 점이 있으면 댓글 부탁드립니다.

피드백 주신다면 정말 감사히 받아들이고 수정하겠습니다.