JSON Web Token (JWT) Bearer Profile for OAuth 2.0Microsoftmbj@microsoft.comhttp://self-issued.info/
This specification defines the use of a JSON Web Token (JWT)
bearer token as a means of requesting an OAuth 2.0 access
token.
JSON Web Token (JWT) is a JSON-based security token encoding that enables
identity and security information to be shared across security
domains. JWTs utilize JSON data structures, as defined in
RFC 4627.
The OAuth 2.0 Authorization Protocol provides a method for making
authenticated HTTP requests to a resource using an access
token. Access tokens are issued to third-party clients by an
authorization server (AS) with the (sometimes implicit)
approval of the resource owner. In OAuth, an authorization
grant is an abstract term used to describe intermediate
credentials that represent the resource owner authorization.
An authorization grant is used by the client to obtain an
access token.
Several authorization grant types are defined to support a
wide range of client types and user experiences. OAuth also
allows for the definition of new extension grant types to
support additional clients or to provide a bridge between
OAuth and other trust frameworks.
This specification defines an extension grant type that
profiles the use of a JSON Web Token (JWT) in requesting
an OAuth 2.0 access token.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD
NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in .
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
All terms are as defined in and .
A JSON Web Token (JWT) bearer token can be used to request an
access token when a client wishes to utilize an existing trust
relationship, expressed through the semantics of the JWT,
without a direct user approval step at the authorization
server.
The process by which the client obtains the JWT, prior to
exchanging it with the authorization server, is out of scope.
The request/response flow illustrated in includes the following steps:
(A) The client sends an access token request to the
authorization server that includes a JWT bearer token and a grant_type
of http://oauth.net/grant_type/jwt/1.0/bearer.
(B) The authorization server validates the JWT per the
processing rules defined in the JWT specification and in
this specification and issues an access token.
The client includes the JWT in the access token request, the
core details of which are defined in OAuth , by specifying
http://oauth.net/grant_type/jwt/1.0/bearer as the absolute
URI value of the grant_type parameter and by adding the
following parameter:
REQUIRED. The value of the jwt parameter MUST be a single JWT
that is represented using the Compact Serialization.
OPTIONAL. The scope of the access request expressed as a
list of space-delimited strings. The value is defined by
the authorization server. If the value contains multiple
space-delimited strings, their order does not matter,
and each string adds an additional access range to the
requested scope.
Prior to issuing an access token response as described in
, the authorization
server MUST validate the JWT according to the criteria
below. If present, the authorization server MUST also
validate the client credentials. Application of additional
restrictions and policy are at the discretion of the
authorization server.
The JWT MUST contain an iss
(issuer) claim that contains a unique identifier for the
entity that issued the JWT.
The JWT MUST contain a prn
(principal) claim. The principal MUST identify the
resource owner for whom the access token is being
requested.
The JWT MUST contain an aud
(audience) claim containing a URI reference that
identifies the authorization server as the intended
audience. The authorization server MUST verify that it
is an intended audience for the JWT.
The JWT MUST contain an exp
(expiration) claim that limits the time window during
which the JWT can be used. The authorization 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.
The JWT MAY contain an iat
(issued at) claim containing the UTC time at which the
JWT was issued. This time is represented as an IntDate, as defined by .
The JWT MAY contain other claims.
The JWT MUST be digitally signed by the issuer in the
manner described in the JWT specification and the
authorization server MUST verify the signature.
The authorization server MUST verify that the JWT is
valid in all other respects per .
If the JWT is not valid or has expired, the authorization
server MUST construct an error response as defined in . The value of the error
parameter MUST be the invalid_grant error code. The
authorization server MAY include additional information
regarding the reasons the JWT was considered invalid using
the error_description or error_uri parameters.
Though non-normative, the following examples illustrate what
a conforming JWT and access token request would look like.
Authorization servers SHOULD issue access tokens with a
limited lifetime and require clients to refresh them by
requesting a new access token using the same JWT, if it is
still valid, or with a new JWT. The authorization server
SHOULD NOT issue a refresh token.
This specification registers the following parameters in the OAuth Parameters Registry
established by .
jwt
token request
IETF
[[ this document ]]
None
JSON Web Token (JWT)Microsoftmbj@microsoft.comhttp://self-issued.info/Googlebalfanz@google.comindependentve7jtb@ve7jtb.comMicrosoftyarong@microsoft.comGooglejpanzer@google.comNomura Research Instituten-sakimura@nri.co.jpFacebookpt@fb.com
This profile was derived from the SAML2 Bearer Assertion Grant
Type Profile for OAuth 2.0 by Brian
Campbell and Chuck Mortimore.
[[ to be removed by RFC editor before publication as an RFC ]]
-00
Initial draft.