JWT(Json Web Token)완전 정복

개념

 

JWT( JSON Web Token)은 정보를 JSON 객체로 안전하게 전달하기 위한 간결하고 자체 포함형 방식을 정의한 개방형 표준(RFC 7519)이다. 이 정보는 디지털로 서명되어 검증되고 신뢰할 수 있다.

서명된 토큰은 내부에 포함된 클레임의 무결성을 검증할 수 있으며, 공개/개인 키 쌍으로 토큰을 서명하면 해당 서명은 개인 키를 가지고 있는 당사자만이 서명한 것임을 인증한다.

 

RFC 7519?

JSON Web Token (JWT) 표준을 정의하는 문서.

RFC 7519 문서는 JWT의 구조, 서명 방식, 유효성 검증, 기타 관련 사항들을 자세히 설명하고 있으며, 웹 기반 애플리케이션과 서비스에서 인증과 정보 교환을 위해 널리 사용되고 있다.

 

 

언제 JSON Web Token을 사용해야 할까?

1. 권한부여 (Authorization)

사용자가 로그인한 후, 이후의 각 요청은 JWT를 포함하며, 해당 토큰으로 허용된 라우트, 서비스 및 리소스에 접근할 수 있고

Single Sign On (SSO) 기능을 구현하는데 적합하며, 작은 오버헤드와 다양한 도메인에서 쉽게 사용할 수 있는 특징.

 

2. 정보 교환(Information Exchange)

당사자 간에 안전하게 정보를 전송하는 좋은 방법이며 JWT는 공개/개인 키 쌍을 사용하여 서명될 수 있기 때문에, 발신자가 스스로를 주장하는 사람임을 확신할 수 있다. 또한, 서명은 헤더와 페이로드를 사용하여 계산되므로, 내용이 변경되지 않았음을 검증할 수 있다.

 

 

 

Token구조

JSON Web Token (JWT)은 다음과 같이 세 개의 점(.)으로 구분된 세 부분으로 구성되어 있다.

1. 헤더(Header)

헤더에는 일반적으로 두 가지 정보가 포함된다.

첫 번째는 토큰의 타입으로 "JWT"라는 문자열이 들어가며, 두 번째는 사용되는 서명 알고리즘으로 HMAC SHA256 또는 RSA와 같은 알고리즘이 포함된다.

 

EX : 

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

2. 페이로드(Payload)

토큰의 두 번째 부분은 페이로드로, 클레임(claim)들을 포함한다.

클레임은 주로 사용자와 관련된 정보 및 추가 데이터를 담고 있으며 세 가지 종류의 클레임이 있다.

• 등록된 클레임(Registered claims)
  - Ex : "iss" (발급자), "exp" (만료 시간), "sub" (주제), "aud" (사용자)
• 공개 클레임(Public claims)
  - 원하는대로 정의할 수 있지만 충돌을 피하기 위해 이들은 IANA JSON Web Token Registry에 정의되거나 충돌이 발생하지 않도록 보호되는 네임스페이스를 포함하는 URI로 정의.
• 개인 클레임(Private claims)
  - 등록된 클레임도 아니고 공개 클레임도 아닌, 특정 당사자 간에 정보를 공유하기 위해 만들어지는 사용자 정의 클레임

JWT의 형태

xxxxx.yyyyy.zzzzz

xxxxx는 헤더를, yyyyy는 페이로드를, zzzzz는 서명을 나타내며 각각의 부분은 Base64Url로 인코딩되어 있다.

 

IANA JSON Web Token Registry?

IANA JSON Web Token (JWT) Registry는 JWT에서 사용되는 클레임들과 알고리즘들을 등록하고 관리하는 레지스트리. IANA(Internet Assigned Numbers Authority)는 인터넷 프로토콜과 관련하여 다양한 매개변수들을 관리하고 표준화하기 위해 사용되는 권위 있는 기관.

 

 

JWT의 동작 방식

출처 : https://jwt.io/introduction

1. 인증(authentication) 과정에서 사용자가 자격 증명(credential)을 사용하여 성공적으로 로그인하면 JSON Web Token(JWT)이 반환.

※주의 

토큰은 자격 증명으로 간주되기 때문에 보안 문제를 방지하기 위해 매우 신중하게 다루어져야 하며 일반적으로 필요 이상으로 토큰을 보관하지 않도록 주의해야 함. 또한, 브라우저 저장소에 민감한 세션 데이터를 저장해서는 안된다.

 

resorce 접근 시 사용자 에이전트(user agent)는 일반적으로 Bearer 스키마를 사용하여 JWT를 Authorization 헤더에 담아서 Request

 

Authorization: Bearer <token>

1. 서버의 보호된 라우트는 Authorization 헤더에 유효한 JWT가 있는지 확인하고, 있을 경우 사용자가 보호된 리소스에 접근할 수 있도록 허용한다.

2. JWT 토큰이 Authorization 헤더에 포함되어 전송되면 Cross-Origin Resource Sharing(CORS)는 문제가 되지 않는다.

3. 일부 서버는 헤더에서 8KB 이상을 허용하지 않을 수 있다.

 

JWT를 사용해야 하는 이유

JSON Web Tokens (JWT)와 Simple Web Tokens (SWT) 및 Security Assertion Markup Language Tokens (SAML)을 비교했을 때의 이점.

1. 크기와 효율성:
   • JSON은 XML보다 덜 장황하며, 인코딩되었을 때 크기도 더 작다. 이로 인해 JWT는 SAML보다 더 간결하고 이러한 특성은 HTML과 HTTP 환경에서 JWT를 전달하기에 적합하도록 만듭니다.
2. 보안:
   • SWT는 공유된 비밀 키를 사용하여 대칭 서명만 지원합니다. 그러나 JWT와 SAML 토큰은 공개/개인 키 쌍인 X.509 인증서를 사용하여 서명할 수 있습니다. JSON으로 서명하는 것이 XML로 서명하는 것보다 간단하므로 XML Digital Signature를 도입하지 않고 애매한 보안 취약점을 만들지 않으면서 서명하는 것은 어렵습니다.
3. 파싱 및 처리의 용이성:
   • 대부분의 프로그래밍 언어에서 JSON 파서는 일반적으로 사용되며, JSON은 직접 객체로 매핑됩니다. 반면에 XML은 자연스러운 문서-객체 매핑을 가지고 있지 않습니다. 이로 인해 JWT 작업이 SAML Assertion 작업보다 쉽습니다.
4. 사용 범위:
   • JWT는 인터넷 규모에서 사용됩니다. 이는 다양한 플랫폼에서 특히 모바일에서 JSON 웹 토큰을 쉽게 클라이언트 측에서 처리할 수 있다는 것을 강조합니다.