JWT (Json Web Token) 인증방식

오래 전에 초단기간 내에 REST Api를 이용해서 웹서비스를 개발해 달라는 요구사항을 받은 적이 있었는데 그때는 잘 모르는 상황에서 인터넷 검색에 의지하면서 겨우겨우 개발했던 기억이 있습니다. 

요구사항이 요상했는데 5개정도의 웹서비스를 요즘(요청당시) 유행하는 REST Api 방식으로 개발하고 토큰을 발행하지만 서버세션으로 사용자를 인증하고, 원타임 패스워드를 이용한 암호화를 하는데 실제 개발기간은 1주일 정도라는 말도 안 되는 요구사항이었습니다. (웃음) 
요구사항을 들을 당시는 단순하게 생각해서 그냥 넘어갔지만 토큰을 발행하는데 세션으로 권한관리를 해달라고 하니 무언가 이상했고 세션을 유지하기 위해 서비스 요청 시 헤더의 쿠키값을 유지해달라는 요구에 클라이언트들이 불만을 이야기 했습니다. (클라이언트 들은 웹브라우저/어플리케이션서버/앱)
결국 서버세션을 무시하고 토큰값으로 사용자인증를 처리하도록 개발했습니다. 아마도 JWT 토큰에 대한 이해가 서로 부족해서 그랬을 것이라 생각됩니다.

힘들었지만 재미있었던 당시 기억을 토대로 JWT에 대한 기록을 남깁니다.

 

특징 :
JSON 기반 웹 토큰
Claim 기반 (클라이언트에서 정보을 가지고 있음. 토큰에 필요한 정보를 다 가지고 있음.)
회원 로그인등 간단한 정보 공유에 사용

장점 : 
서버에 세션으로 관리되어서 나타나는 문제 해결
 - CSRF 문제
 - CORS, 도메인 확장 시 문제
 - 다양한 클라이언트 접속 문제
 - 서버 자원의 한계
REST API

※ CSRF : 사용자의 세션을 이용해서 의도하지 않은 서비스를 호출하는 것. 웹브라우저가 세션을 공유하면서 더 큰 문제가 됨.

단점 :
중요정보를 담을 수 없다. 
 - 누구나 정보를 볼 수 있기 때문 (중요정보의 경우 본문 암호화 필요)
인코딩을 함으로 인하여 데이터량이 늘어난다.
권한이 필요한 모든 요청에 토큰이 포함되어야 한다.
한번 발행된 토큰은 수정이 불가하다.
 - 토큰 만료일자로 관리필요
토큰을 클라이언트에서 저장해 놔야 한다.
토큰이 탈취당하는 경우 문제가 된다. 
 - 사실 이것이 가장 고민이 되는 것이였습니다. 토큰을 변경하는 것은 불가능 하지만 토큰이 가지고 있는 권한은 획득가능하니까요. 
 - 중요 데이터 암호화하여 피해를 줄일 수는 있다. 

 

구조 :
헤더 + '.' + 본문 + '.' + 사인

헤더 : 타입과 알고리즘
본문 : 아래 링크를 참조하거나 마음대로...
사인 : 헤더에 정의된 알고리즘으로 헤더. 본문을 해쉬 한 값
         - 서버만 가지고 있는 특정 키값을 포함하여 해쉬

언듯 보면 PKI 방식의 암호화 알고리즘과 형식이 비슷하다.

 

형식은 다음을 참조.

RFC-7519
https://www.rfc-editor.org/info/rfc7519

Information on RFC 7519 » RFC Editor

 

본문에 넣을만한 약속된 항목들

https://tools.ietf.org/html/draft-jones-json-web-token-07#section-4.1

draft-jones-json-web-token-07 - JSON Web Token (JWT)