# JSON Web Token (JWT)
##### 개요 (Abstract)
JSON Web Token (JWT)는 두 주체 사이에서 전달될 클레임(주장, 정보 조각)을 표현하기 위한 컴팩트하고 URL-안전한 형식이다. JWT 안의 클레임들은 JSON 객체로 인코딩되며, 이는 JSON Web Signature (JWS) 구조의 페이로드로 사용되거나 JSON Web Encryption (JWE) 구조의 평문으로 사용되어 디지털 서명되거나 메시지 인증 코드(MAC)로 무결성 보호되거나, 그리고/또는 암호화될 수 있다.
##### 메모 상태 (Status of This Memo)
이 문서는 인터넷 표준 트랙 문서(Internet Standards Track Document)이다.
이 문서는 IETF(Internet Engineering Task Force)의 산출물이며, IETF 커뮤니티 컨센서스를 반영한다. 공개 검토를 받았고 IESG(Internet Engineering Steering Group)의 승인을 받아 출판되었다. 인터넷 표준에 대한 추가 정보는 RFC 5741의 2절에서 확인할 수 있다.
이 문서의 현재 상태, 정오표(Errata), 그리고 피드백 제공 방법은 http://www.rfc-editor.org/info/rfc7519 에서 확인할 수 있다.
##### 저작권 고지 (Copyright Notice)
Copyright (c) 2015 IETF Trust 및 문서에 명시된 저자들. 모든 권리 보유.
이 문서는 출판 날짜에 유효한 BCP 78 및 IETF Trust의 "Legal Provisions Relating to IETF Documents"(http://trustee.ietf.org/license-info)의 적용을 받는다. 이 문서들을 주의 깊게 검토하라. 이들은 귀하가 이 문서와 관련하여 가지는 권리와 제한 사항을 설명한다. 이 문서에서 추출된 코드 컴포넌트는 Section 4.e의 Legal Provisions에서 기술된 Simplified BSD License 텍스트를 포함해야 하며 Simplified BSD License에 기술된 바와 같이 보증 없이 제공된다.
## 목차 (Table of Contents)
```
1. 소개 (Introduction)
1.1. 표기 규칙 (Notational Conventions)
2. 용어 (Terminology)
3. JSON Web Token (JWT) 개요
3.1. 예시 JWT (Example JWT)
4. JWT 클레임 (JWT Claims)
4.1. 등록된 클레임 이름 (Registered Claim Names)
4.1.1. "iss" (Issuer) 클레임
4.1.2. "sub" (Subject) 클레임
4.1.3. "aud" (Audience) 클레임
4.1.4. "exp" (Expiration Time) 클레임
4.1.5. "nbf" (Not Before) 클레임
4.1.6. "iat" (Issued At) 클레임
4.1.7. "jti" (JWT ID) 클레임
4.2. 공용(Public) 클레임 이름
4.3. 개인(Private) 클레임 이름
5. JOSE 헤더
5.1. "typ" (Type) 헤더 파라미터
5.2. "cty" (Content Type) 헤더 파라미터
5.3. 헤더 파라미터로 클레임 복제
6. 서명/암호화되지 않은(비보호) JWTs (Unsecured JWTs)
6.1. 예시 Unsecured JWT
7. JWT 생성 및 검증
7.1. JWT 생성
7.2. JWT 검증
7.3. 문자열 비교 규칙
8. 구현 요구사항
9. JWT 콘텐츠 선언을 위한 URI
10. IANA 고려사항
10.1. JSON Web Token Claims 레지스트리
10.1.1. 등록 템플릿
10.1.2. 초기 레지스트리 내용
10.2. Sub-Namespace 등록: urn:ietf:params:oauth:token-type:jwt
10.2.1. 레지스트리 내용
10.3. 미디어 타입 등록
10.3.1. 레지스트리 내용
10.4. 헤더 파라미터 이름 등록
10.4.1. 레지스트리 내용
11. 보안 고려사항
11.1. 신뢰 결정
11.2. 서명 및 암호화 순서
12. 프라이버시 고려사항
13. 참고 문헌 (References)
13.1. 표준 문헌 (Normative References)
13.2. 참고용 문헌 (Informative References)
부록 A. JWT 예시
A.1. 암호화된 JWT 예시
A.2. 중첩(Nested) JWT 예시
부록 B. JWT와 SAML 어서션 관계
부록 C. JWT와 SWT(Simple Web Tokens) 관계
감사의 글 (Acknowledgements)
저자 주소 (Authors' Addresses)
```
## 1. 소개 (Introduction)
JSON Web Token (JWT)는 HTTP Authorization 헤더나 URI 쿼리 파라미터처럼 공간이 제한된 환경을 위한 컴팩트한 클레임 표현 형식이다. JWT는 전달될 클레임을 JSON 객체(RFC7159)를 사용하여 인코딩하며, 이는 JSON Web Signature (JWS) 구조의 페이로드로 사용되거나 JSON Web Encryption (JWE) 구조의 평문으로 사용되어 디지털 서명 혹은 MAC을 통해 무결성 보호되고, 그리고/또는 암호화될 수 있다. JWT는 항상 JWS Compact Serialization 또는 JWE Compact Serialization을 사용해 표현된다.
JWT의 발음은 영어 단어 "jot"와 동일하게 추천된다.
### 1.1. 표기 규칙 (Notational Conventions)
본 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL"과 같은 키워드는 RFC 2119에 정의된 요구 수준을 나타내는 용어로 해석되어야 한다. 이러한 해석은 용어가 전부 대문자로 나타날 때만 적용된다.
## 2. 용어 (Terminology)
"JSON Web Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature", "Unsecured JWS" 용어는 JWS 명세에 의해 정의된다.
"JSON Web Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact Serialization", "JWE Encrypted Key", "JWE Initialization Vector" 용어는 JWE 명세에 의해 정의된다.
"Ciphertext", "Digital Signature", "Message Authentication Code (MAC)", "Plaintext" 용어는 "Internet Security Glossary, Version 2"(RFC4949)에 의해 정의된다.
이 명세에서 정의하는 용어:
JSON Web Token (JWT):
JWS 또는 JWE에 인코딩된 클레임 집합을 JSON 객체로 표현하는 문자열. 이를 통해 클레임이 디지털 서명 혹은 MAC 처리되고 그리고/또는 암호화될 수 있다.
JWT Claims Set:
JWT가 전달하는 클레임을 포함하는 JSON 객체.
Claim:
주체(subject)에 대해 주장되는 정보 조각. name/value 쌍(Claim Name, Claim Value)으로 표현된다.
Claim Name:
클레임 표현의 name 부분. 항상 문자열.
Claim Value:
클레임 표현의 value 부분. 임의의 JSON 값.
Nested JWT:
중첩 서명 및/또는 암호화가 사용되는 JWT. 내부 JWT가 외부 JWS/JWE 구조의 페이로드(서명)나 평문(암호화)으로 사용.
Unsecured JWT:
무결성 보호나 암호화가 적용되지 않은 JWT.
Collision-Resistant Name:
다른 이름과 충돌할 가능성이 매우 낮도록 이름을 할당할 수 있는 네임스페이스 내 이름. 예: 도메인 이름, OID, UUID(RFC4122). 위임된 네임스페이스 사용 시 이름 정의자는 자신이 사용하는 네임스페이스 부분을 통제하고 있음을 합리적으로 보장해야 한다.
StringOrURI:
임의 문자열(JSON string) 값. 단, 콜론(":") 문자를 포함하면 반드시 URI(RFC3986)이어야 한다. StringOrURI 값은 대소문자 구분 문자열로 비교되며 변환이나 정규화(canonicalization)를 적용하지 않는다.
NumericDate:
UTC 기준 1970-01-01T00:00:00Z부터 특정 UTC 날짜/시간까지의 초(second) 수를 나타내는 JSON 숫자 값(윤초 무시). IEEE Std 1003.1, 2013 Edition의 "Seconds Since the Epoch" 정의와 동일하나 비정수도 표현 가능. 날짜/시간과 UTC에 대한 일반 사항은 RFC3339 참조.
## 3. JSON Web Token (JWT) 개요 (Overview)
JWT는 클레임 집합을 JSON 객체로 표현하고 이를 JWS and/or JWE 구조에 인코딩한다. 이 JSON 객체가 JWT Claims Set이다. RFC7159 4절에 따라 JSON 객체는 0개 이상의 name/value 쌍을 포함하며, 이름은 문자열이고 값은 임의의 JSON 값이다. 이 JSON 객체는 RFC7159 2절에 따라 값이나 구조 문자 앞뒤에 공백이나 줄바꿈을 포함할 수 있다.
JWT Claims Set 안의 멤버 이름은 Claim Name이라 한다. 해당 값은 Claim Value라 한다.
JOSE 헤더 내용은 JWT Claims Set에 적용된 암호 연산을 설명한다. 헤더가 JWS용이면 JWT는 JWS로 표현되고 클레임은 디지털 서명 또는 MAC 처리되며 JWT Claims Set은 JWS Payload가 된다. 헤더가 JWE용이면 JWT는 JWE로 표현되고 클레임은 암호화되며 JWT Claims Set은 JWE가 암호화하는 평문이 된다. JWT는 또 다른 JWE 또는 JWS 구조 내부에 포함될 수 있어 Nested JWT를 형성하여 중첩 서명 및 암호화를 가능하게 한다.
JWT는 마침표('.') 문자로 구분된 URL-안전한 파트 시퀀스로 표현된다. 각 파트는 base64url 인코딩된 값을 포함한다. 파트 개수는 JWS Compact Serialization 또는 JWE Compact Serialization 표현 방식에 따라 달라진다.
### 3.1. 예시 JWT (Example JWT)
다음 JOSE 헤더는 인코딩된 객체가 JWT이며, JWT가 HMAC SHA-256 알고리즘으로 MAC 처리된 JWS임을 선언한다:
{"typ":"JWT",
"alg":"HS256"}
위 JSON 객체 표현의 잠재적 모호성을 제거하기 위해 UTF-8 옥텟 시퀀스를 아래에 포함한다. (플랫폼별 줄바꿈(CRLF vs LF), 라인 시작/끝 공백, 마지막 라인의 종료 줄바꿈 여부 등의 차이로 모호성이 발생할 수 있다.) 이 예제에서 사용된 UTF-8 표현의 옥텟(JSON 배열 표기)은:
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
이 UTF-8 표현 옥텟을 base64url 인코딩하면 다음 JOSE 헤더 인코딩 값이 된다:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
다음은 JWT Claims Set 예시이다:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
위 JWT Claims Set의 UTF-8 표현 옥텟 시퀀스(JWS Payload)는:
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
JWS Payload를 base64url 인코딩하면 (보기 편의를 위한 줄바꿈 포함):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
JOSE 헤더 인코딩 값과 JWS Payload 인코딩 값에 대해 HMAC SHA-256으로 MAC을 계산하고 그 값을 base64url 인코딩하면 다음 JWS Signature 인코딩 값이 된다:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
이 인코딩된 파트들을 마침표('.')로 연결하면 전체 JWT가 된다 (줄바꿈은 표시용):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
이 계산은 JWS 부록 A.1에 더 자세히 설명되어 있다. 암호화된 JWT 예시는 부록 A.1을 참조.
## 4. JWT 클레임 (JWT Claims)
JWT Claims Set은 JWT가 전달하는 클레임을 멤버로 갖는 JSON 객체다. JWT Claims Set 내부의 Claim Name은 고유해야 한다. JWT 파서는 중복 Claim Name이 있는 JWT를 거부하거나 ECMAScript 5.1 Section 15.12 규칙에 따라 마지막 중복 멤버만 반환하는 JSON 파서를 사용해야 한다.
특정 컨텍스트에서 JWT가 유효하다고 간주되기 위해 반드시 포함해야 하는 클레임 집합은 상황에 따라 달라지며 이 명세 범위를 벗어난다. 특정 응용은 일부 클레임을 특정 방식으로 처리해야 한다. 그러나 그러한 요구가 없다면 구현에서 이해하지 못한 클레임은 모두 무시(MUST)해야 한다.
JWT Claim Name은 세 가지 클래스가 있다: 등록된(Registered) 클레임 이름, 공용(Public) 클레임 이름, 개인(Private) 클레임 이름.
### 4.1. 등록된 클레임 이름 (Registered Claim Names)
다음 Claim Name들은 Section 10.1에서 설정한 IANA "JSON Web Token Claims" 레지스트리에 등록되어 있다. 아래 정의된 어떤 클레임도 모든 경우에 필수 사용을 의도하지 않는다. 대신 유용하고 상호운용 가능한 클레임 집합의 출발점을 제공한다. JWT를 사용하는 응용은 어떤 클레임을 언제 필수 또는 선택으로 사용할지 정의해야 한다. 모든 이름은 표현을 컴팩트하게 유지하기 위한 목적상 짧다.
#### 4.1.1. "iss" (Issuer) 클레임
"iss" 클레임은 JWT를 발행한 주체(principal)를 식별한다. 처리 방식은 일반적으로 애플리케이션 특정적이다. 값은 대소문자 구분 StringOrURI 문자열. 사용은 OPTIONAL.
#### 4.1.2. "sub" (Subject) 클레임
"sub" 클레임은 JWT의 주제(subject)를 식별한다. JWT의 클레임은 일반적으로 해당 subject에 대한 진술이다. subject 값은 issuer 문맥에서 로컬하게 유일하거나 전역적으로 유일해야 한다(MUST). 처리 방식은 애플리케이션 특정. 값은 대소문자 구분 StringOrURI 문자열. OPTIONAL.
#### 4.1.3. "aud" (Audience) 클레임
"aud" 클레임은 JWT를 처리하도록 의도된 수신자(recipient)를 식별한다. JWT를 처리하려는 각 주체는 audience 클레임 안의 값과 자신을 식별해야 한다(MUST). 처리 주체가 "aud" 클레임 존재 시 자신의 식별 값을 포함하지 않으면 JWT는 거부되어야 한다(MUST). 일반적으로 "aud" 값은 StringOrURI 문자열을 요소로 갖는 배열. 단일 audience인 경우 단일 문자열 허용. 해석은 애플리케이션 특정. OPTIONAL.
#### 4.1.4. "exp" (Expiration Time) 클레임
"exp" 클레임은 이 시간 이후(JWT를 처리하는 현재 시각이 exp보다 같거나 이후면 안 됨) JWT가 처리 수락되어서는 안 되는(MUST NOT) 만료 시간을 나타낸다. 처리 시 현재 시간은 "exp" 클레임 값보다 이전이어야 한다(MUST). 구현은 시계 불일치 보정용 몇 분 이내의 허용 오차(leeway)를 제공할 수 있다(MAY). 값은 NumericDate 숫자. OPTIONAL.
#### 4.1.5. "nbf" (Not Before) 클레임
"nbf" 클레임은 이 시간 이전에는 JWT가 처리 수락되어서는 안 되는(MUST NOT) 시간을 식별한다. 처리 시 현재 시간은 "nbf" 클레임 값보다 이후 또는 같아야 한다(MUST). 구현은 시계 불일치 보정용 소폭 허용 오차를 둘 수 있다(MAY). 값은 NumericDate 숫자. OPTIONAL.
#### 4.1.6. "iat" (Issued At) 클레임
"iat" 클레임은 JWT가 발행된 시각을 나타낸다. 이 클레임은 JWT의 경과 시간(나이)을 판단하는 데 사용 가능. 값은 NumericDate 숫자. OPTIONAL.
#### 4.1.7. "jti" (JWT ID) 클레임
"jti" 클레임은 JWT에 대한 고유 식별자를 제공한다. 식별자 값은 같은 값이 다른 데이터 객체에 우연히 할당될 확률이 매우 낮도록(MUST) 부여되어야 한다. 다중 issuer 사용하는 응용은 서로 다른 issuer가 생성한 값 충돌을 방지해야 한다(MUST). "jti"는 재사용 공격(replay)을 방지하는 데 사용 가능. 값은 대소문자 구분 문자열. OPTIONAL.
### 4.2. 공용(Public) 클레임 이름
클레임 이름은 JWT 사용자들이 임의로 정의할 수 있다. 그러나 충돌을 방지하려면 새 Claim Name은 IANA 레지스트리에 등록하거나 Section 10.1, 또는 공용 이름(Public Name)—Collision-Resistant Name을 포함하는 값을 사용해야 한다. 각 경우 이름 정의자는 자신이 사용하는 네임스페이스 부분을 통제하고 있음을 합리적으로 보장해야 한다.
### 4.3. 개인(Private) 클레임 이름
JWT 생산자와 소비자는 등록된(4.1) 또는 공용(4.2) 클레임이 아닌 Private Name을 클레임 이름으로 사용하기로 합의할 수 있다(MAY). Public Claim Name과 달리 Private Claim Name은 충돌 위험이 있으므로 주의해서 사용해야 한다.
## 5. JOSE 헤더
JWT 객체에서 JOSE 헤더로 표현되는 JSON 객체 멤버는 JWT에 적용된 암호 연산과 선택적으로 추가 속성을 설명한다. JWT가 JWS인지 JWE인지에 따라 해당 JOSE 헤더 규칙이 적용된다.
이 명세는 JWT가 JWS이든 JWE이든 모두에 대해 다음 헤더 파라미터 사용을 추가 규정한다.
### 5.1. "typ" (Type) 헤더 파라미터
"typ" 헤더 파라미터(JWS/JWE에서 정의)는 JWT 응용이 이 전체 객체의 미디어 타입을 선언하는 데 사용된다. JWT가 아닐 수도 있는 값들이 존재할 수 있는 데이터 구조에서 객체 종류를 판별하기 위해 사용할 수 있다. 이미 JWT임이 알려진 경우 일반적으로 사용되지 않는다. 이 파라미터는 JWT 구현에 의해 무시된다; 처리 로직은 JWT 응용이 수행. 존재 시 값으로 "JWT"를 사용하는 것이 권장(RECOMMENDED). 미디어 타입 이름은 대소문자 구분하지 않지만 레거시 호환성 위해 대문자 "JWT" 사용 권장. OPTIONAL.
### 5.2. "cty" (Content Type) 헤더 파라미터
"cty" 헤더 파라미터(JWS/JWE 정의)는 이 명세에서 JWT 구조 정보를 전달하는 데 사용된다.
중첩 서명/암호화가 없는 일반 경우 사용은 권장되지 않는다(NOT RECOMMENDED). 중첩 서명 또는 암호화를 사용하는 경우 MUST 존재해야 하고 값은 "JWT"여야 한다. 상호운용성 위해 대문자 사용 권장(RECOMMENDED). 예시는 부록 A.2 참조.
### 5.3. 헤더 파라미터로 클레임 복제
암호화된 JWT를 사용하는 일부 응용에서 특정 클레임을 암호화되지 않은 형태로 갖는 것이 유용할 수 있다. 이는 복호화 전에 처리 여부나 방법을 결정하기 위한 규칙에 사용될 수 있다.
이 명세는 필요한 경우 JWT Claims Set에 존재하는 클레임을 JWE인 JWT 헤더 파라미터로 복제하는 것을 허용한다. 복제된 클레임이 존재하면 수신 응용은 값이 동일한지 확인해야 한다(SHOULD), 단 응용이 다른 처리 규칙을 정의하는 경우는 예외. 응용은 암호화되지 않은 상태로 전송해도 안전한 클레임만 복제하도록 책임을 진다.
Section 10.4.1은 암호화된 JWT에서 암호화되지 않은 복제본 제공을 위해 "iss", "sub", "aud" 헤더 파라미터 이름을 등록한다. 다른 명세도 필요 시 등록된 클레임 이름을 헤더 파라미터 이름으로 등록할 수 있다.
## 6. Unsecured JWTs (비보호 JWT)
JWT 내용이 JWT 내부 서명/암호화 외의 다른 수단으로 보호되는 사용 사례(예: JWT를 포함하는 데이터 구조에 대한 별도의 서명)를 지원하기 위해, 서명이나 암호화 없이도 JWT를 생성할 수 있다(MAY). Unsecured JWT는 JWA 명세에서 정의한 "alg" 헤더 값 "none"을 사용하는 JWS이며 JWS Signature 값은 빈 문자열이다. 즉 JWT Claims Set이 JWS Payload인 Unsecured JWS.
### 6.1. 예시 Unsecured JWT
다음 JOSE 헤더는 인코딩 객체가 Unsecured JWT임을 선언한다:
{"alg":"none"}
UTF-8 표현 옥텟을 base64url 인코딩하면 JOSE 헤더 인코딩 값은:
eyJhbGciOiJub25lIn0
다음은 JWT Claims Set 예시:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
JWT Claims Set UTF-8 옥텟을 base64url 인코딩한 JWS Payload (줄바꿈은 표시용):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
JWS Signature 인코딩 값은 빈 문자열.
마침표로 연결하면 전체 JWT (줄바꿈 표시용):
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
## 7. JWT 생성 및 검증
### 7.1. JWT 생성
JWT 생성 단계 (입출력 의존성이 없는 경우 순서 중요하지 않음):
1. 원하는 클레임을 포함하는 JWT Claims Set 생성. 공백 허용, 인코딩 전 정규화 필요 없음.
2. Message를 JWT Claims Set의 UTF-8 표현 옥텟으로 설정.
3. 원하는 헤더 파라미터를 포함하는 JOSE 헤더 생성. JWT는 JWS 또는 JWE 명세를 따라야 함(MUST). 공백 허용, 정규화 필요 없음.
4. JWT가 JWS인지 JWE인지에 따라:
* JWS이면 Message를 JWS Payload로 하여 JWS 생성. JWS 생성 단계(JWS 명세) 모두 따라야 함(MUST).
* JWE이면 Message를 JWE 평문으로 하여 JWE 생성. JWE 생성 단계(JWE 명세) 모두 따라야 함(MUST).
5. 중첩 서명/암호화 수행할 경우 Message를 그 JWS 또는 JWE로 설정하고 3단계로 돌아가 "cty" 값을 "JWT"로 설정.
6. 그렇지 않으면 결과 JWT는 해당 JWS 또는 JWE.
### 7.2. JWT 검증
검증 단계 (입출력 의존 없으면 순서 중요하지 않음). 어느 단계라도 실패하면 JWT는 거부(MUST) (즉 응용에서 무효 입력 취급).
1. JWT가 최소 한 개의 마침표('.')를 포함하는지 확인.
2. Encoded JOSE Header를 첫 마침표 이전 부분으로 설정.
3. Encoded JOSE Header를 base64url 디코딩(줄바꿈/공백/추가 문자 금지)한다.
4. 결과 옥텟 시퀀스가 완전히 유효한 JSON 객체(RFC7159)를 UTF-8로 인코딩한 것인지 검증하고 JOSE Header로 설정.
5. JOSE Header가 이해 및 지원하거나(구문/의미) 이해되지 않아도 무시하기로 지정된 파라미터와 값만 포함하는지 검증.
6. Section 9 of JWE에 기술된 방법 중 하나로 JWT가 JWS인지 JWE인지 판별.
7. JWT 유형에 따라:
* JWS면 JWS 검증 단계(JWS 명세) 수행. Message를 JWS Payload base64url 디코딩 결과로 설정.
* JWE면 JWE 검증 단계(JWE 명세) 수행. Message를 복호화된 평문으로 설정.
8. JOSE Header에 "cty" 값 "JWT"가 있으면 Message는 중첩 서명/암호화 대상이었던 JWT이므로 1단계로 돌아가 Message를 새로운 JWT로 사용.
9. 그렇지 않으면 Message를 base64url 디코딩(줄바꿈/공백/추가 문자 없음).
10. 결과 옥텟 시퀀스가 완전히 유효한 JSON 객체(RFC7159) UTF-8 표현인지 검증하고 JWT Claims Set으로 설정.
마지막으로 어떤 알고리즘이 특정 컨텍스트에서 사용 가능한지는 응용 결정이다. JWT가 성공적으로 검증되더라도 사용된 알고리즘이 응용에서 허용되지 않으면 응용은 JWT를 거부해야 한다(SHOULD).
### 7.3. 문자열 비교 규칙
JWT 처리 시 JSON 객체 멤버와 값에 대해 알려진 문자열 비교가 필요하다. 예를 들어 알고리즘을 확인하기 위해 Unicode 문자열 "alg"를 JOSE Header 멤버 이름과 비교.
JSON 멤버 이름 비교 규칙은 RFC7159 8.3절에 있다. 동등/비동등 비교만 수행되므로 같은 규칙을 멤버 이름과 값 비교 모두에 사용할 수 있다.
이 비교 규칙은 멤버 값 정의가 다른 비교 규칙 사용을 명시하지 않는 한 모든 JSON 문자열 비교에 MUST 적용된다. 이 명세에서 "typ"와 "cty" 멤버 값만 예외.
일부 응용은 대소문자 구분 값 안에 대소문자 구분 없는 정보를 포함할 수 있다(예: "iss" 값 일부로 DNS 이름). 그런 경우 다수 주체가 동일 값을 독립적으로 생성하여 비교해야 하면 소문자화 등 표준 표기 규칙을 정의해야 할 수 있다. (다른 모든 주체가 생산자가 출력한 값을 그대로 소비하고 독립적으로 생산한 값과 비교하지 않는다면 대소문자 표기는 중요하지 않음.)
## 8. 구현 요구사항 (Implementation Requirements)
이 절은 어떤 알고리즘과 기능이 구현 필수인지 정의한다. 응용은 추가 요구를 부과할 수 있다. 예: 한 응용은 암호화된 JWT와 Nested JWT 지원 요구, 다른 응용은 ES256(ECDSA P-256 + SHA-256) 서명을 요구.
JWA 명세에 지정된 서명 및 MAC 알고리즘 중 HMAC SHA-256("HS256")과 "none"만이 표준 준수 JWT 구현에서 MUST 구현이다. 구현이 RS256(RSASSA-PKCS1-v1_5 + SHA-256)과 ES256(ECDSA P-256 + SHA-256)도 지원하는 것이 권장(RECOMMENDED). 다른 알고리즘과 키 크기 지원은 OPTIONAL.
암호화된 JWT 지원은 OPTIONAL. 암호화 기능 제공 시 JWA 명세 암호화 알고리즘 중 RSAES-PKCS1-v1_5 2048-bit("RSA1_5"), AES Key Wrap 128/256("A128KW", "A256KW"), AES-CBC + HMAC SHA-2 조합("A128CBC-HS256", "A256CBC-HS512")이 MUST 구현. ECDH-ES를 사용한 키 합의로 CEK 래핑("ECDH-ES+A128KW", "ECDH-ES+A256KW") 및 AES GCM 128/256("A128GCM", "A256GCM") 지원 권장(RECOMMENDED). 기타 알고리즘/키 크기 지원 OPTIONAL.
Nested JWT 지원 OPTIONAL.
## 9. JWT 콘텐츠 선언을 위한 URI
이 명세는 URN "urn:ietf:params:oauth:token-type:jwt"를 등록하여 URI로 콘텐츠 타입을 선언하는 응용이 해당 콘텐츠가 JWT임을 나타내도록 한다.
## 10. IANA 고려사항 (IANA Considerations)
### 10.1. JSON Web Token Claims 레지스트리
이 절은 JWT Claim Name을 위한 IANA "JSON Web Token Claims" 레지스트리를 설정한다. 레지스트리는 Claim Name과 이를 정의하는 명세 참조를 기록한다. 이 절은 Section 4.1에 정의된 Claim Name을 등록한다.
값은 Specification Required(RFC5226) 기준으로 등록되며 3주 검토 기간을 거치며, Designated Expert 조언에 따른다. 출판 이전 값 할당 허용을 위해 Designated Expert는 해당 명세가 출판될 것이라 확신하면 등록 승인 가능.
검토를 위한 메일링 리스트(jwt-reg-review@ietf.org)로 전송되는 등록 요청은 적절한 제목 사용 (예: "Request to register claim: example").
검토 기간 내 Designated Expert는 승인 또는 거절을 메일링 리스트와 IANA에 통지. 거절 시 설명과(가능하다면) 성공 가능성 높이는 제안 포함. 21일 넘게 미결정인 등록 요청은 IESG(iesg@ietf.org)로 문제 제기 가능.
Designated Expert 적용 기준: 기존 기능 중복 여부, 일반 적용 가능성 또는 단일 응용 전용인지 여부, 등록 설명 명확성.
IANA는 Designated Expert로부터만 레지스트리 업데이트를 수락해야 하며 모든 등록 요청을 검토 메일링 리스트로 안내.
다양한 응용 관점을 대표할 수 있는 다수 Designated Expert를 임명하여 폭넓은 정보에 기반한 검토를 가능케 하는 것이 제안된다. 이해충돌로 인지될 수 있는 등록 결정 사례에서는 해당 Expert가 다른 Expert 판단에 양보해야 한다.
#### 10.1.1. 등록 템플릿 (Registration Template)
Claim Name:
요청 이름 (예: "iss"). 컴팩트 표현 목표 때문에 이름은 8자를 넘지 않는 것이 권장(RECOMMENDED) (강한 이유가 없다면). 대소문자 구분. Designated Expert가 강한 이유로 예외 허용을 언급하지 않는 한 다른 등록 이름과 대소문자 구분 없이 일치해서는 안 됨.
Claim Description:
클레임에 대한 간단한 설명 (예: "Issuer").
Change Controller:
표준 트랙 RFC는 "IESG" 기재. 기타는 책임 당사자 이름. 추가 세부(주소, 이메일, 홈 페이지 URI) 포함 가능.
Specification Document(s):
파라미터를 지정하는 문서 참조(가능하면 URI 포함). 관련 절 표시 가능(필수 아님).
#### 10.1.2. 초기 레지스트리 내용 (Initial Registry Contents)
o Claim Name: "iss"
o Claim Description: Issuer
o Change Controller: IESG
o Specification Document(s): Section 4.1.1 of RFC 7519
o Claim Name: "sub"
o Claim Description: Subject
o Change Controller: IESG
o Specification Document(s): Section 4.1.2 of RFC 7519
o Claim Name: "aud"
o Claim Description: Audience
o Change Controller: IESG
o Specification Document(s): Section 4.1.3 of RFC 7519
o Claim Name: "exp"
o Claim Description: Expiration Time
o Change Controller: IESG
o Specification Document(s): Section 4.1.4 of RFC 7519
o Claim Name: "nbf"
o Claim Description: Not Before
o Change Controller: IESG
o Specification Document(s): Section 4.1.5 of RFC 7519
o Claim Name: "iat"
o Claim Description: Issued At
o Change Controller: IESG
o Specification Document(s): Section 4.1.6 of RFC 7519
o Claim Name: "jti"
o Claim Description: JWT ID
o Change Controller: IESG
o Specification Document(s): Section 4.1.7 of RFC 7519
### 10.2. Sub-Namespace 등록: urn:ietf:params:oauth:token-type:jwt
#### 10.2.1. 레지스트리 내용
"An IETF URN Sub-Namespace for OAuth"(RFC6755)에서 설정한 IANA "OAuth URI" 레지스트리에 "token-type:jwt" 값을 등록한다. 이는 콘텐츠가 JWT임을 나타내는 데 사용.
o URN: urn:ietf:params:oauth:token-type:jwt
o Common Name: JSON Web Token (JWT) Token Type
o Change Controller: IESG
o Specification Document(s): RFC 7519
### 10.3. 미디어 타입 등록 (Media Type Registration)
#### 10.3.1. 레지스트리 내용
이 절은 "application/jwt" 미디어 타입(RFC2046)을 RFC6838 절차에 따라 "Media Types" 레지스트리에 등록한다. 이는 콘텐츠가 JWT임을 나타내는 데 사용.
o Type name: application
o Subtype name: jwt
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: 8bit; JWT 값은 마침표('.')로 구분된 base64url 인코딩 값 시리즈(일부는 빈 문자열일 수 있음)로 인코딩.
o Security considerations: RFC 7519 보안 고려사항 절 참조
o Interoperability considerations: n/a
o Published specification: RFC 7519
o Applications that use this media type: OpenID Connect, Mozilla Persona, Salesforce, Google, Android, Windows Azure, Amazon Web Services 등 다수
o Fragment identifier considerations: n/a
o Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com
o Change controller: IESG
o Provisional registration? No
### 10.4. 헤더 파라미터 이름 등록
이 절은 Section 4.1에 정의된 특정 Claim Name을 JWE에서 클레임 복제 헤더 파라미터 용도로 JWS 명세(JWS]에서 설정한 IANA "JSON Web Signature and Encryption Header Parameters" 레지스트리에 등록한다.
#### 10.4.1. 레지스트리 내용
o Header Parameter Name: "iss"
o Header Parameter Description: Issuer
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.1.1 of RFC 7519
o Header Parameter Name: "sub"
o Header Parameter Description: Subject
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.1.2 of RFC 7519
o Header Parameter Name: "aud"
o Header Parameter Description: Audience
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.1.3 of RFC 7519
## 11. 보안 고려사항 (Security Considerations)
모든 암호 응용 관련 보안 이슈는 JWT/JWS/JWE/JWK 에이전트가 해결해야 한다. 여기에는 사용자의 비대칭 개인키 및 대칭 비밀 키 보호, 다양한 공격에 대한 대응책 등이 포함된다.
JWS 명세의 모든 보안 고려사항은 JWT에도 적용되며 암호화를 사용할 경우 JWE 보안 고려사항도 적용된다. 특히 JWS Section 10.12(JSON Security Considerations)와 10.13(Unicode Comparison Security Considerations)은 JOSE 헤더와 동일 방식으로 JWT Claims Set에도 동일하게 적용.
### 11.1. 신뢰 결정 (Trust Decisions)
JWT 내용은 그 내용이 신뢰 결정에 필요한 컨텍스트에 암호학적으로 안전하게 결합되지 않은 경우 신뢰할 수 없다. 특히 서명 및/또는 암호화에 사용된 키가 JWT 발행자로 식별된 주체의 통제 하에 있음이 검증 가능해야 한다.
### 11.2. 서명 및 암호화 순서 (Signing and Encryption Order)
Nested JWT에서 서명 및 암호화 연산은 문법적으로 어떤 순서로든 적용 가능하지만, 둘 다 필요한 경우 일반적으로 먼저 서명 후 암호화(서명 값도 암호화)해야 한다. 이는 서명을 제거하고 암호화된 메시지만 남기는 공격을 예방하고 서명자 프라이버시 제공. 또한 암호문에 대한 서명은 많은 법적 관할에서 유효하지 않게 간주.
서명 후 암호화 순서 관련 잠재적 보안 우려는 이미 기반 JWS/JWE 명세에서 해결됨. 특히 JWE가 인증된 암호화(authenticated encryption) 알고리즘만 지원하므로 많은 문맥에서 암호화 후 서명 필요성 관련 암호학적 우려가 이 명세에는 적용되지 않는다.
## 12. 프라이버시 고려사항 (Privacy Considerations)
JWT는 프라이버시 민감 정보(privacy-sensitive)를 포함할 수 있다. 그런 경우 의도되지 않은 당사자에게 정보가 노출되지 않도록 조치 MUST. 한 방법은 암호화된 JWT 사용과 수신자 인증. 다른 방법은 민감 정보가 암호화되지 않은 JWT를 TLS 같이 암호화 및 엔드포인트 인증을 지원하는 프로토콜로만 전달. 민감 정보를 JWT에서 생략하는 것이 프라이버시 이슈 최소화의 가장 단순한 방법.
## 13. 참고 문헌 (References)
### 13.1. 표준 문헌 (Normative References)
[ECMAScript]
Ecma International, "ECMAScript Language Specification, 5.1 Edition", ECMA Standard 262, June 2011, <http://www.ecma-international.org/ecma-262/5.1/ECMA-262.pdf>.
[IANA.MediaTypes]
IANA, "Media Types", <http://www.iana.org/assignments/media-types>.
[JWA]
Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[JWE]
Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[JWS]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC20]
Cerf, V., "ASCII format for Network Interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC2046]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC4949]
Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC7159]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[UNICODE]
The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
### 13.2. 참고용 문헌 (Informative References)
[CanvasApp]
Facebook, "Canvas Applications", 2010, <http://developers.facebook.com/docs/authentication/canvas>.
[JSS]
Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", September 2010, <http://jsonenc.info/jss/1.0/>.
[MagicSignatures]
Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic Signatures", January 2011, <http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html>.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[POSIX.1]
IEEE, "The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition, 2013, <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15>.
[RFC3275]
Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, DOI 10.17487/RFC3275, March 2002, <http://www.rfc-editor.org/info/rfc3275>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC4122]
Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC5226]
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC6755]
Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <http://www.rfc-editor.org/info/rfc6755>.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[SWT]
Hardt, D. and Y. Goland, "Simple Web Token (SWT)", Version 0.9.5.1, November 2009, <http://msdn.microsoft.com/en-us/library/windowsazure/hh781551.aspx>.
[W3C.CR-xml11-20060816]
Cowan, J., "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation REC-xml11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816>.
[W3C.REC-xml-c14n-20010315]
Boyer, J., "Canonical XML Version 1.0", W3C Recommendation REC-xml-c14n-20010315, March 2001, <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
## 부록 A. JWT 예시 (Appendix A. JWT Examples)
이 절은 JWT 예시를 포함한다. 다른 예시는 Section 6.1 및 JWS 부록 A.1 - A.3 참조.
### A.1. 암호화된 JWT 예시 (Example Encrypted JWT)
이 예시는 Section 3.1 클레임을 수신자에게 RSAES-PKCS1-v1_5 및 AES_128_CBC_HMAC_SHA_256을 사용해 암호화한다.
다음 JOSE 헤더는 선언한다:
o 콘텐츠 암호화 키(CEK)는 RSAES-PKCS1-v1_5 알고리즘으로 수신자에게 암호화되어 JWE Encrypted Key 생성.
o 평문은 AES_128_CBC_HMAC_SHA_256 인증 암호화로 처리되어 JWE Ciphertext와 JWE Authentication Tag 생성.
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
평문으로 Section 3.1 JWT Claims Set UTF-8 옥텟을 사용한다는 점을 제외하면 계산은 JWE 부록 A.2(JWE]와 동일하며 사용한 키도 동일.
최종 결과 (줄바꿈 표시용):
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDhzjAD26ima
sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
1rZgN5TiysnmzTROF869lQ.
AxY8DCtDaGlsbGljb3RoZQ.
MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8.
fiK51VwhsxJ-siBMR-YFiA
### A.2. 중첩 JWT 예시 (Example Nested JWT)
이 예시는 JWT가 JWE 또는 JWS의 페이로드로 사용되어 Nested JWT를 형성하는 방법을 보여준다. 이 경우 JWT Claims Set이 먼저 서명된 후 암호화된다.
내부 서명된 JWT는 JWS 부록 A.2 예시와 동일하므로 계산은 반복하지 않는다. 이 예시는 내부 JWT를 RSAES-PKCS1-v1_5 및 AES_128_CBC_HMAC_SHA_256으로 암호화.
다음 JOSE 헤더는 선언한다:
o CEK는 RSAES-PKCS1-v1_5 알고리즘으로 수신자에게 암호화되어 JWE Encrypted Key 생성.
o 평문은 AES_128_CBC_HMAC_SHA_256 인증 암호화로 처리되어 JWE Ciphertext와 JWE Authentication Tag 생성.
o 평문 자체가 JWT.
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
JOSE 헤더 UTF-8 옥텟 base64url 인코딩 값:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
계산은 JWE 부록 A.2와 동일하지만 JOSE 헤더, 평문, IV, CEK 값이 다름 (RSA 키 동일).
평문은 JWS 부록 A.2.1 끝의 JWT ASCII(RFC20) 표현(공백/줄바꿈 제거) 458 옥텟.
JWE Initialization Vector(JSON 배열):
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]
사용된 CEK(base64url 인코딩):
GawgguFyGrWKav7AX4VKUg
최종 Nested JWT (줄바꿈 표시용):
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldU
In0.
g_hEwksO1Ax8Qn7HoN-BVeBoa8FXe0kpyk_XdcSmxvcM5_P296JXXtoHISr_DD_M
qewaQSH4dZOQHoUgKLeFly-9RI11TG-_Ge1bZFazBPwKC5lJ6OLANLMd0QSL4fYE
b9ERe-epKYE3xb2jfY1AltHqBO-PM6j23Guj2yDKnFv6WO72tteVzm_2n17SBFvh
DuR9a2nHTE67pe0XGBUS_TK7ecA-iVq5COeVdJR4U4VZGGlxRGPLRHvolVLEHx6D
YyLpw30Ay9R6d68YCLi9FYTq3hIXPK_-dmPlOUlKvPr1GgJzRoeC9G5qCvdcHWsq
JGTO_z3Wfo5zsqwkxruxwA.
UmVkbW9uZCBXQSA5ODA1Mg.
VwHERHPvCNcHHpTjkoigx3_ExK0Qc71RMEParpatm0X_qpg-w8kozSjfNIPPXiTB
BLXR65CIPkFqz4l1Ae9w_uowKiwyi9acgVztAi-pSL8GQSXnaamh9kX1mdh3M_TT
-FZGQFQsFhu0Z72gJKGdfGE-OE7hS1zuBD5oEUfk0Dmb0VzWEzpxxiSSBbBAzP10
l56pPfAtrjEYw-7ygeMkwBl6Z_mLS6w6xUgKlvW6ULmkV-uLC4FUiyKECK4e3WZY
Kw1bpgIqGYsw2v_grHjszJZ-_I5uM-9RA8ycX9KqPRp9gc6pXmoU_-27ATs9XCvr
ZXUtK2902AUzqpeEUJYjWWxSNsS-r1TJ1I-FMJ4XyAiGrfmo9hQPcNBYxPz3GQb2
8Y5CLSQfNgKSGt0A4isp1hBUXBHAndgtcslt7ZoQJaKe_nNJgNliWtWpJ_ebuOpE
l8jdhehdccnRMIwAmU1n7SPkmhIl1HlSOpvcvDfhUN5wuqU955vOBvfkBOh5A11U
zBuo2WlgZ6hYi9-e3w29bR0C2-pp3jbqxEDw3iWaf2dc5b-LnR0FEYXvI_tYk5rd
_J9N0mg0tQ6RbpxNEMNoA9QWk5lgdPvbh9BaO195abQ.
AVO9iT5AV4CzvDJCdhSFlQ
## 부록 B. JWT와 SAML 어서션 관계
SAML 2.0은 JWT보다 더 풍부한 표현력과 많은 보안 옵션을 가진 보안 토큰 표준을 제공한다. 그러나 이 유연성과 표현력의 비용은 크기와 복잡성이다. SAML은 XML과 XML 디지털 서명(XML DSIG)을 사용하여 어서션 크기를 키우며 XML 및 특히 XML Canonicalization 사용이 복잡성을 증가시킨다.
JWT는 HTTP 헤더와 URI 쿼리 인자에 들어갈 만큼 작은 단순 보안 토큰 형식을 제공하려 한다. 이를 위해 SAML보다 단순한 토큰 모델을 지원하고 JSON 객체 인코딩 구문을 사용한다. 또한 MAC와 디지털 서명을 XML DSIG보다 작고 덜 유연한 형식으로 지원한다.
따라서 JWT가 SAML 어서션 일부 기능을 수행할 수 있으나 JWT는 SAML 어서션의 완전한 대체를 의도하지 않는다. 대신 구현 용이성이나 compactness가 고려될 때 사용할 토큰 형식.
SAML 어서션은 항상 주체에 대해 엔티티가 한 진술이다. JWT도 종종 동일 방식으로 사용되며 "iss" 클레임이 진술 엔티티, "sub" 클레임이 subject를 나타낸다. 하지만 이 클레임이 OPTIONAL이라 JWT 형식의 다른 사용도 허용된다.
## 부록 C. JWT와 SWT(Simple Web Tokens) 관계
JWT와 SWT 모두 응용 간 클레임 집합 전달을 가능하게 한다. SWT는 클레임 이름과 값 모두 문자열. JWT는 이름은 문자열이지만 값은 임의 JSON 타입 가능. 두 토큰 타입 모두 내용 암호학적 보호 제공: SWT는 HMAC SHA-256, JWT는 다양한 알고리즘(서명, MAC, 암호화) 선택 가능.
## 감사의 글 (Acknowledgements)
저자들은 JWT 설계가 SWT 설계와 단순성에서 의도적으로 영향을 받았음을 인정한다. 또한 Dick Hardt가 OpenID 커뮤니티에서 논의한 JSON 토큰 아이디어에도 영향 받았다.
JSON 콘텐츠 서명 솔루션은 Magic Signatures, JSON Simple Sign, Canvas Applications에서 이전에 탐구되었으며 이 문서에 영향을 미쳤다.
이 명세는 OAuth 워킹 그룹의 산물로 수많은 적극적이고 헌신적인 참여자가 포함된다. 특히 다음 개인들이 아이디어, 피드백, 문구로 기여했다:
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Warren Kumari, Ben Laurie, Barry Leiba, Ted Lemon, James Manger, Prateek Mishra, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, David Recordon, Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig, Sean Turner, Tom Yu.
Hannes Tschofenig과 Derek Atkins가 OAuth 워킹 그룹을 의장으로 이끌었고 Sean Turner, Stephen Farrell, Kathleen Moriarty가 이 명세 작성 동안 Security Area Director로 활동.
## 저자 주소 (Authors' Addresses)
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley
Ping Identity
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura
Nomura Research Institute
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/