[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Updated by: 7797, 8725 Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7519 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON Web Token (JWT)
초록
JSON Web Token(JWT)은 두 당사자 간에 전달될 클레임을 표현하기 위한
간결하고 URL 안전한 수단이다. JWT의 클레임은 JSON 객체로 인코딩되며,
이는 JSON Web Signature(JWS) 구조의 페이로드로 사용되거나 JSON Web
Encryption(JWE) 구조의 평문으로 사용되어, 클레임을 디지털 서명하거나
메시지 인증 코드(MAC)를 통해 무결성을 보호하고/또는 암호화할 수 있게 한다.
이 메모의 상태
본 문서는 인터넷 표준 트랙 문서이다.
본 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물이다.
이는 IETF 커뮤니티의 합의를 대표한다. 공개 검토를 거쳤으며,
인터넷 엔지니어링 스티어링 그룹(IESG)에 의해 출판 승인을 받았다.
인터넷 표준에 대한 추가 정보는 RFC 5741의 2절에서 확인할 수 있다.
본 문서의 현재 상태, 모든 정오표, 그리고 이에 대한 피드백 제공 방법에 대한
정보는 다음에서 확인할 수 있다.
http://www.rfc-editor.org/info/rfc7519.
Jones, et al. Standards Track [Page 1]
RFC 7519 JSON Web Token (JWT) May 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones, et al. Standards Track [Page 2]
RFC 7519 JSON Web Token (JWT) May 2015
목차
1. 서론 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 표기 규칙 . . . . . . . . . . . . . . . . . . . . . . . 4
2. 용어 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. JSON Web Token(JWT) 개요 . . . . . . . . . . . . . . . . . . 6
3.1. JWT 예제 . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWT 클레임 . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. 등록된 클레임 이름 . . . . . . . . . . . . . . . . . . 9
4.1.1. "iss"(발급자) 클레임 . . . . . . . . . . . . . . . . 9
4.1.2. "sub"(주체) 클레임 . . . . . . . . . . . . . . . . . 9
4.1.3. "aud"(대상) 클레임 . . . . . . . . . . . . . . . . . 9
4.1.4. "exp"(만료 시각) 클레임 . . . . . . . . . . . . . . 9
4.1.5. "nbf"(유효 시작 시각) 클레임 . . . . . . . . . . . . 10
4.1.6. "iat"(발급 시각) 클레임 . . . . . . . . . . . . . . . 10
4.1.7. "jti"(JWT ID) 클레임 . . . . . . . . . . . . . . . . 10
4.2. 공개 클레임 이름 . . . . . . . . . . . . . . . . . . . 10
4.3. 비공개 클레임 이름 . . . . . . . . . . . . . . . . . . 10
5. JOSE 헤더 . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. "typ"(타입) 헤더 매개변수 . . . . . . . . . . . . . . . 11
5.2. "cty"(콘텐츠 타입) 헤더 매개변수 . . . . . . . . . . . 11
5.3. 클레임을 헤더 매개변수로 복제하기 . . . . . . . . . . 12
6. 비보안 JWT . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. 비보안 JWT 예제 . . . . . . . . . . . . . . . . . . . 12
7. JWT 생성 및 검증 . . . . . . . . . . . . . . . . . . . . 13
7.1. JWT 생성 . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. JWT 검증 . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. 문자열 비교 규칙 . . . . . . . . . . . . . . . . . . . . 15
8. 구현 요구 사항 . . . . . . . . . . . . . . . . . . . . . . 16
9. 콘텐츠가 JWT임을 선언하기 위한 URI . . . . . . . . . . . 17
10. IANA 고려 사항 . . . . . . . . . . . . . . . . . . . . . . 17
10.1. JSON Web Token 클레임 레지스트리 . . . . . . . . . . . 17
10.1.1. 등록 템플릿 . . . . . . . . . . . . . . . . . . . . 18
10.1.2. 초기 레지스트리 내용 . . . . . . . . . . . . . . . . 18
10.2. urn:ietf:params:oauth:token-type:jwt
하위 네임스페이스 등록 . . . . . . . . . . . . . . . . 19
10.2.1. 레지스트리 내용 . . . . . . . . . . . . . . . . . . 19
10.3. 미디어 타입 등록 . . . . . . . . . . . . . . . . . . . 20
10.3.1. 레지스트리 내용 . . . . . . . . . . . . . . . . . . 20
10.4. 헤더 매개변수 이름 등록 . . . . . . . . . . . . . . . 20
10.4.1. 레지스트리 내용 . . . . . . . . . . . . . . . . . . 21
11. 보안 고려 사항 . . . . . . . . . . . . . . . . . . . . . . 21
11.1. 신뢰 결정 . . . . . . . . . . . . . . . . . . . . . . 21
11.2. 서명 및 암호화 순서 . . . . . . . . . . . . . . . . . . 21
12. 개인정보 보호 고려 사항 . . . . . . . . . . . . . . . . . 22
13. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. 규범적 참고 문헌 . . . . . . . . . . . . . . . . . . . 22
13.2. 정보 제공 참고 문헌 . . . . . . . . . . . . . . . . . . 23
Jones, et al. Standards Track [Page 3]
RFC 7519 JSON Web Token (JWT) May 2015
부록 A. JWT 예제 . . . . . . . . . . . . . . . . . . . . . . . . 26
A.1. 암호화된 JWT 예제 . . . . . . . . . . . . . . . . . . . 26
A.2. 중첩 JWT 예제 . . . . . . . . . . . . . . . . . . . . . 26
부록 B. JWT와 SAML 어서션의 관계 . . . . . . . . . . . . . . . 28
부록 C. JWT와 Simple Web Token(SWT)의 관계 . . . . . . . . . . 28
감사의 말 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
저자 주소 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1. 서론
JSON Web Token(JWT)은 HTTP 인증 헤더와 URI 쿼리 매개변수와 같은
공간 제약 환경을 위해 설계된 간결한 클레임 표현 형식이다. JWT는
전송될 클레임을 JSON [RFC7159] 객체로 인코딩하며, 이는 JSON Web
Signature(JWS) [JWS] 구조의 페이로드로 사용되거나 JSON Web
Encryption(JWE) [JWE] 구조의 평문으로 사용되어, 클레임을
디지털 서명하거나 메시지 인증 코드(MAC)로 무결성을 보호하고/또는
암호화할 수 있게 한다. JWT는 항상 JWS Compact Serialization 또는
JWE Compact Serialization을 사용하여 표현된다.
JWT의 권장 발음은 영어 단어 "jot"과 동일하다.
1.1. 표기 규칙
본 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
"OPTIONAL"이라는 키워드는
"RFC에서 요구 수준을 나타내기 위한 키워드" [RFC2119]에
설명된 대로 해석되어야 한다.
이러한 해석은 해당 용어가 모두 대문자로 나타날 때에만 적용된다.
2. 용어
"JSON Web Signature(JWS)", "Base64url 인코딩", "헤더 매개변수",
"JOSE 헤더", "JWS Compact Serialization", "JWS 페이로드",
"JWS 서명", "비보안 JWS"라는 용어는 JWS 명세
[JWS]에 정의되어 있다.
"JSON Web Encryption(JWE)", "콘텐츠 암호화 키(CEK)",
"JWE Compact Serialization", "JWE 암호화된 키",
"JWE 초기화 벡터"라는 용어는 JWE 명세
[JWE]에 정의되어 있다.
"암호문", "디지털 서명", "메시지 인증 코드(MAC)", "평문"이라는 용어는
"인터넷 보안 용어집, 버전 2"
[RFC4949]에 정의되어 있다.
Jones, et al. Standards Track [Page 4]
RFC 7519 JSON Web Token (JWT) May 2015
다음 용어는 본 명세에서 정의된다:
JSON Web Token(JWT)
JWS 또는 JWE로 인코딩된 JSON 객체로서 클레임 집합을 표현하는
문자열로, 클레임을 디지털 서명하거나 MAC 처리하고/또는
암호화할 수 있게 한다.
JWT Claims Set
JWT가 전달하는 클레임을 포함하는 JSON 객체.
Claim
주체에 대해 주장되는 정보의 한 조각. 클레임은
클레임 이름과 클레임 값으로 구성된 이름/값 쌍으로 표현된다.
Claim Name
클레임 표현에서 이름 부분. 클레임 이름은 항상 문자열이다.
Claim Value
클레임 표현에서 값 부분. 클레임 값은 임의의 JSON 값일 수 있다.
Nested JWT
중첩된 서명 및/또는 암호화를 사용하는 JWT.
중첩 JWT에서는 JWT가 각각 외부 JWS 또는 JWE 구조의
페이로드 또는 평문 값으로 사용된다.
Unsecured JWT
클레임이 무결성 보호되거나 암호화되지 않은 JWT.
Collision-Resistant Name
다른 이름과 충돌할 가능성이 매우 낮도록 이름을 할당할 수 있게 하는
네임스페이스 내의 이름. 충돌 저항 네임스페이스의 예로는
도메인 이름, ITU-T X.660 및 X.670 권고 시리즈에 정의된
객체 식별자(OID), 그리고 전역 고유 식별자(UUID)
[RFC4122]가 있다.
관리적으로 위임된 네임스페이스를 사용할 경우,
이름 정의자는 자신이 이름을 정의하는 데 사용하는
네임스페이스 부분을 통제하고 있음을 보장하기 위해
합리적인 예방 조치를 취해야 한다.
StringOrURI
JSON 문자열 값으로, 임의의 문자열 값이 사용될 수 있으나,
":" 문자를 포함하는 값은 반드시 URI
[RFC3986]여야 한다는 추가 요구 사항이 있다.
StringOrURI 값은 어떠한 변환이나 정규화도 적용하지 않고,
대소문자를 구분하는 문자열로 비교된다.
Jones, et al. Standards Track [Page 5]
RFC 7519 JSON Web Token (JWT) May 2015
NumericDate
1970-01-01T00:00:00Z UTC부터 지정된 UTC 날짜/시각까지의
초 수를 나타내는 JSON 숫자 값으로, 윤초는 무시된다.
이는 IEEE Std 1003.1, 2013판
[POSIX.1]에서 정의한
"에폭 이후의 초(Seconds Since the Epoch)"와 동등하며,
각 하루는 정확히 86400초로 계산되고,
비정수 값도 표현될 수 있다는 점만 다르다.
날짜/시각 전반 및 특히 UTC에 대한 자세한 내용은
RFC 3339
[RFC3339]를 참조하라.
3. JSON Web Token(JWT) 개요
JWT는 JWS 및/또는 JWE 구조로 인코딩된 JSON 객체로
클레임 집합을 표현한다. 이 JSON 객체가 JWT Claims Set이다.
RFC 7159의 4절
[RFC7159]에 따르면,
JSON 객체는 0개 이상의 이름/값 쌍(또는 멤버)으로 구성되며,
이름은 문자열이고 값은 임의의 JSON 값이다.
이러한 멤버가 JWT가 표현하는 클레임이다.
이 JSON 객체는
RFC 7159의 2절
[RFC7159]에 따라,
어떤 JSON 값이나 구조 문자 앞이나 뒤에
공백 및/또는 줄 바꿈을 포함할 수 있다.
JWT Claims Set 내의 멤버 이름을 클레임 이름이라 하며,
이에 대응하는 값을 클레임 값이라 한다.
JOSE 헤더의 내용은 JWT Claims Set에 적용되는
암호학적 연산을 설명한다. JOSE 헤더가 JWS용인 경우,
JWT는 JWS로 표현되며 클레임은 디지털 서명되거나
MAC 처리되고, JWT Claims Set은 JWS 페이로드가 된다.
JOSE 헤더가 JWE용인 경우, JWT는 JWE로 표현되며
클레임은 암호화되고, JWT Claims Set은 JWE에 의해
암호화되는 평문이 된다. JWT는 중첩 서명 및 암호화를
수행할 수 있도록 또 다른 JWE 또는 JWS 구조로
둘러싸일 수 있으며, 이를 중첩 JWT라 한다.
JWT는 마침표('.') 문자로 구분된 URL 안전한
여러 부분의 시퀀스로 표현된다. 각 부분은
base64url로 인코딩된 값을 포함한다.
JWT의 부분 개수는 결과 JWS를 JWS Compact Serialization으로
표현하는지, 또는 JWE를 JWE Compact Serialization으로
표현하는지에 따라 달라진다.
Jones, et al. Standards Track [Page 6]
RFC 7519 JSON Web Token (JWT) May 2015
3.1. JWT 예제
다음 예제의 JOSE 헤더는 인코딩된 객체가 JWT임을 선언하며,
JWT가 HMAC SHA-256 알고리즘을 사용하여 MAC 처리된
JWS임을 나타낸다:
{"typ":"JWT",
"alg":"HS256"}
위의 JSON 객체 표현에서 발생할 수 있는 잠재적인 모호성을
제거하기 위해, 위 JOSE 헤더 예제에서 사용된 실제 UTF-8 표현에 대한
옥텟 시퀀스도 아래에 포함하였다.
(플랫폼별 줄 바꿈 표현(CRLF 대 LF), 줄의 시작과 끝에서의 공백 차이,
마지막 줄에 종료 줄 바꿈이 있는지 여부 등 다양한 원인으로
모호성이 발생할 수 있다.
본 예제에서 사용된 표현에서는 첫 번째 줄에 선행 및 후행 공백이 없고,
첫 번째 줄과 두 번째 줄 사이에 CRLF 줄 바꿈(13, 10)이 있으며,
두 번째 줄에는 하나의 선행 공백(32)만 있고 후행 공백은 없으며,
마지막 줄에는 종료 줄 바꿈이 없다.)
본 예제의 JOSE 헤더 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]
JOSE 헤더의 UTF-8 표현 옥텟을 base64url로 인코딩하면
다음과 같은 인코딩된 JOSE 헤더 값을 얻는다:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
다음은 JWT Claims Set의 예이다:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
다음 옥텟 시퀀스는 위 JWT Claims Set 예제에 사용된
UTF-8 표현으로, JWS 페이로드이다:
[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]
Jones, et al. Standards Track [Page 7]
RFC 7519 JSON Web Token (JWT) May 2015
JWS 페이로드를 Base64url 인코딩하면 다음과 같은 인코딩된 JWS 페이로드가
생성된다(표시 목적상 줄 바꿈이 포함되어 있음):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
인코딩된 JOSE 헤더와 인코딩된 JWS 페이로드에 대해 HMAC SHA-256 알고리즘을
사용하여 MAC을 계산하고, [JWS]에 지정된 방식으로
HMAC 값을 base64url 인코딩하면 다음과 같은 인코딩된 JWS 서명이 생성된다:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
이러한 인코딩된 부분들을 이 순서대로 각 부분 사이에 마침표('.')
문자를 두고 연결하면 다음과 같은 완전한 JWT가 된다
(표시 목적상 줄 바꿈이 포함되어 있음):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
이 계산 과정은 [JWS]의
부록 A.1에서 더 자세히 설명된다.
암호화된 JWT의 예시는 부록 A.1을 참조하라.
4. JWT 클레임
JWT 클레임 집합은 JWT에 의해 전달되는 클레임들을 멤버로 갖는
JSON 객체를 나타낸다. JWT 클레임 집합 내의 클레임 이름은 반드시
고유해야 하며, JWT 파서는 중복된 클레임 이름을 가진 JWT를 거부하거나,
ECMAScript 5.1의 15.12절
(“JSON 객체”)에 명시된 대로 사전적으로 마지막에 나타난 중복 멤버 이름만을
반환하는 JSON 파서를 사용해야 한다
[ECMAScript].
JWT가 유효하다고 간주되기 위해 반드시 포함해야 하는 클레임 집합은
문맥에 따라 달라지며, 이는 본 사양의 범위를 벗어난다.
JWT의 특정 응용에서는 구현이 일부 클레임을 특정 방식으로 이해하고
처리할 것을 요구할 수 있다. 그러나 그러한 요구사항이 없는 경우,
구현이 이해하지 못하는 모든 클레임은 반드시 무시되어야 한다.
JWT 클레임 이름에는 등록된 클레임 이름, 공개 클레임 이름,
비공개 클레임 이름의 세 가지 클래스가 있다.
Jones, et al. Standards Track [Page 8]
RFC 7519 JSON Web Token (JWT) May 2015
4.1. 등록된 클레임 이름
다음의 클레임 이름들은 10.1절에 의해 설정된
IANA “JSON Web Token Claims” 레지스트리에 등록되어 있다.
아래에 정의된 어떤 클레임도 모든 경우에 반드시 사용하거나 구현하도록
의도된 것은 아니며, 유용하고 상호 운용 가능한 클레임 집합을 위한
출발점을 제공하기 위한 것이다.
JWT를 사용하는 응용은 자신들이 사용하는 구체적인 클레임과,
그것들이 필수인지 선택인지 여부를 정의해야 한다.
모든 이름이 짧은 이유는 JWT의 핵심 목표 중 하나가 표현을
간결하게 유지하는 것이기 때문이다.
4.1.1. "iss"(발급자) 클레임
"iss"(issuer) 클레임은 JWT를 발급한 주체를 식별한다.
이 클레임의 처리는 일반적으로 응용 프로그램에 따라 달라진다.
"iss" 값은 StringOrURI 값을 포함하는 대소문자를 구분하는 문자열이다.
이 클레임의 사용은 선택 사항이다.
4.1.2. "sub"(주제) 클레임
"sub"(subject) 클레임은 JWT의 주체가 되는 주체를 식별한다.
JWT의 클레임은 일반적으로 이 주체에 대한 진술이다.
주체 값은 발급자 맥락 내에서 로컬하게 고유해야 하거나,
전역적으로 고유해야 한다.
이 클레임의 처리는 일반적으로 응용 프로그램에 따라 달라진다.
"sub" 값은 StringOrURI 값을 포함하는 대소문자를 구분하는 문자열이다.
이 클레임의 사용은 선택 사항이다.
4.1.3. "aud"(대상) 클레임
"aud"(audience) 클레임은 JWT가 의도된 수신자를 식별한다.
JWT를 처리하려는 각 주체는 audience 클레임의 값 중 하나로
자신을 식별해야 한다. 이 클레임이 존재할 때,
이를 처리하는 주체가 "aud" 클레임의 값으로 자신을 식별하지 못하면
해당 JWT는 반드시 거부되어야 한다.
일반적인 경우 "aud" 값은 각각 StringOrURI 값을 포함하는
대소문자를 구분하는 문자열 배열이다.
JWT에 하나의 대상만 있는 특수한 경우에는 "aud" 값이
단일 StringOrURI 값을 포함하는 문자열일 수도 있다.
대상 값의 해석은 일반적으로 응용 프로그램에 따라 달라진다.
이 클레임의 사용은 선택 사항이다.
4.1.4. "exp"(만료 시각) 클레임
"exp"(expiration time) 클레임은 해당 시각 이후로
JWT가 처리에 사용되어서는 안 되는 만료 시각을 식별한다.
"exp" 클레임의 처리는 현재 날짜/시간이
"exp" 클레임에 명시된 만료 날짜/시간 이전이어야 함을 요구한다.
Jones, et al. Standards Track [Page 9]
RFC 7519 JSON Web Token (JWT) May 2015
구현은 일반적으로 몇 분을 넘지 않는 작은 허용 오차를 제공하여
시계 오차를 보정할 수 있다.
그 값은 NumericDate 값을 포함하는 숫자여야 한다.
이 클레임의 사용은 선택 사항이다.
4.1.5. "nbf"(이전 불가) 클레임
"nbf"(not before) 클레임은 해당 시각 이전에는
JWT가 처리에 사용되어서는 안 되는 시각을 식별한다.
"nbf" 클레임의 처리는 현재 날짜/시간이
"nbf" 클레임에 명시된 not-before 날짜/시간과 같거나
이후여야 함을 요구한다.
구현은 일반적으로 몇 분을 넘지 않는 작은 허용 오차를 제공하여
시계 오차를 보정할 수 있다.
그 값은 NumericDate 값을 포함하는 숫자여야 한다.
이 클레임의 사용은 선택 사항이다.
4.1.6. "iat"(발급 시각) 클레임
"iat"(issued at) 클레임은 JWT가 발급된 시각을 식별한다.
이 클레임은 JWT의 경과 시간을 판단하는 데 사용될 수 있다.
그 값은 NumericDate 값을 포함하는 숫자여야 한다.
이 클레임의 사용은 선택 사항이다.
4.1.7. "jti"(JWT ID) 클레임
"jti"(JWT ID) 클레임은 JWT에 대한 고유 식별자를 제공한다.
이 식별자 값은 동일한 값이 다른 데이터 객체에
우연히 할당될 가능성이 무시할 수 있을 정도로 작도록
할당되어야 한다.
응용이 여러 발급자를 사용하는 경우,
서로 다른 발급자에 의해 생성된 값들 사이에서도
충돌이 방지되어야 한다.
"jti" 클레임은 JWT의 재사용을 방지하는 데 사용될 수 있다.
"jti" 값은 대소문자를 구분하는 문자열이다.
이 클레임의 사용은 선택 사항이다.
4.2. 공개 클레임 이름
클레임 이름은 JWT를 사용하는 자에 의해 자유롭게 정의될 수 있다.
그러나 충돌을 방지하기 위해,
새로운 클레임 이름은 10.1절에 의해 설정된
IANA “JSON Web Token Claims” 레지스트리에 등록되거나,
공개 이름, 즉 충돌 방지 이름을 포함하는 값이어야 한다.
각 경우에 이름이나 값을 정의하는 자는
자신이 사용하는 네임스페이스의 부분을
제어하고 있음을 보장하기 위해
합리적인 예방 조치를 취해야 한다.
4.3. 비공개 클레임 이름
JWT의 생성자와 소비자는
등록된 클레임 이름(4.1절)이나
공개 클레임 이름(4.2절)이 아닌
비공개 이름을 클레임 이름으로 사용하기로 합의할 수 있다.
공개 클레임 이름과 달리,
Jones, et al. Standards Track [Page 10]
RFC 7519 JSON Web Token (JWT) May 2015
비공개 클레임 이름은 충돌의 대상이 되므로
주의하여 사용되어야 한다.
5. JOSE 헤더
JWT 객체의 경우,
JOSE 헤더로 표현되는 JSON 객체의 멤버들은
JWT에 적용되는 암호학적 연산과,
선택적으로 JWT의 추가 속성을 기술한다.
JWT가 JWS인지 JWE인지에 따라,
JOSE 헤더 값에 적용되는 해당 규칙이 적용된다.
본 사양은 JWT가 JWS인 경우와 JWE인 경우 모두에서
다음의 헤더 파라미터 사용을 추가로 명시한다.
5.1. "typ"(유형) 헤더 파라미터
[JWS] 및
[JWE]에 의해 정의된
"typ"(type) 헤더 파라미터는
JWT 응용이 이 완전한 JWT의 미디어 타입
[IANA.MediaTypes]을 선언하는 데 사용된다.
이는 JWT가 아닌 값들도 포함될 수 있는 응용 데이터 구조 내에서
JWT 객체를 구분하기 위해 사용된다.
일반적으로 객체가 이미 JWT임을 알고 있는 경우에는
응용에서 사용되지 않는다.
이 파라미터는 JWT 구현에 의해 무시되며,
이에 대한 모든 처리는 JWT 응용에 의해 수행된다.
존재하는 경우, 이 객체가 JWT임을 나타내기 위해
그 값은 "JWT"일 것이 권장된다.
미디어 타입 이름은 대소문자를 구분하지 않지만,
레거시 구현과의 호환성을 위해
"JWT"는 항상 대문자로 표기하는 것이 권장된다.
이 헤더 파라미터의 사용은 선택 사항이다.
5.2. "cty"(콘텐츠 유형) 헤더 파라미터
[JWS] 및
[JWE]에 의해 정의된
"cty"(content type) 헤더 파라미터는
JWT에 대한 구조적 정보를 전달하기 위해
본 사양에서 사용된다.
중첩된 서명이나 암호화 연산이 사용되지 않는 일반적인 경우,
이 헤더 파라미터의 사용은 권장되지 않는다.
중첩된 서명이나 암호화가 사용되는 경우에는
이 헤더 파라미터가 반드시 존재해야 하며,
이 경우 그 값은 중첩된 JWT가 이 JWT에 포함되어 있음을 나타내기 위해
반드시 "JWT"여야 한다.
미디어 타입 이름은 대소문자를 구분하지 않지만,
레거시 구현과의 호환성을 위해
"JWT"는 항상 대문자로 표기하는 것이 권장된다.
중첩된 JWT의 예시는 부록 A.2를 참조하라.
Jones, et al. Standards Track [Page 11]
RFC 7519 JSON Web Token (JWT) May 2015
5.3. 헤더 파라미터로서의 클레임 복제
암호화된 JWT를 사용하는 일부 응용에서는,
일부 클레임을 암호화되지 않은 형태로 표현하는 것이 유용할 수 있다.
예를 들어, JWT를 복호화하기 전에
이를 처리할지 여부와 처리 방법을 결정하기 위한
응용 처리 규칙에서 사용될 수 있다.
본 사양은 JWT가 JWE인 경우,
응용에 필요에 따라 JWT 클레임 집합에 존재하는 클레임을
헤더 파라미터로 복제하는 것을 허용한다.
이러한 복제된 클레임이 존재하는 경우,
응용은 해당 클레임에 대해 다른 처리 규칙을 정의하지 않는 한,
그 값이 동일함을 검증해야 한다.
암호화되지 않은 방식으로 전송해도 안전한 클레임만이
JWT의 헤더 파라미터 값으로 복제되도록 보장하는 것은
응용의 책임이다.
본 사양의 10.4.1절은
암호화된 JWT에서 이러한 클레임의 암호화되지 않은 복제본을
필요로 하는 응용을 위해,
"iss"(발급자), "sub"(주제), "aud"(대상)
헤더 파라미터 이름을 등록한다.
다른 사양들도 필요에 따라
등록된 클레임 이름을 헤더 파라미터 이름으로
유사하게 등록할 수 있다.
6. 비보안 JWT
JWT 내부에 포함된 서명 및/또는 암호화가 아닌
다른 수단(예: JWT를 포함하는 데이터 구조에 대한 서명)에 의해
JWT 콘텐츠가 보호되는 사용 사례를 지원하기 위해,
서명이나 암호화 없이 JWT를 생성할 수도 있다.
비보안 JWT는 JWA 사양 [JWA]에 정의된 바와 같이,
"alg" 헤더 파라미터 값이 "none"이고
JWS 서명 값이 빈 문자열인 JWS이며,
JWT 클레임 집합을 JWS 페이로드로 갖는
비보안 JWS이다.
6.1. 비보안 JWT 예시
다음 예시의 JOSE 헤더는
인코딩된 객체가 비보안 JWT임을 선언한다:
{"alg":"none"}
JOSE 헤더의 UTF-8 표현 옥텟을 Base64url 인코딩하면
다음과 같은 인코딩된 JOSE 헤더 값이 생성된다:
eyJhbGciOiJub25lIn0
Jones, et al. Standards Track [Page 12]
RFC 7519 JSON Web Token (JWT) May 2015
다음은 JWT 클레임 집합의 예시이다:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
JWT 클레임 집합의 UTF-8 표현 옥텟을 Base64url 인코딩하면
다음과 같은 인코딩된 JWS 페이로드가 생성된다
(표시 목적상 줄 바꿈이 포함되어 있음):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
인코딩된 JWS 서명은 빈 문자열이다.
이러한 인코딩된 부분들을 이 순서대로 각 부분 사이에
마침표('.') 문자를 두고 연결하면
다음과 같은 완전한 JWT가 된다
(표시 목적상 줄 바꿈이 포함되어 있음):
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
7. JWT 생성 및 검증
7.1. JWT 생성
JWT를 생성하기 위해 다음 단계를 수행한다.
입력과 출력 간에 의존성이 없는 경우,
단계의 순서는 중요하지 않다.
1. 원하는 클레임을 포함하는 JWT 클레임 집합을 생성한다.
표현에는 공백이 명시적으로 허용되며,
인코딩 전에 정규화(canonicalization)를 수행할 필요는 없다.
2. 메시지를 JWT 클레임 집합의 UTF-8 표현 옥텟으로 한다.
3. 원하는 헤더 파라미터 집합을 포함하는 JOSE 헤더를 생성한다.
JWT는 [JWS] 또는
[JWE] 사양 중
하나를 반드시 준수해야 한다.
표현에는 공백이 명시적으로 허용되며,
인코딩 전에 정규화를 수행할 필요는 없다.
Jones, et al. Standards Track [Page 13]
RFC 7519 JSON Web Token (JWT) May 2015
4. JWT가 JWS인지 JWE인지에 따라 다음 두 가지 경우가 있다:
* JWT가 JWS인 경우,
메시지를 JWS 페이로드로 사용하여 JWS를 생성하며,
[JWS]에 지정된
모든 JWS 생성 단계를 반드시 따라야 한다.
* 그렇지 않고 JWT가 JWE인 경우,
메시지를 JWE의 평문으로 사용하여 JWE를 생성하며,
[JWE]에 지정된
모든 JWE 생성 단계를 반드시 따라야 한다.
5. 중첩된 서명 또는 암호화 연산이 수행될 경우,
메시지를 JWS 또는 JWE로 설정하고,
3단계로 돌아가 해당 단계에서 생성되는
새로운 JOSE 헤더에 "cty"(콘텐츠 유형) 값으로
"JWT"를 사용한다.
6. 그렇지 않으면,
결과로 생성된 JWT는 JWS 또는 JWE이다.
7.2. JWT 검증
JWT를 검증할 때 다음 단계를 수행한다.
입력과 출력 간에 의존성이 없는 경우,
단계의 순서는 중요하지 않다.
나열된 단계 중 하나라도 실패하면,
해당 JWT는 반드시 거부되어야 하며,
응용에서는 이를 유효하지 않은 입력으로 처리해야 한다.
1. JWT에 최소 하나 이상의 마침표('.') 문자가 포함되어 있는지
확인한다.
2. JWT에서 첫 번째 마침표('.') 문자 이전 부분을
인코딩된 JOSE 헤더로 설정한다.
3. 줄 바꿈, 공백 또는 기타 추가 문자가 사용되지 않았다는
제한을 준수하여,
인코딩된 JOSE 헤더를 Base64url 디코딩한다.
4. 결과 옥텟 시퀀스가
RFC 7159
[RFC7159]를 준수하는
완전히 유효한 JSON 객체의 UTF-8 인코딩 표현인지
검증하고,
이를 JOSE 헤더로 설정한다.
5. 결과 JOSE 헤더가
구문과 의미가 모두 이해되고 지원되거나,
이해되지 않을 경우 무시되도록 지정된
파라미터와 값만을 포함하는지 검증한다.
6. [JWE]의 9절에 설명된
방법 중 하나를 사용하여
JWT가 JWS인지 JWE인지 판단한다.
Jones, et al. Standards Track [Page 14]
RFC 7519 JSON Web Token (JWT) May 2015
7. JWT가 JWS인지 JWE인지에 따라 다음 두 가지 경우가 있다:
* JWT가 JWS인 경우,
[JWS]에 지정된
JWS 검증 단계를 따른다.
메시지는 JWS 페이로드를 Base64url 디코딩한
결과로 설정한다.
* 그렇지 않고 JWT가 JWE인 경우,
[JWE]에 지정된
JWE 검증 단계를 따른다.
메시지는 결과 평문으로 설정한다.
8. JOSE 헤더에 "cty"(콘텐츠 유형) 값으로
"JWT"가 포함되어 있다면,
메시지는 중첩된 서명 또는 암호화 연산의
대상이 되었던 JWT이다.
이 경우 메시지를 JWT로 사용하여
1단계로 돌아간다.
9. 그렇지 않으면,
줄 바꿈, 공백 또는 기타 추가 문자가 사용되지 않았다는
제한을 준수하여 메시지를 Base64url 디코딩한다.
10. 결과 옥텟 시퀀스가
RFC 7159
[RFC7159]를 준수하는
완전히 유효한 JSON 객체의 UTF-8 인코딩 표현인지
검증하고,
이를 JWT 클레임 집합으로 설정한다.
마지막으로, 어떤 알고리즘을 사용할지는
특정 맥락에서 응용이 결정하는 사항임에 유의하라.
JWT가 성공적으로 검증되었다 하더라도,
JWT에 사용된 알고리즘이 응용에서 허용되지 않는다면
응용은 해당 JWT를 거부하는 것이 바람직하다.
7.3. 문자열 비교 규칙
JWT 처리는 필연적으로 알려진 문자열을
JSON 객체의 멤버 및 값과 비교하는 작업을 요구한다.
예를 들어 알고리즘을 확인할 때,
유니코드 [UNICODE] 문자열 인코딩
"alg"는 JOSE 헤더의 멤버 이름과 비교되어
일치하는 헤더 파라미터 이름이 있는지 확인된다.
멤버 이름 비교에 대한 JSON 규칙은
RFC 7159의 8.3절
[RFC7159]에
설명되어 있다.
수행되는 문자열 비교 연산은
동등성과 비동등성뿐이므로,
동일한 규칙을 멤버 이름과 멤버 값 모두에
적용할 수 있다.
이 비교 규칙은,
특정 멤버 값에 대해 다른 비교 규칙을 사용해야 한다고
정의에서 명시적으로 언급한 경우를 제외하고,
모든 JSON 문자열 비교에 반드시 사용되어야 한다.
본 사양에서는 "typ"과 "cty" 멤버 값만이
이러한 비교 규칙을 사용하지 않는다.
Jones, et al. Standards Track [Page 15]
RFC 7519 JSON Web Token (JWT) May 2015
일부 응용은 대소문자를 구분하는 값 안에
대소문자를 구분하지 않는 정보를 포함할 수 있는데,
예를 들어 "iss"(발급자) 클레임 값의 일부로
DNS 이름을 포함하는 경우가 이에 해당한다.
이러한 경우, 여러 당사자가 동일한 값을 생성하여
비교해야 할 수 있으므로,
응용은 대소문자를 구분하지 않는 부분을
소문자로 변환하는 등,
사용할 표준 대소문자 형식에 대한 규칙을
정의할 필요가 있을 수 있다.
(그러나 다른 모든 당사자가
생성자가 출력한 값을 그대로 소비하고
독립적으로 생성한 값과 비교하려 하지 않는다면,
생성자가 사용한 대소문자는 중요하지 않다.)
8. 구현 요구사항
이 절은 본 사양에서 반드시 구현해야 하는
알고리즘과 기능을 정의한다.
이 사양을 사용하는 응용은
자신들이 사용하는 구현에 대해
추가적인 요구사항을 부과할 수 있다.
예를 들어, 한 응용은
암호화된 JWT와 중첩된 JWT 지원을 요구할 수 있고,
다른 응용은
P-256 곡선과 SHA-256 해시 알고리즘을 사용하는
타원 곡선 디지털 서명 알고리즘(ECDSA)
("ES256")으로 JWT 서명을 요구할 수 있다.
JSON Web Algorithms
[JWA]에 지정된
서명 및 MAC 알고리즘 중,
HMAC SHA-256("HS256")과 "none"만이
적합한 JWT 구현에서 반드시 구현되어야 한다.
또한 구현이
SHA-256 해시 알고리즘을 사용하는
RSASSA-PKCS1-v1_5("RS256")와,
P-256 곡선을 사용하는
ECDSA("ES256")를 지원하는 것이 권장된다.
다른 알고리즘과 키 크기에 대한 지원은
선택 사항이다.
암호화된 JWT에 대한 지원은 선택 사항이다.
구현이 암호화 기능을 제공하는 경우,
[JWA]에 지정된
암호화 알고리즘 중,
2048비트 키를 사용하는 RSAES-PKCS1-v1_5("RSA1_5"),
128비트 및 256비트 키를 사용하는
AES 키 래핑("A128KW", "A256KW"),
AES-CBC와 HMAC SHA-2를 결합한
복합 인증 암호화 알고리즘
("A128CBC-HS256", "A256CBC-HS512")만이
적합한 구현에서 반드시 구현되어야 한다.
또한 구현이
콘텐츠 암호화 키를 래핑하기 위해
타원 곡선 디피-헬만 임시-정적(ECDH-ES)을 사용하는
("ECDH-ES+A128KW", "ECDH-ES+A256KW") 방식과,
128비트 및 256비트 키를 사용하는
AES GCM("A128GCM", "A256GCM")을
지원하는 것이 권장된다.
다른 알고리즘과 키 크기에 대한 지원은
선택 사항이다.
중첩된 JWT에 대한 지원은 선택 사항이다.
Jones, et al. Standards Track [Page 16]
RFC 7519 JSON Web Token (JWT) May 2015
9. 콘텐츠가 JWT임을 선언하기 위한 URI
본 사양은
미디어 타입이 아닌 URI를 사용하여
콘텐츠 유형을 선언하는 응용에서,
해당 콘텐츠가 JWT임을 나타내기 위해 사용되는
URN
"urn:ietf:params:oauth:token-type:jwt"
를 등록한다.
10. IANA 고려 사항
10.1. JSON Web Token 클레임 레지스트리
이 절은 JWT 클레임 이름을 위한 IANA “JSON Web Token Claims”
레지스트리를 설정한다. 이 레지스트리는 클레임 이름과 이를 정의하는
명세에 대한 참조를 기록한다. 이 절에서는
4.1절에 정의된 클레임 이름을 등록한다.
값은 jwt-reg-review@ietf.org 메일링 리스트에서 3주간의 검토 기간을
거친 후, 하나 이상의 지정 전문가(Designated Expert)의 조언에 따라
Specification Required [RFC5226] 기준으로 등록된다.
단, 출판 이전에 값을 할당할 수 있도록 하기 위해, 지정 전문가는
해당 명세가 출판될 것임을 만족스럽게 확인한 경우 등록을 승인할 수 있다.
검토를 위해 메일링 리스트로 전송되는 등록 요청은 적절한 제목을
사용해야 한다(예: “Request to register claim: example”).
검토 기간 내에 지정 전문가는 등록 요청을 승인하거나 거부하며,
그 결정을 검토 리스트와 IANA에 통지한다. 거부 시에는 설명을 포함해야 하며,
해당되는 경우 요청을 성공적으로 만들기 위한 제안을 포함해야 한다.
21일을 초과하는 기간 동안 미결 상태로 남아 있는 등록 요청은
해결을 위해 IESG의 주의(iesg@ietf.org 메일링 리스트 사용)를
환기시킬 수 있다.
지정 전문가가 적용해야 할 기준에는 제안된 등록이 기존 기능을
중복하는지 여부, 일반적인 적용 가능성이 있는지 아니면 단일
애플리케이션에만 유용한지 여부, 그리고 등록 설명이 명확한지 여부를
판단하는 것이 포함된다.
IANA는 지정 전문가로부터의 레지스트리 업데이트만 수락해야 하며,
모든 등록 요청은 검토 메일링 리스트로 안내해야 한다.
등록 결정에 대해 폭넓게 정보에 기반한 검토를 가능하게 하기 위해,
이 명세를 사용하는 다양한 애플리케이션의 관점을 대표할 수 있는
여러 명의 지정 전문가를 임명하는 것이 권장된다. 특정 전문가에게
이해 충돌을 야기하는 것으로 인식될 수 있는 경우에는, 해당 전문가는
다른 전문가의 판단에 따르는 것이 바람직하다.
Jones, et al. Standards Track [Page 17]
RFC 7519 JSON Web Token (JWT) May 2015
10.1.1. 등록 템플릿
Claim Name:
요청된 이름(예: “iss”). 이 명세의 핵심 목표 중 하나는 결과 표현을
간결하게 만드는 것이므로, 특별히 설득력 있는 이유가 없는 한
이름은 짧게, 즉 8자를 초과하지 않는 것이 권장된다(RECOMMENDED).
이 이름은 대소문자를 구분한다. 지정 전문가가 예외를 허용해야 할
설득력 있는 이유가 있다고 판단하지 않는 한, 이름은 대소문자를
구분하지 않는 비교에서 다른 등록된 이름과 일치해서는 안 된다.
Claim Description:
클레임에 대한 간단한 설명(예: “Issuer”).
Change Controller:
Standards Track RFC의 경우 “IESG”를 기재한다.
그 외의 경우 책임 당사자의 이름을 기재한다.
기타 세부 정보(예: 우편 주소, 이메일 주소, 홈페이지 URI)도
포함될 수 있다.
Specification Document(s):
파라미터를 명시하는 문서에 대한 참조.
가능하다면 문서 사본을 가져올 수 있는 URI를 포함하는 것이 바람직하다.
관련 절에 대한 표시를 포함할 수도 있으나 필수는 아니다.
10.1.2. 초기 레지스트리 내용
o Claim Name: "iss"
o Claim Description: Issuer
o Change Controller: IESG
o Specification Document(s): RFC 7519의 4.1.1절
o Claim Name: "sub"
o Claim Description: Subject
o Change Controller: IESG
o Specification Document(s): RFC 7519의 4.1.2절
o Claim Name: "aud"
o Claim Description: Audience
o Change Controller: IESG
o Specification Document(s): RFC 7519의 4.1.3절
Jones, et al. Standards Track [Page 18]
RFC 7519 JSON Web Token (JWT) May 2015
o Claim Name: "exp"
o Claim Description: Expiration Time
o Change Controller: IESG
o Specification Document(s): RFC 7519의 4.1.4절
o Claim Name: "nbf"
o Claim Description: Not Before
o Change Controller: IESG
o Specification Document(s): RFC 7519의 4.1.5절
o Claim Name: "iat"
o Claim Description: Issued At
o Change Controller: IESG
o Specification Document(s): RFC 7519의 4.1.6절
o Claim Name: "jti"
o Claim Description: JWT ID
o Change Controller: IESG
o Specification Document(s): RFC 7519의 4.1.7절
10.2. 하위 네임스페이스 등록
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) 토큰 타입
o Change Controller: IESG
o Specification Document(s): RFC 7519
Jones, et al. Standards Track [Page 19]
RFC 7519 JSON Web Token (JWT) May 2015
10.3. 미디어 타입 등록
10.3.1. 레지스트리 내용
이 절은 RFC 6838 [RFC6838]에 설명된 방식에 따라,
콘텐츠가 JWT임을 나타내는 데 사용할 수 있는
“application/jwt” 미디어 타입 [RFC2046]을
“Media Types” 레지스트리 [IANA.MediaTypes]에 등록한다.
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: 없음
o Author: Michael B. Jones, mbj@microsoft.com
o Change controller: IESG
o Provisional registration? 아니오
10.4. 헤더 파라미터 이름 등록
이 절은 4.1절에 정의된 특정 클레임 이름을,
5.3절에 따라 JWE에서 헤더 파라미터로
복제되는 클레임에 사용하기 위해,
[JWS]에 의해 설정된
IANA “JSON Web Signature and Encryption Header Parameters”
레지스트리에 등록한다.
Jones, et al. Standards Track [Page 20]
RFC 7519 JSON Web Token (JWT) May 2015
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): RFC 7519의 4.1.1절
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): RFC 7519의 4.1.2절
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): RFC 7519의 4.1.3절
11. 보안 고려 사항
모든 암호학적 애플리케이션과 관련된 보안 문제는
JWT/JWS/JWE/JWK 에이전트에 의해 다루어져야 한다.
이러한 문제에는 사용자의 비대칭 개인 키와 대칭 비밀 키를
보호하는 것과, 다양한 공격에 대한 대응책을 사용하는 것이 포함된다.
JWS 명세의 모든 보안 고려 사항은 JWT에도 동일하게 적용되며,
암호화가 사용되는 경우 JWE의 보안 고려 사항 또한 적용된다.
특히 [JWS]의
10.12절(“JSON 보안 고려 사항”)과
10.13절(“유니코드 비교 보안 고려 사항”)은
JOSE 헤더에 적용되는 것과 동일한 방식으로
JWT 클레임 세트에도 적용된다.
11.1. 신뢰 결정
JWT의 내용은 암호학적으로 보호되고 신뢰 결정을 위해 필요한
컨텍스트에 바인딩되지 않는 한 신뢰 결정에서 의존될 수 없다.
특히 JWT에 서명하고/또는 암호화하는 데 사용되는 키는,
일반적으로 JWT의 발행자로 식별된 당사자의 통제 하에 있음을
검증 가능하게 입증할 필요가 있다.
11.2. 서명 및 암호화 순서
구문적으로는 중첩 JWT에 대한 서명 및 암호화 연산을
어떤 순서로든 적용할 수 있지만, 서명과 암호화가 모두 필요한 경우
일반적으로 생성자는 메시지에 먼저 서명한 다음 그 결과를
암호화해야 한다(즉, 서명을 암호화함).
Jones, et al. Standards Track [Page 21]
RFC 7519 JSON Web Token (JWT) May 2015
이는 서명이 제거되고 암호화된 메시지만 남는 공격을 방지할 뿐만 아니라,
서명자에 대한 프라이버시를 제공한다. 또한 암호화된 텍스트에 대한
서명은 많은 관할권에서 유효한 것으로 간주되지 않는다.
서명 및 암호화 연산 순서와 관련된 잠재적인 보안 문제는
기본이 되는 JWS 및 JWE 명세에서 이미 다루어지고 있다.
특히 JWE는 인증된 암호화 알고리즘만을 지원하므로,
많은 맥락에서 적용되는 암호화 이후 서명의 필요성과 관련된
암호학적 우려는 본 명세에는 적용되지 않는다.
12. 프라이버시 고려 사항
JWT에는 프라이버시에 민감한 정보가 포함될 수 있다.
이러한 경우 의도하지 않은 당사자에게 해당 정보가 노출되지 않도록
조치를 취해야 한다(MUST). 이를 달성하는 한 가지 방법은
암호화된 JWT를 사용하고 수신자를 인증하는 것이다.
또 다른 방법은 암호화되지 않은 프라이버시 민감 정보를 포함한 JWT가,
전송 계층 보안(TLS)과 같이 종단점 인증을 지원하는 암호화를 사용하는
프로토콜을 통해서만 전송되도록 보장하는 것이다.
JWT에서 프라이버시 민감 정보를 생략하는 것은
프라이버시 문제를 최소화하는 가장 간단한 방법이다.
13. 참고 문헌
13.1. 규범적 참고 문헌
[ECMAScript]
Ecma International, “ECMAScript 언어 명세,
제5.1판”, ECMA 표준 262, 2011년 6월,
<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, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7518>.
[JWE] Jones, M. 및 J. Hildebrand, “JSON Web Encryption (JWE)”,
RFC 7516, DOI 10.17487/RFC7516, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7516>.
Jones, et al. Standards Track [Page 22]
RFC 7519 JSON Web Token (JWT) May 2015
[JWS] Jones, M., Bradley, J., 및 N. Sakimura, “JSON Web
Signature (JWS)”, RFC 7515, DOI 10.17487/RFC, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7515>.
[RFC20] Cerf, V., “네트워크 상호 교환을 위한 ASCII 형식”, STD 80,
RFC 20, DOI 10.17487/RFC0020, 1969년 10월,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2046] Freed, N. 및 N. Borenstein, “다목적 인터넷 메일 확장(MIME)
제2부: 미디어 타입”, RFC 2046,
DOI 10.17487/RFC2046, 1996년 11월,
<http://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., “RFC에서 요구 수준을 나타내기 위한 키워드”,
BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997년 3월,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., 및 L. Masinter,
“통합 자원 식별자(URI): 일반 구문”, STD 66,
RFC 3986, DOI 10.17487/RFC3986, 2005년 1월,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4949] Shirey, R., “인터넷 보안 용어집, 버전 2”,
FYI 36, RFC 4949, DOI 10.17487/RFC4949, 2007년 8월,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC7159] Bray, T.(편집), “JavaScript Object Notation(JSON)
데이터 교환 형식”, RFC 7159,
DOI 10.17487/RFC7159, 2014년 3월,
<http://www.rfc-editor.org/info/rfc7159>.
[UNICODE] 유니코드 컨소시엄, “유니코드 표준”,
<http://www.unicode.org/versions/latest/>.
13.2. 정보 제공 참고 문헌
[CanvasApp]
Facebook, “Canvas Applications”, 2010,
<http://developers.facebook.com/docs/authentication/
canvas>.
[JSS] Bradley, J. 및 N. Sakimura(편집),
“JSON Simple Sign”, 2010년 9월,
<http://jsonenc.info/jss/1.0/>.
Jones, et al. Standards Track [Page 23]
RFC 7519 JSON Web Token (JWT) May 2015
[MagicSignatures]
Panzer, J.(편집), Laurie, B., 및 D. Balfanz,
“Magic Signatures”, 2011년 1월,
<http://salmon-protocol.googlecode.com/svn/
trunk/draft-panzer-magicsig-01.html>.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., 및 E. Maler,
“OASIS 보안 어설션 마크업 언어(SAML) V2.0을 위한
어설션 및 프로토콜”, OASIS 표준 saml-core-2.0-os,
2005년 3월,
<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 표준 1003.1, 2013판, 2013년,
<http://pubs.opengroup.org/onlinepubs/9699919799/
basedefs/V1_chap04.html#tag_04_15>.
[RFC3275] Eastlake 3rd, D., Reagle, J., 및 D. Solo,
“(확장 가능 마크업 언어) XML-서명 구문 및 처리”,
RFC 3275, DOI 10.17487/RFC3275, 2002년 3월,
<http://www.rfc-editor.org/info/rfc3275>.
[RFC3339] Klyne, G. 및 C. Newman,
“인터넷에서의 날짜와 시간: 타임스탬프”,
RFC 3339, DOI 10.17487/RFC3339, 2002년 7월,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC4122] Leach, P., Mealling, M., 및 R. Salz,
“범용 고유 식별자(UUID) URN 네임스페이스”,
RFC 4122, DOI 10.17487/RFC4122, 2005년 7월,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC5226] Narten, T. 및 H. Alvestrand,
“RFC에서 IANA 고려 사항 절을 작성하기 위한 지침”,
BCP 26, RFC 5226,
DOI 10.17487/RFC5226, 2008년 5월,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6755] Campbell, B. 및 H. Tschofenig,
“OAuth를 위한 IETF URN 하위 네임스페이스”,
RFC 6755, DOI 10.17487/RFC6755, 2012년 10월,
<http://www.rfc-editor.org/info/rfc6755>.
[RFC6838] Freed, N., Klensin, J., 및 T. Hansen,
“미디어 타입 명세 및 등록 절차”,
BCP 13, RFC 6838,
DOI 10.17487/RFC6838, 2013년 1월,
<http://www.rfc-editor.org/info/rfc6838>.
Jones, et al. Standards Track [Page 24]
RFC 7519 JSON Web Token (JWT) May 2015
[SWT] Hardt, D. 및 Y. Goland,
“Simple Web Token (SWT)”, 버전 0.9.5.1,
2009년 11월,
<http://msdn.microsoft.com/en-us/
library/windowsazure/hh781551.aspx>.
[W3C.CR-xml11-20060816]
Cowan, J., “확장 가능 마크업 언어(XML) 1.1
(제2판)”, 월드 와이드 웹 컨소시엄 권고안
REC-xml11-20060816, 2006년 8월,
<http://www.w3.org/TR/2006/REC-xml11-20060816>.
[W3C.REC-xml-c14n-20010315]
Boyer, J., “정규화 XML 버전 1.0”,
월드 와이드 웹 컨소시엄 권고안
REC-xml-c14n-20010315, 2001년 3월,
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
Jones, et al. Standards Track [Page 25]
RFC 7519 JSON Web Token (JWT) May 2015
부록 A. JWT 예제
이 절에는 JWT의 예제가 포함되어 있다. 다른 JWT 예제에 대해서는
이 문서의 섹션 6.1 및 [JWS]의 부록 A.1 - A.3을
참조하라.
A.1. 암호화된 JWT 예제
이 예제는 섹션 3.1에서 사용된 것과 동일한 클레임을
RSAES-PKCS1-v1_5 및 AES_128_CBC_HMAC_SHA_256을 사용하여
수신자에게 암호화한다.
다음 예제의 JOSE 헤더는 다음을 선언한다:
o 콘텐츠 암호화 키(Content Encryption Key)는
RSAES-PKCS1-v1_5 알고리즘을 사용하여 수신자에게 암호화되며,
이를 통해 JWE 암호화 키(JWE Encrypted Key)가 생성된다.
o 인증된 암호화는 AES_128_CBC_HMAC_SHA_256 알고리즘을 사용하여
평문에 대해 수행되며, 이를 통해 JWE 암호문(JWE Ciphertext)과
JWE 인증 태그(JWE Authentication Tag)가 생성된다.
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
섹션 3.1의 JWT 클레임 집합(JWT Claims Set)의
UTF-8 표현의 옥텟을 평문 값으로 사용하는 것 외에는,
이 JWT의 계산은 [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 예제
이 예제는 JWT가 JWE 또는 JWS의 페이로드로 사용되어
중첩된 JWT(Nested JWT)를 생성하는 방법을 보여준다.
이 경우, JWT 클레임 집합은 먼저 서명되고,
그 다음에 암호화된다.
Jones, et al. Standards Track [Page 26]
RFC 7519 JSON Web Token (JWT) May 2015
내부 서명된 JWT는 [JWS]의
부록 A.2에 있는 예제와 동일하다.
따라서, 그 계산은 여기서 반복하지 않는다.
그런 다음 이 예제는 RSAES-PKCS1-v1_5 및
AES_128_CBC_HMAC_SHA_256을 사용하여
이 내부 JWT를 수신자에게 암호화한다.
다음 예제의 JOSE 헤더는 다음을 선언한다:
o 콘텐츠 암호화 키는 RSAES-PKCS1-v1_5 알고리즘을 사용하여
수신자에게 암호화되며, 이를 통해 JWE 암호화 키가 생성된다.
o 인증된 암호화는 AES_128_CBC_HMAC_SHA_256 알고리즘을 사용하여
평문에 대해 수행되며, 이를 통해 JWE 암호문과
JWE 인증 태그가 생성된다.
o 평문 자체가 JWT이다.
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
JOSE 헤더의 UTF-8 표현의 옥텟을 base64url로 인코딩하면
다음과 같은 인코딩된 JOSE 헤더 값이 생성된다:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
이 JWT의 계산은 [JWE]의
부록 A.2에 있는 JWE의 계산과
동일하며, 단지 사용된 JOSE 헤더, 평문,
JWE 초기화 벡터(JWE Initialization Vector),
그리고 콘텐츠 암호화 키 값이 다를 뿐이다.
(사용된 RSA 키는 동일하다.)
사용된 평문은 [RFC20]에 따른
ASCII 표현의 옥텟으로,
[JWS]의
부록 A.2.1 끝에 있는 JWT이며
(모든 공백과 줄 바꿈이 제거된),
총 458 옥텟의 시퀀스이다.
사용된 JWE 초기화 벡터 값은
(JSON 배열 표기법을 사용하여) 다음과 같다:
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53,
50]
이 예제에서는 아래에 표시된 base64url로 인코딩된 값으로
표현된 콘텐츠 암호화 키를 사용한다:
GawgguFyGrWKav7AX4VKUg
Jones, et al. Standards Track [Page 27]
RFC 7519 JSON Web Token (JWT) May 2015
이 중첩된 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 어설션의 관계
보안 어설션 마크업 언어(Security Assertion Markup Language, SAML) 2.0
[OASIS.saml-core-2.0-os]은
JWT보다 더 높은 표현력과 더 많은 보안 옵션을 가진
보안 토큰을 생성하기 위한 표준을 제공한다.
그러나 이러한 유연성과 표현력의 비용은
크기와 복잡성 모두에 있다.
SAML은 XML
[W3C.CR-xml11-20060816]과
XML 디지털 서명(DSIG)
[RFC3275]을 사용함으로써
SAML 어설션의 크기를 증가시키며,
특히 XML 및 XML 정규화(XML Canonicalization)
[W3C.REC-xml-c14n-20010315]의 사용은
그 복잡성을 증가시킨다.
JWT는 HTTP 헤더 및 URI의 쿼리 인자에
들어갈 수 있을 만큼 충분히 작은
단순한 보안 토큰 형식을 제공하는 것을 목표로 한다.
이를 위해 SAML보다 훨씬 단순한 토큰 모델을 지원하고,
JSON
[RFC7159] 객체 인코딩 문법을 사용한다.
또한 XML DSIG보다 더 작은 (그리고 덜 유연한)
형식을 사용하여 메시지 인증 코드(MAC)와
디지털 서명을 통한 토큰 보안도 지원한다.
따라서 JWT는 SAML 어설션이 수행할 수 있는 일부 기능을
수행할 수는 있지만,
SAML 어설션을 완전히 대체하기 위한 것은 아니며,
구현의 용이성이나 간결성이 중요한 경우에
사용되도록 의도된 토큰 형식이다.
Jones, et al. Standards Track [Page 28]
RFC 7519 JSON Web Token (JWT) May 2015
SAML 어설션은 항상 어떤 주체(subject)에 대해
엔터티가 수행하는 진술이다.
JWT 역시 종종 동일한 방식으로 사용되며,
진술을 수행하는 엔터티는
"iss"(발급자, issuer) 클레임으로 표현되고,
주체는 "sub"(주체, subject) 클레임으로 표현된다.
그러나 이러한 클레임들이 선택 사항이기 때문에,
JWT 형식의 다른 사용 사례들도 허용된다.
부록 C. JWT와 단순 웹 토큰(Simple Web Token, SWT)의 관계
JWT와 SWT
[SWT]는
그 핵심에서 애플리케이션 간에
클레임 집합을 전달할 수 있도록 한다.
SWT의 경우, 클레임 이름과 클레임 값은 모두 문자열이다.
JWT의 경우, 클레임 이름은 문자열이지만
클레임 값은 모든 JSON 타입이 될 수 있다.
두 토큰 형식 모두 콘텐츠에 대한
암호학적 보호를 제공하는데,
SWT는 HMAC SHA-256을 사용하고,
JWT는 서명, MAC, 암호화 알고리즘을 포함한
다양한 알고리즘 선택을 제공한다.
Acknowledgements
저자들은 JWT의 설계가
SWT
[SWT]의 설계와 단순성,
그리고 OpenID 커뮤니티 내에서
Dick Hardt가 논의한 JSON 토큰에 대한 아이디어의
영향을 의도적으로 받았음을 인정한다.
JSON 콘텐츠 서명에 대한 해결책은
이전에 Magic Signatures
[MagicSignatures],
JSON Simple Sign
[JSS],
그리고 Canvas
Applications
[CanvasApp]에서
탐구되었으며,
이들 모두가 이 문서에 영향을 미쳤다.
이 명세는 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, and Tom Yu.
Hannes Tschofenig와 Derek Atkins는
OAuth 작업 그룹의 의장을 맡았으며,
Sean Turner, Stephen Farrell,
그리고 Kathleen Moriarty는
이 명세가 작성되는 동안
보안 영역 디렉터(Security Area Director)로
활동하였다.
Jones, et al. Standards Track [Page 29]
RFC 7519 JSON Web Token (JWT) May 2015
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/
Jones, et al. Standards Track [Page 30]