draft-ietf-oauth-jwt-bearer-04.txt   draft-ietf-oauth-jwt-bearer-05.txt 
OAuth Working Group M. Jones OAuth Working Group M.B. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track B. Campbell Intended status: Standards Track B. Campbell
Expires: June 30, 2013 Ping Identity Expires: September 30, 2013 Ping Identity
C. Mortimore C. Mortimore
Salesforce Salesforce
December 27, 2012 March 29, 2013
JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and
draft-ietf-oauth-jwt-bearer-04 Authorization Grants
draft-ietf-oauth-jwt-bearer-05
Abstract Abstract
This specification defines the use of a JSON Web Token (JWT) Bearer This specification defines the use of a JSON Web Token (JWT) Bearer
Token as a means for requesting an OAuth 2.0 access token as well as Token as a means for requesting an OAuth 2.0 access token as well as
for use as a means of client authentication. for use as a means of client authentication.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 30, 2013. This Internet-Draft will expire on September 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4 2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4
2.1. Using JWTs as Authorization Grants . . . . . . . . . . . . 4 2.1. Using JWTs as Authorization Grants . . . . . . . . . . . 4
2.2. Using JWTs for Client Authentication . . . . . . . . . . . 5 2.2. Using JWTs for Client Authentication . . . . . . . . . . 5
3. JWT Format and Processing Requirements . . . . . . . . . . . . 5 3. JWT Format and Processing Requirements . . . . . . . . . . . 6
3.1. Authorization Grant Processing . . . . . . . . . . . . . . 7 3.1. Authorization Grant Processing . . . . . . . . . . . . . 7
3.2. Client Authentication Processing . . . . . . . . . . . . . 7 3.2. Client Authentication Processing . . . . . . . . . . . . 7
4. Authorization Grant Example . . . . . . . . . . . . . . . . . 7 4. Authorization Grant Example . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Interoperability Considerations . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Sub-Namespace Registration of 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
urn:ietf:params:oauth:grant-type:jwt-bearer . . . . . . . 8 7.1. Sub-Namespace Registration of urn:ietf:params:oauth
6.2. Sub-Namespace Registration of :grant-type:jwt-bearer . . . . . . . . . . . . . . . . . 9
urn:ietf:params:oauth:client-assertion-type:jwt-bearer . . 9 7.2. Sub-Namespace Registration of urn:ietf:params:oauth
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 :client-assertion-type:jwt-bearer . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix B. Document History . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
JSON Web Token (JWT) [JWT] is a JavaScript Object Notation (JSON) JSON Web Token (JWT) [JWT] is a JavaScript Object Notation (JSON)
[RFC4627] based security token encoding that enables identity and [RFC4627] based security token encoding that enables identity and
security information to be shared across security domains. A security information to be shared across security domains. A
security token is generally issued by an identity provider and security token is generally issued by an identity provider and
consumed by a relying party that relies on its content to identify consumed by a relying party that relies on its content to identify
the token's subject for security related purposes. the token's subject for security related purposes.
skipping to change at page 3, line 29 skipping to change at page 3, line 9
term used to describe intermediate credentials that represent the term used to describe intermediate credentials that represent the
resource owner authorization. An authorization grant is used by the resource owner authorization. An authorization grant is used by the
client to obtain an access token. Several authorization grant types client to obtain an access token. Several authorization grant types
are defined to support a wide range of client types and user are defined to support a wide range of client types and user
experiences. OAuth also allows for the definition of new extension experiences. OAuth also allows for the definition of new extension
grant types to support additional clients or to provide a bridge grant types to support additional clients or to provide a bridge
between OAuth and other trust frameworks. Finally, OAuth allows the between OAuth and other trust frameworks. Finally, OAuth allows the
definition of additional authentication mechanisms to be used by definition of additional authentication mechanisms to be used by
clients when interacting with the authorization server. clients when interacting with the authorization server.
The Assertion Framework for OAuth 2.0 [I-D.ietf-oauth-assertions] is The Assertion Framework for OAuth 2.0 Client Authentication and
an abstract extension to OAuth 2.0 that provides a general framework Authorization Grants [I-D.ietf-oauth-assertions] specification is an
for the use of Assertions (a.k.a. Security Tokens) as client abstract extension to OAuth 2.0 that provides a general framework for
credentials and/or authorization grants with OAuth 2.0. This the use of Assertions (a.k.a. Security Tokens) as client credentials
specification profiles the Assertion Framework for OAuth 2.0 and/or authorization grants with OAuth 2.0. This specification
[I-D.ietf-oauth-assertions] to define an extension grant type that profiles the Assertion Framework for OAuth 2.0 Client Authentication
uses a JSON Web Token (JWT) Bearer Token to request an OAuth 2.0 and Authorization Grants [I-D.ietf-oauth-assertions] specification to
access token as well as for use as client credentials. The format define an extension grant type that uses a JSON Web Token (JWT)
and processing rules for the JWT defined in this specification are Bearer Token to request an OAuth 2.0 access token as well as for use
intentionally similar, though not identical, to those in the closely as client credentials. The format and processing rules for the JWT
related SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 defined in this specification are intentionally similar, though not
[I-D.ietf-oauth-saml2-bearer]. identical, to those in the closely related SAML 2.0 Profile for OAuth
2.0 Client Authentication and Authorization Grants
[I-D.ietf-oauth-saml2-bearer] specification.
This document defines how a JSON Web Token (JWT) Bearer Token can be This document defines how a JSON Web Token (JWT) Bearer Token can be
used to request an access token when a client wishes to utilize an used to request an access token when a client wishes to utilize an
existing trust relationship, expressed through the semantics of (and existing trust relationship, expressed through the semantics of (and
digital signature calculated over) the JWT, without a direct user digital signature or keyed message digest calculated over) the JWT,
approval step at the authorization server. It also defines how a JWT without a direct user approval step at the authorization server. It
can be used as a client authentication mechanism. The use of a also defines how a JWT can be used as a client authentication
security token for client authentication is orthogonal to and mechanism. The use of a security token for client authentication is
separable from using a security token as an authorization grant. orthogonal to and separable from using a security token as an
They can be used either in combination or separately. Client authorization grant. They can be used either in combination or
authentication using a JWT is nothing more than an alternative way separately. Client authentication using a JWT is nothing more than
for a client to authenticate to the token endpoint and must be used an alternative way for a client to authenticate to the token endpoint
in conjunction with some grant type to form a complete and meaningful and must be used in conjunction with some grant type to form a
protocol request. JWT authorization grants may be used with or complete and meaningful protocol request. JWT authorization grants
without client authentication or identification. Whether or not may be used with or without client authentication or identification.
client authentication is needed in conjunction with a JWT Whether or not client authentication is needed in conjunction with a
authorization grant, as well as the supported types of client JWT authorization grant, as well as the supported types of client
authentication, are policy decisions at the discretion of the authentication, are policy decisions at the discretion of the
authorization server. authorization server.
The process by which the client obtains the JWT, prior to exchanging The process by which the client obtains the JWT, prior to exchanging
it with the authorization server or using it for client it with the authorization server or using it for client
authentication, is out of scope. authentication, is out of scope.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
1.2. Terminology 1.2. Terminology
All terms are as defined in The OAuth 2.0 Authorization Framework All terms are as defined in The OAuth 2.0 Authorization Framework
[RFC6749], Assertion Framework for OAuth 2.0 [RFC6749], the Assertion Framework for OAuth 2.0 Client
[I-D.ietf-oauth-assertions], and JSON Web Token (JWT) [JWT]. Authentication and Authorization Grants [I-D.ietf-oauth-assertions],
and the JSON Web Token (JWT) [JWT] specifications.
2. HTTP Parameter Bindings for Transporting Assertions 2. HTTP Parameter Bindings for Transporting Assertions
The Assertion Framework for OAuth 2.0 [I-D.ietf-oauth-assertions] The Assertion Framework for OAuth 2.0 Client Authentication and
Authorization Grants [I-D.ietf-oauth-assertions] specification
defines generic HTTP parameters for transporting Assertions (a.k.a. defines generic HTTP parameters for transporting Assertions (a.k.a.
Security Tokens) during interactions with a token endpoint. This Security Tokens) during interactions with a token endpoint. This
section defines the values of those parameters for use with JWT section defines specific parameters and treatments of those
Bearer Tokens. parameters for use with JWT bearer tokens.
2.1. Using JWTs as Authorization Grants 2.1. Using JWTs as Authorization Grants
To use a JWT Bearer Token as an authorization grant, use the To use a Bearer JWT as an authorization grant, use an access token
following parameter values and encodings. request as defined in Section 4 of the Assertion Framework for OAuth
2.0 Client Authentication and Authorization Grants
[I-D.ietf-oauth-assertions] specification with the following specific
parameter values and encodings.
The value of the "grant_type" parameter MUST be The value of the "grant_type" parameter MUST be
"urn:ietf:params:oauth:grant-type:jwt-bearer". "urn:ietf:params:oauth:grant-type:jwt-bearer".
The value of the "assertion" parameter MUST contain a single JWT. The value of the "assertion" parameter MUST contain a single JWT.
The "scope" parameter may be used, as defined in the Assertion
Framework for OAuth 2.0 Client Authentication and Authorization
Grants [I-D.ietf-oauth-assertions] specification, to indicate the
requested scope.
Authentication of the client is optional, as described in
Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the
"client_id" is only needed when a form of client authentication that
relies on the parameter is used.
The following non-normative example demonstrates an Access Token The following non-normative example demonstrates an Access Token
Request with a JWT as an authorization grant (with extra line breaks Request with a JWT as an authorization grant (with extra line breaks
for display purposes only): for display purposes only):
POST /token.oauth2 HTTP/1.1 POST /token.oauth2 HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJFUzI1NiJ9. &assertion=eyJhbGciOiJFUzI1NiJ9.
skipping to change at page 5, line 45 skipping to change at page 6, line 7
grant_type=authorization_code& grant_type=authorization_code&
code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer& client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiJ9. client_assertion=eyJhbGciOiJSUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...]. eyJpc3Mi[...omitted for brevity...].
cC4hiUPo[...omitted for brevity...] cC4hiUPo[...omitted for brevity...]
3. JWT Format and Processing Requirements 3. JWT Format and Processing Requirements
In order to issue an access token response as described in The OAuth In order to issue an access token response as described in OAuth 2.0
2.0 Authorization Framework [RFC6749] or to rely on a JWT for client [RFC6749] or to rely on a JWT for client authentication, the
authentication, the authorization server MUST validate the JWT authorization server MUST validate the JWT according to the criteria
according to the criteria below. Application of additional below. Application of additional restrictions and policy are at the
restrictions and policy are at the discretion of the authorization discretion of the authorization server.
server.
o The JWT MUST contain an "iss" (issuer) claim that contains a 1. The JWT MUST contain an "iss" (issuer) claim that contains a
unique identifier for the entity that issued the JWT. unique identifier for the entity that issued the JWT.
o The JWT MUST contain a "sub" (subject) claim identifying the 2. The JWT MUST contain a "sub" (subject) claim identifying the
subject of the transaction. The subject MAY identify the resource subject of the transaction. The subject MAY identify the
owner for whom the access token is being requested. For client resource owner for whom the access token is being requested.
authentication, the subject MUST be the "client_id" of the OAuth
client. When using a JWT as an authorization grant, the subject
SHOULD identify an authorized accessor for whom the access token
is being requested (typically the resource owner, or an authorized
delegate).
o The JWT MUST contain an "aud" (audience) claim containing an a. When using a JWT as an authorization grant, the subject
audience value that identifies the authorization server, or the SHOULD identify an authorized accessor for whom the access
service provider principal entity of its controlling domain, as an token is being requested (typically the resource owner, or
intended audience. The token endpoint URL of the authorization an authorized delegate).
server MAY be used as an acceptable value for an "aud" element.
The authorization server MUST verify that it is an intended
audience for the JWT.
o The JWT MUST contain an "exp" (expiration) claim that limits the b. For client authentication, the subject MUST be the
time window during which the JWT can be used. The authorization "client_id" of the OAuth client.
server MUST verify that the expiration time has not passed,
subject to allowable clock skew between systems. The
authorization server MAY reject JWTs with an "exp" claim value
that is unreasonably far in the future.
o The JWT MAY contain an "nbf" (not before) claim that identifies 3. The JWT MUST contain an "aud" (audience) claim containing a
the time before which the token MUST NOT be accepted for value that identifies the authorization server as an intended
processing. audience. The token endpoint URL of the authorization server
MAY be used as a value for an "aud" element to identify the
authorization server as an intended audience of the JWT. JWTs
that do not identify the authorization server as an intended
audience MUST be rejected.
o The JWT MAY contain an "iat" (issued at) claim that identifies the 4. The JWT MUST contain an "exp" (expiration) claim that limits the
time at which the JWT was issued. The authorization server MAY time window during which the JWT can be used. The authorization
reject JWTs with an "iat" claim value that is unreasonably far in server MUST verify that the expiration time has not passed,
the past. subject to allowable clock skew between systems, and reject
expired JWTs. The authorization server MAY reject JWTs with an
"exp" claim value that is unreasonably far in the future.
o The JWT MAY contain a "jti" (JWT ID) claim that provides a unique 5. The JWT MAY contain an "nbf" (not before) claim that identifies
identifier for the token. The authorization server MAY ensure the time before which the token MUST NOT be accepted for
that JWTs are not replayed by maintaining the set of used "jti" processing.
values for the length of time for which the JWT would be
considered valid based on the applicable "exp" instant.
o The JWT MAY contain other claims. 6. The JWT MAY contain an "iat" (issued at) claim that identifies
the time at which the JWT was issued. The authorization server
MAY reject JWTs with an "iat" claim value that is unreasonably
far in the past.
o The JWT MUST be digitally signed by the issuer and the 7. The JWT MAY contain a "jti" (JWT ID) claim that provides a
authorization server MUST verify the signature. unique identifier for the token. The authorization server MAY
ensure that JWTs are not replayed by maintaining the set of used
"jti" values for the length of time for which the JWT would be
considered valid based on the applicable "exp" instant.
o The authorization server MUST verify that the JWT is valid in all 8. The JWT MAY contain other claims.
other respects per JSON Web Token (JWT) [JWT].
9. The JWT MUST be digitally signed or have a keyed message digest
applied by the issuer. The authorization server MUST reject
JWTs with an invalid signature or keyed message digest.
10. The authorization server MUST verify that the JWT is valid in
all other respects per JSON Web Token (JWT) [JWT].
3.1. Authorization Grant Processing 3.1. Authorization Grant Processing
If present, the authorization server MUST also validate the client JWT authorization grants may be used with or without client
credentials. authentication or identification. Whether or not client
authentication is needed in conjunction with a JWT authorization
grant, as well as the supported types of client authentication, are
policy decisions at the discretion of the authorization server.
However, if client credentials are present in the request, the
authorization server MUST validate them.
If the JWT is not valid, or the current time is not within the If the JWT is not valid, or the current time is not within the
token's valid time window for use, the authorization server MUST token's valid time window for use, the authorization server MUST
construct an error response as defined in OAuth 2.0 [RFC6749]. The construct an error response as defined in OAuth 2.0 [RFC6749]. The
value of the "error" parameter MUST be the "invalid_grant" error value of the "error" parameter MUST be the "invalid_grant" error
code. The authorization server MAY include additional information code. The authorization server MAY include additional information
regarding the reasons the JWT was considered invalid using the regarding the reasons the JWT was considered invalid using the
"error_description" or "error_uri" parameters. "error_description" or "error_uri" parameters.
For example: For example:
skipping to change at page 8, line 5 skipping to change at page 8, line 17
the "error" parameter MUST be the "invalid_client" error code. The the "error" parameter MUST be the "invalid_client" error code. The
authorization server MAY include additional information regarding the authorization server MAY include additional information regarding the
reasons the JWT was considered invalid using the "error_description" reasons the JWT was considered invalid using the "error_description"
or "error_uri" parameters. or "error_uri" parameters.
4. Authorization Grant Example 4. Authorization Grant Example
Though non-normative, the following examples illustrate what a Though non-normative, the following examples illustrate what a
conforming JWT and access token request would look like. conforming JWT and access token request would look like.
The example shows a JWT issued and signed by the system entity
identified as "https://jwt-idp.example.com". The subject of the JWT
is identified by email address as "mike@example.com". The intended
audience of the JWT is "https://jwt-rp.example.net", which is an
identifier with which the authorization server identifies itself.
The JWT is sent as part of an access token request to the
authorization server's token endpoint at "https://authz.example.net/
token.oauth2".
Below is an example JSON object that could be encoded to produce the Below is an example JSON object that could be encoded to produce the
JWT Claims Object for a JWT: JWT Claims Object for a JWT:
{"iss":"https://jwt-idp.example.com", {"iss":"https://jwt-idp.example.com",
"sub":"mailto:mike@example.com", "sub":"mailto:mike@example.com",
"aud":"https://jwt-rp.example.net", "aud":"https://jwt-rp.example.net",
"nbf":1300815780, "nbf":1300815780,
"exp":1300819380, "exp":1300819380,
"http://claims.example.com/member":true} "http://claims.example.com/member":true}
The following example JSON object, used as the header of a JWT, The following example JSON object, used as the header of a JWT,
declares that the JWT is signed with the ECDSA P-256 SHA-256 declares that the JWT is signed with the ECDSA P-256 SHA-256
algorithm. algorithm.
{"alg":"ES256"} {"alg":"ES256"}
To present the JWT with the claims and header shown in the previous To present the JWT with the claims and header shown in the previous
example as part of an access token request, for example, the client example as part of an access token request, for example, the client
might make the following HTTPS request (with extra line breaks for might make the following HTTPS request (with extra line breaks for
display purposes only): display purposes only):
POST /token.oauth2 HTTP/1.1 POST /token.oauth2 HTTP/1.1
Host: authz.example.net Host: authz.example.net
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJFUzI1NiJ9. &assertion=eyJhbGciOiJFUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...]. eyJpc3Mi[...omitted for brevity...].
J9l-ZhwP[...omitted for brevity...] J9l-ZhwP[...omitted for brevity...]
5. Security Considerations 5. Interoperability Considerations
Agreement between system entities regarding identifiers, keys, and
endpoints is required in order to achieve interoperable deployments
of this profile. Specific items that require agreement are as
follows: values for the issuer and audience identifiers, the location
of the token endpoint, and the key used to apply and verify the
digital signature or keyed message digest over the JWT. The exchange
of such information is explicitly out of scope for this
specification. In some cases, additional profiles may be created
that constrain or prescribe these values or specify how they are to
be exchanged. Examples of such profiles include the OAuth 2.0
Dynamic Client Registration Protocol [I-D.ietf-oauth-dyn-reg], OpenID
Connect Dynamic Client Registration 1.0 [OpenID.Registration], and
OpenID Connect Discovery 1.0 [OpenID.Discovery].
6. Security Considerations
No additional security considerations apply beyond those described No additional security considerations apply beyond those described
within The OAuth 2.0 Authorization Framework [RFC6749], the Assertion within The OAuth 2.0 Authorization Framework [RFC6749], the Assertion
Framework for OAuth 2.0 [I-D.ietf-oauth-assertions], and the JSON Web Framework for OAuth 2.0 Client Authentication and Authorization
Token (JWT) [JWT] specification. Grants [I-D.ietf-oauth-assertions], and the JSON Web Token (JWT)
[JWT] specifications.
6. IANA Considerations 7. IANA Considerations
6.1. Sub-Namespace Registration of 7.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant-type
urn:ietf:params:oauth:grant-type:jwt-bearer :jwt-bearer
This specification registers the value "grant-type:jwt-bearer" in the This specification registers the value "grant-type:jwt-bearer" in the
IANA urn:ietf:params:oauth registry established in An IETF URN Sub- IANA urn:ietf:params:oauth registry established in An IETF URN Sub-
Namespace for OAuth [RFC6755]. Namespace for OAuth [RFC6755].
o URN: urn:ietf:params:oauth:grant-type:jwt-bearer o URN: urn:ietf:params:oauth:grant-type:jwt-bearer
o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0 o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0
o Change controller: IETF o Change controller: IETF
skipping to change at page 9, line 10 skipping to change at page 10, line 4
This specification registers the value "grant-type:jwt-bearer" in the This specification registers the value "grant-type:jwt-bearer" in the
IANA urn:ietf:params:oauth registry established in An IETF URN Sub- IANA urn:ietf:params:oauth registry established in An IETF URN Sub-
Namespace for OAuth [RFC6755]. Namespace for OAuth [RFC6755].
o URN: urn:ietf:params:oauth:grant-type:jwt-bearer o URN: urn:ietf:params:oauth:grant-type:jwt-bearer
o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0 o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0
o Change controller: IETF o Change controller: IETF
o Specification Document: [[this document]] o Specification Document: [[this document]]
6.2. Sub-Namespace Registration of 7.2. Sub-Namespace Registration of urn:ietf:params:oauth:client-
urn:ietf:params:oauth:client-assertion-type:jwt-bearer assertion-type:jwt-bearer
This specification registers the value This specification registers the value "client-assertion-type:jwt-
"client-assertion-type:jwt-bearer" in the IANA urn:ietf:params:oauth bearer" in the IANA urn:ietf:params:oauth registry established in An
registry established in An IETF URN Sub-Namespace for OAuth IETF URN Sub-Namespace for OAuth [RFC6755].
[RFC6755].
o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client
Authentication Authentication
o Change controller: IETF o Change controller: IETF
o Specification Document: [[this document]] o Specification Document: [[this document]]
7. References 8. References
7.1. Normative References 8.1. Normative References
[I-D.ietf-oauth-assertions] [I-D.ietf-oauth-assertions]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland, Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0", "Assertion Framework for OAuth 2.0", draft-ietf-oauth-
draft-ietf-oauth-assertions-08 (work in progress), assertions-10 (work in progress), January 2013.
November 2012.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M.B., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in (JWT)", draft-ietf-oauth-json-web-token (work in
progress), December 2012. progress), December 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
RFC 6749, October 2012. 6749, October 2012.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012. for OAuth", RFC 6755, October 2012.
7.2. Informative References 8.2. Informative References
[I-D.ietf-oauth-dyn-reg]
Richer, J., Bradley, J., Jones, M., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Protocol", draft-
ietf-oauth-dyn-reg-08 (work in progress), March 2013.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-15 Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-15
(work in progress), November 2012. (work in progress), November 2012.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M.B., and E. Jay,
"OpenID Connect Discovery 1.0", March 2013.
[OpenID.Registration]
Sakimura, N., Bradley, J., and M.B. Jones, "OpenID Connect
Dynamic Client Registration 1.0", March 2013.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This profile was derived from SAML 2.0 Bearer Assertion Profiles for This profile was derived from SAML 2.0 Profile for OAuth 2.0 Client
OAuth 2.0 [I-D.ietf-oauth-saml2-bearer] by Brian Campbell and Chuck Authentication and Authorization Grants [I-D.ietf-oauth-saml2-bearer]
Mortimore. by Brian Campbell and Chuck Mortimore.
Appendix B. Document History Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-05
o Changed title from "JSON Web Token (JWT) Bearer Token Profiles for
OAuth 2.0" to "JSON Web Token (JWT) Profile for OAuth 2.0 Client
Authentication and Authorization Grants" to be more explicit about
the scope of the document per http://www.ietf.org/mail-archive/web
/oauth/current/msg11063.html.
o Numbered the list of processing rules.
o Smallish editorial cleanups to try and improve readability and
comprehensibility.
o Cleaner split out of the processing rules in cases where they
differ for client authentication and authorization grants.
o Clarified the parameters that are used/available for authorization
grants.
o Added Interoperability Considerations section.
o Added more explanatory context to the example in Section 4.
-04 -04
o Changed the name of the "prn" claim to "sub" (subject) both to o Changed the name of the "prn" claim to "sub" (subject) both to
more closely align with SAML name usage and to use a more more closely align with SAML name usage and to use a more
intuitive name. intuitive name.
o Added seriesInfo information to Internet Draft references. o Added seriesInfo information to Internet Draft references.
-03 -03
skipping to change at page 11, line 14 skipping to change at page 12, line 45
o Tracked specification name changes: "The OAuth 2.0 Authorization o Tracked specification name changes: "The OAuth 2.0 Authorization
Protocol" to "The OAuth 2.0 Authorization Framework" and "OAuth Protocol" to "The OAuth 2.0 Authorization Framework" and "OAuth
2.0 Assertion Profile" to "Assertion Framework for OAuth 2.0". 2.0 Assertion Profile" to "Assertion Framework for OAuth 2.0".
o Merged in changes between draft-ietf-oauth-saml2-bearer-11 and o Merged in changes between draft-ietf-oauth-saml2-bearer-11 and
draft-ietf-oauth-saml2-bearer-13. All changes were strictly draft-ietf-oauth-saml2-bearer-13. All changes were strictly
editorial. editorial.
-00 -00
o Created the initial IETF draft based upon o Created the initial IETF draft based upon draft-jones-oauth-jwt-
draft-jones-oauth-jwt-bearer-04 with no normative changes. bearer-04 with no normative changes.
Authors' Addresses Authors' Addresses
Michael B. Jones Michael B. Jones
Microsoft Microsoft
Email: mbj@microsoft.com Email: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
Brian Campbell Brian Campbell
 End of changes. 47 change blocks. 
144 lines changed or deleted 230 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/