identity 1.0 documentation

OpenID Connect Messages 1.0

«  OpenID Connect Standard 1.0   ::   Contents   ::   OpenID Connect Dynamic Client Registration 1.0  »

OpenID Connect Messages 1.0

Table of Contents

Based on OpenID Connect Messages 1.0 - draft 15 ( January 22, 2013 )

Abstract

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and RESTful manner.

This specification only defines the endpoints and the associated message formats. The actual use MUST be based on one of the companion protocol bindings specifications such as OpenID Connect Standard.

(draft 07)

1. Introduction

(draft 07)

1.1. Requirements Notation and Conventions

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 RFC 2119 [RFC2119].

Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.

(drat 07)

1.2. Terminology

This specification uses the terms “Access Token”, “Refresh Token”, “Authorization Code”, “Authorization Grant”, “Authorization Server”, “Authorization Endpoint”, “Client”, “Client Identifier”, “Client Secret”, “Protected Resource”, “Resource Owner”, “Resource Server”, “Token Endpoint” defined by OAuth 2.0 [OAuth2.0], “Claim Values” defined by JSON Web Token (JWT) [JWT].

This specification also defines the following terms:

Authentication
An act of verifying End-User’s posession of the previously provisioned credential.
Claim
A piece of information about an Entity that a Claims Provider asserts about that Entity.
Claims Provider
An Authorization Server that can return Claims about an Entity.
End-User
A human Resource Owner.
Entity
Something that has a separate and distinct existence and that can be identified in context. An End-User is one example of an Entity.
Personally Identifiable Information (PII)
Any information that (a) can be used to identify the natural person to whom such information relates, or (b) is or might be directly or indirectly linked to a natural person to whom such information relates.
Pairwise Pseudonymous Identifier (PPID)
An identifier that identifies the Entity to a Relying Party. An Entity’s PPID at one Relying Party cannot be correlated with the Entity’s PPID at another Relying Party.
ID Token
A token that contains Claims about the authentication event.
Issuer
An Entity that issues a set of Claims.
Issuer Identifier
A verifiable identifier for an Issuer. An Issuer Identifier is an HTTPS URL that only contains scheme, host, and OPTIONALLY, port number components. (No path component may be present.)
Message
A request or a response between an OpenID Relying Party and an OpenID Provider.
OpenID Provider (OP)
A service capable of providing Claims to a Relying Party.
OP Endpoints
Authorization Endpoint, Token Endpoint, and UserInfo Endpoint.
OpenID Request Object
A JSON object that holds the OpenID request parameters.
Relying Party (RP)
An application requiring Claims from an OpenID Provider.
Check ID Endpoint
A resource that, when presented with an ID Token by the Client, returns Claims about the user session represented by that ID Token.
UserInfo Endpoint
A Protected Resource that, when presented with an Access Token by the Client, returns Claims about the End-User represented by that Access Token.

(draft 07)

1.3. Overview

The OpenID Connect protocol, in abstract, follows the following steps.

  1. The Client sends a request to the Authorization Server‘s End-User Authorization Endpoint.
  2. The Authorization Server authenticates the End-User and obtains appropriate authorization.
  3. The Authorization Server responds with an Access Token, an Id Token, and a few other variables.
  4. The Client sends a request with the Access Token to the UserInfo Endpoint.
  5. UserInfo Endpoint returns the additional End-User information supported by the Resource Server.
  6. Optionally, the Client sends a request with the ID Token to the Authorization Server‘s Check ID Endpoint.
  7. Optionally, the Check ID Endpoint responds with authentication information pertaining to the supplied ID Token.

This specification only defines the abstract message flow and message formats. The actual use MUST be based on one of the companion protocol bindings specifications such as OpenID Connect Basic Client [OpenID.Basic] or OpenID Connect Standard [OpenID.Standard].

(draft 07)

2. Messages

In OpenID Connect protocols, in abstract, the process proceeds by the RP interacting with endpoints. There are a number of endpoints involved.

  1. Authorization Endpoint:

    The RP sends a request to the OP at the Authorization Endpoint. The OP then authenticates the End-User to find out if he is eligible to make the authorization.

    Then, upon the authorization action of the End-User, the Authorization Server returns an Authorization Response that includes Authorization Code, code.

    For some Clients, Implicit Grant may be used to obtain access_token without using code. In this case, response_type MUST include token. When id_token was specified in the response_type, then the id_token is returned from this endpoint as well.

  2. Token Endpoint:

    The Client sends the Access Token Request to the Token Endpoint to obtain an Access Token Response which includes an access_token.

  3. UserInfo Endpoint:

    The access_token MAY be sent to the UserInfo Endpoint to obtain Claims about the End-User.

(draft 13, http://openid.bitbucket.org/openid-connect-messages-1_0.html#anchor3 )

2.1. Authorization Endpoint

The RP sends an Authorization Request to the Authorization Endpoint of the OP to obtain either an Authorization Response or an ID Token or both depending on response_type and scope.

( draft 13, http://openid.bitbucket.org/openid-connect-messages-1_0.html#anchor4 )

2.1.1. Authorization Request

An Authorization Request is a message sent from an RP to the OP’s Authorization Endpoint. It is an extended OAuth 2.0 [OAuth2.0] Authorization Request. Section 4.1.1 and 4.2.1 of OAuth 2.0 [OAuth2.0] defines the OAuth 2.0 Authorization Request parameters.

In this specification, the values to the parameters are defined as follows.

response_type

This parameter controls the parameters returned in the response from the Authorization Endpoint. The OAuth 2.0 specification documents two response types:

code

When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code as defined in the OAuth 2.0 specification.

Both successful and error responses MUST be added as parameters to the query component of the response. All tokens are returned from the Token Endpoint. Authorization Servers MUST support this response_type.

token

When supplied as the value for the response_type parameter, a successful response MUST include an Access Token as defined in the OAuth 2.0 specification.

Both successful and error responses MUST be fragment-encoded.

No ID Token is provided to the Client.

OpenID Connect supports these additional response types [OAuth.Responses] that have been registered:

id_token
When supplied as the value for the response_type parameter, a successful response MUST include an ID Token. Both successful and error responses SHOULD be fragment-encoded. Authorization Servers SHOULD support this response_type.
id_token token

When supplied as the value for the response_type parameter, a successful response MUST include both an Access Token as well as an ID Token.

Both successful and error responses SHOULD be fragment-encoded. Authorization Servers MUST support this response_type.

code token

When supplied as the value for the response_type parameter, a successful response MUST include both an Access Token and an Authorization Code as defined in the OAuth 2.0 specification.

Both successful and error responses SHOULD be fragment-encoded.

code id_token

When supplied as the value for the response_type parameter, a successful response MUST include both an Authorization Code as well as an ID Token.

Both successful and error responses SHOULD be fragment-encoded.

code id_token token

When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code, an ID Token, and an Access Token.

Both successful and error responses SHOULD be fragment-encoded.

The Authorization Server MUST support all three of the code, id_token, and id_token token values for response_type. The Client may request any OAuth 2.0 registered response type supported by the Authorization Server.

scope

A space delimited, case sensitive list of ASCII string values. The values specify an additive list of voluntary Claims that are returned from the UserInfo Endpoint. The following scope values are defined:

openid

REQUIRED.

Informs the Authorization Server that the Client is making an OpenID Connect request. If the openid scope value is not present, the request MUST NOT be treated as an OpenID Connect request. This scope value requests access to the user_id Claim at the UserInfo Endpoint.

profile

OPTIONAL.

This scope value requests that access to the End-User’s default profile Claims at the UserInfo Endpoint be granted by the issued Access Token.

These claims are: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_time.

email

OPTIONAL.

This scope value requests that access to the email and email_verified Claims at the UserInfo Endpoint be granted by the issued Access Token.

address

OPTIONAL.

This scope value requests that access to address Claim at the UserInfo Endpoint be granted by the issued Access Token.

phone

OPTIONAL.

This scope value requests that access to the phone_number Claim at the UserInfo Endpoint be granted by the issued Access Token.

Other REQUIRED OAuth 2.0 parameters in the request include:

client_id
The OAuth 2.0 Client Identifier.
redirect_uri
A redirection URI where the response will be sent.

The request MAY contain the following OAuth 2.0 parameters:

state

RECOMMENDED.

An opaque value used to maintain state between the request and the callback; it can serve as a protection against XSRF attacks, among other uses.

The following extension parameters are also defined:

nonce

A random, unique string value used to mitigate replay attacks.

Use of the nonce is REQUIRED when using the implicit flow and OPTIONAL when using the code flow.

Note

display

OPTIONAL.

An ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User.

page

The Authorization Server SHOULD display authentication and consent UI consistent with a full user-agent page view.

If the display parameter is not specified this is the default display mode.

popup

The Authorization Server SHOULD display authentication and consent UI consistent with a popup user-agent window.

The popup user-agent window SHOULD be 450 pixels wide and 500 pixels tall.

touch

The Authorization Server SHOULD display authentication and consent UI consistent with a device that leverages a touch interface.

The Authorization Server MAY attempt to detect the touch device and further customize the interface.

wap
The Authorization Server SHOULD display authentication and consent UI consistent with a “feature phone” type display.
prompt

OPTIONAL.

A space delimited, case sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent. The possible values are:

none

The Authorization Server MUST NOT display any authentication or consent user interface pages.

An error is returned if the End-User is not already authenticated or the Client does not have pre-configured consent for the requested scopes.

This can be used as a method to check for existing authentication and/or consent.

login
The Authorization Server MUST prompt the End-User for reauthentication.
The Authorization Server MUST prompt the End-User for consent before returning information to the Client.
select_account
The Authorization Server MUST prompt the End-User to select a user account. This allows a user who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they may have current sessions for.

The prompt parameter can be used by the Client to make sure that the End-User is still present for the current session or to bring attention to the request.

If this parameter contains none with any other value, an error is returned.

request

OPTIONAL.

An OpenID Request Object value.

request_uri

OPTIONAL.

An URL that points to an OpenID Request Object. This is used to pass an OpenID Request Object by reference.

id_token_hint

OPTIONAL.

An ID Token passed to the Authorization server as a hint about the user’s current or past authenticated session with the client.

This SHOULD be present if prompt=none is sent. The value is a JWS [JWS] encoded ID token as signed by the issuer, the JWS [JWS] may be JWE [JWE] encrypted by the public key of the issuer for additional confidentiality.

If the id_token received by the RP was encrypted, the Client MUST decrypt the signed id_token (JWS [JWS]).

The Client MAY re-encrypt using the key that the server is capable of decrypting.

login_hint

OPTIONAL.

A hint to the authorization service as to the login identifier the user may use to authenticate at the authorization service (if necessary).

This hint can be used by an RP if it first asks the user for their email address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service.

It is recommended that the hint value match the value used for discovery. The use of this parameter is up to the IdP’s discretion.

(draft 13, http://openid.bitbucket.org/openid-connect-messages-1_0.html#auth_req )

2.1.1.1. Request Parameters

OpenID Connect uses the following OAuth 2.0 request parameters:

response_type

REQUIRED.

Value that controls the parameters returned in the response from the Authorization Endpoint.

The OAuth 2.0 specification defines two response types:

code

When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code as defined in the OAuth 2.0 specification.

Both successful and error responses MUST be added as parameters to the query component of the response. All tokens are returned from the Token Endpoint.

When used by OpenID Connect, an ID Token is also returned from the Token Endpoint.

OpenID Providers that are not Self-Issued OPs MUST support this response_type.

token

When supplied as the value for the response_type parameter, a successful response MUST include an Access Token as defined in the OAuth 2.0 specification.

Both successful and error responses MUST be fragment-encoded. No ID Token is provided to the Client; therefore, this response_type is not used by OpenID Connect.

OpenID Connect supports these additional response types [OAuth.Responses], which have been registered with IANA:

id_token

When supplied as the value for the response_type parameter, a successful response MUST include an ID Token.

Both successful and error responses SHOULD be fragment-encoded. OpenID Providers MUST support this response_type.

id_token token

When supplied as the value for the response_type parameter, a successful response MUST include both an Access Token and an ID Token.

Both successful and error responses SHOULD be fragment-encoded.

OpenID Providers MUST support this response_type.

code token

When supplied as the value for the response_type parameter, a successful response MUST include both an Access Token and an Authorization Code as defined in the OAuth 2.0 specification.

When used by OpenID Connect, an ID Token is also returned from the Token Endpoint.

Both successful and error responses SHOULD be fragment-encoded.

code id_token
When supplied as the value for the response_type parameter, a successful response MUST include both an Authorization Code and an ID Token. Both successful and error responses SHOULD be fragment-encoded.
code id_token token

When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code, an ID Token, and an Access Token.

Both successful and error responses SHOULD be fragment-encoded.

All OpenID Providers MUST support the id_token and token id_token response types and all OpenID Providers that are not Self-Issued OPs MUST also support the code response type.

The Client may use any OAuth 2.0 registered response type supported by the OpenID Provider other than token (which provides no ID Token).

client_id
REQUIRED. OAuth 2.0 Client Identifier.
scope

REQUIRED.

Space delimited, case sensitive list of ASCII OAuth 2.0 scope values.

OpenID Connect requests MUST contain the openid scope value.

OPTIONAL scope values of profile, email, address, phone, and offline_access are also defined.

See Section 2.4 for more about the scope values defined by this specification.

redirect_uri

REQUIRED. Redirection URI to which the response will be sent.

This MUST be pre-registered with the OpenID Provider.

If the Client uses the OAuth implicit grant type, the redirection URI MUST NOT use the http scheme unless the Client is a native application, in which case it MAY use the http: scheme with localhost as the hostname.

If the Client only uses the OAuth authorization_code grant type, the redirection URI MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0.

state

RECOMMENDED.

Opaque value used to maintain state between the request and the callback; it can serve as a protection against XSRF attacks, among other uses.

This specification also defines the following request parameters:

nonce

REQUIRED or OPTIONAL.

Random, unique string value used to mitigate replay attacks.

Use of the nonce is REQUIRED for all requests where an ID Token is returned directly from the Authorization Endpoint.

It is OPTIONAL when the ID Token is returned from the Token Endpoint.

display

OPTIONAL.

ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User.

The defined values are:

page
The Authorization Server SHOULD display authentication and consent UI consistent with a full User-Agent page view. If the display parameter is not specified this is the default display mode.
popup
The Authorization Server SHOULD display authentication and consent UI consistent with a popup User-Agent window. The popup User-Agent window SHOULD be 450 pixels wide and 500 pixels tall.
touch
The Authorization Server SHOULD display authentication and consent UI consistent with a device that leverages a touch interface. The Authorization Server MAY attempt to detect the touch device and further customize the interface.
wap
The Authorization Server SHOULD display authentication and consent UI consistent with a “feature phone” type display.
prompt

OPTIONAL.

Space delimited, case sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent.

The defined values are:

none

The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if the End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims.

This can be used as a method to check for existing authentication and/or consent.

login
The Authorization Server MUST prompt the End-User for reauthentication.
consent
The Authorization Server MUST prompt the End-User for consent before returning information to the Client.
select_account
The Authorization Server MUST prompt the End-User to select a user account. This allows a user who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they may have current sessions for.

The prompt parameter can be used by the Client to make sure that the End-User is still present for the current session or to bring attention to the request.

If this parameter contains none with any other value, an error is returned.

max_age

OPTIONAL.

Maximum Authentication Age. Specifies that the End-User must be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. (The max_age request parameter corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age request parameter.)

When max_age is used, the ID Token returned MUST include an auth_time Claim Value.

ui_locales

OPTIONAL.

End-User’s preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference.

For instance, the value “fr-CA fr en” represents a preference for French as spoken in Canada, then French (without a region designation), followed by English (without a region designation). An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider.

claims_locales

OPTIONAL. End-User’s preferred languages and scripts for Claims being returned, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference.

An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider.

id_token_hint

OPTIONAL. ( まえに出した事のあるID Token )

Previously issued ID Token [id_token] passed to the Authorization Server as a hint about the End-User’s current or past authenticated session with the Client.

This SHOULD be present when prompt=none is used. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return a negative response.

If the ID Token received by the RP is encrypted, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token.

For a Self-Issued ID Token, the sub (subject) of the signed ID Token MUST be sent as the kid (Key ID) of the JWE.

login_hint

OPTIONAL.

Hint to the Authorization Server about the login identifier the End-User may use to log in (if necessary).

This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service.

It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim.

The use of this parameter is left to the OP’s discretion.

acr_values

OPTIONAL.

Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server MUST use for processing requests from this Client.

The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value, as specified in Section 2.1.2.1.

claims

OPTIONAL. ( クレーム一覧 )

This parameter is used to request that specific Claims be returned. The value is a JSON object, as specified in Section 2.6.

registration

OPTIONAL. This parameter is used by the Client to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration, as specified in Section 7.2.1.

The registration parameter SHOULD NOT be used when the OP is not a Self-Issued OP.

request

OPTIONAL.

This parameter enables OpenID Connect requests to be passed in a single, self-contained parameter and to be signed and optionally encrypted. The parameter value is a Request Object.

It represents the request as JWT whose Claims are the request parameters above, as specified in Section 2.9.

When the request parameter is used, the OpenID Connect request parameter values contained in the JWT supersede those passed using the OAuth 2.0 request syntax. Even if a scope parameter is present in the Request Object, a scope parameter MUST always be passed using the OAuth 2.0 request syntax containing the openid scope value to indicate to the underlying OAuth 2.0 logic that this is an OpenID Connect request.

request_uri

OPTIONAL.

This parameter enables OpenID Connect requests to be passed by reference, rather than by value.

The request_uri value is a URL using the https scheme referencing a resource containing a Request Object value, which is a JWT containing the request parameters.

This parameter is used identically to the request parameter, other than that the Request Object is retrieved from the specified URL, rather than passed by value.

See Section 2.10 for more information on using the request_uri parameter.

(draft 17)

2.1.1.1.1. “userinfo” member

The structure of the userinfo (UserInfo Request) member is a JSON object that MAY contain the following members:

claims

OPTIONAL.

(Requested Claims): A JSON object containing a set of individual Claims being requested from the UserInfo Endpoint in addition to those requested by the scope values used.

If not present, only the UserInfo Claims held by the OP that are requested by the scope values used are returned.

For details about this claim, refer to “claims” member in “userinfo” and “id_token” section.

preferred_locales

OPTIONAL.

A list of preferred languages and scripts for the entire Claims request, represented as a JSON array of BCP47 [RFC5646] language tag values, ordered by preference.

All members of the userinfo object are OPTIONAL. Other members MAY be present and if so, SHOULD understood by both parties.

(draft 13 )

2.1.1.1.2. “id_token” member

The structure and function of the id_token (ID Token request) member of the OpenID Request Object is similar to that of the userinfo member. It MAY include the OPTIONAL claims and preferred_locales members.

The structure of these members is the same as that for the userinfo member. If the claims member is present in the id_token object, the Claims requested within it augment the Claim set that would otherwise be returned in the ID Token.

Following Claims, in addition to the claims described in “claims” member in “userinfo” and “id_token” section., MAY be requested in the ID Token by specifying it in the claims member:

user_id

OPTIONAL.

(User Identifier): The User Identifier for which an ID Token is being requested. If the specified user is not currently authenticated to the Authorization Server, they may be prompted for authenticated, unless the prompt parameter in the Authorization Request is set to none. The Claim Value in the request is an object containing the single element value.

"user_id": {"value":"248289761001"}
auth_time

OPTIONAL.

(authenticated at): Requests that the auth_time Claim be present in the ID Token response. The Claim Value in the request must be {“essential”: true} to require auth_time in the response.

If the Claim Value in the request is null the has the option of not including the claim in the response.

acr

OPTIONAL.

(Authentication Context Class Reference): Requests the desired Authentication Context Class References. The element values is an ordered array of strings representing acceptable Authentication Context Class Reference values appearing in order of preference.

"acr": {"values":["2","http://id.incommon.org/assurance/bronze"]}

In addition to the claims member, these additional members are defined within the id_token member of the OpenID Request Object:

max_age

OPTIONAL.

(max authentication age): Specifies that the End-User must be actively authenticated if any present authentication is older than the specified number of seconds. (The max_age request parameter corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age request parameter.)

It is anticipated that additional id_token parameters MAY be defined to request that additional properties hold for the authentication - for instance, that certain authentication policies be applied (in the same spirit of the OpenID 2.0 PAPE [OpenID.PAPE] auth_policies values), or that the authentication conform to the policies defined by a specified trust framework. These parameters MAY be defined by extension specifications.

All members of the id_token object are OPTIONAL. Other members MAY be present and if so, SHOULD be understood by both parties.

(draft 13)

2.1.1.1.3. “claims” member with “userinfo” and “id_token” members

The claims member is a JSON object with a member for each requested Claim. The member names are the requested Claim names. Each Claim MAY either be an essential claim or voluntary claim. The default is voluntary.

By requesting Claims as essential, the client indicates to the user that releasing these claims will ensure a smooth authorization for the specific task requested by the user. Note that even if the claims are not available because the user did not authorize their release or they are not present, the Authorization Server MUST NOT generate an error when essential claims are not returned.

The Client may request additional Claims on voluntary basis that it requires to perform other tasks offered to the user.

The member values MAY be either:

null
This indicates that this Claim is being requested in the default manner. In particular, this is a voluntary Claim.
A JSON Object

This is used to provide additional information about the Claim being requested. This specification defines the following member:

essential
OPTIONAL. If the value is set to true, this indicates that the claim being requested is an essential claim. If the value is set to false, it indicates that it is a voluntary claim. The default is false.

Other members MAY be defined to provide additional information about the requested Claim.

The Claims MAY be represented in multiple languages and scripts. To specify languages and scripts for the Claim request, BCP47 [RFC5646] language tags delimited by a “#” MUST be added to each requested Claim Name for which a particular language and script is requested. For example, the Claim family_name#ja-Kana-JP is used for expressing Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same value represented as family_name#ja-Hani-JP.

All members of the claims object are OPTIONAL.

(draft 13)

2.1.2. Authorization Request

An Authorization Request is a message sent from an RP to the OP’s Authorization Endpoint. It is an extended OAuth 2.0 [OAuth2.0] Authorization Request.

Section 4.1.1 and 4.2.1 of OAuth 2.0 [OAuth2.0] defines the OAuth Authorization Request parameters. In this specification, the values to the parameters are defined as follows.

Note

response_type

This parameter controls the parameters returned in the response from the Authorization Endpoint. The OAuth 2.0 specification documents two response types:

code

When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code as defined in the OAuth 2.0 specification.

Both successful and error responses MUST be added as parameters to the query component of the response.

All tokens are returned from the Token Endpoint.

Authorization Servers MUST support this response_type.

token

When supplied as the value for the response_type parameter, a successful response MUST include an Access Token as defined in the OAuth 2.0 specification.

Both successful and error responses MUST be fragment-encoded.

No ID Token is provided to the Client.

OpenID Connect supports these additional response types [OAuth.Responses] that have been registered:

id_token

When supplied as the value for the response_type parameter, a successful response MUST include an ID Token.

Both successful and error responses SHOULD be fragment-encoded.

Authorization Servers SHOULD support this response_type.

id_token token

When supplied as the value for the response_type parameter, a successful response MUST include both an Access Token as well as an ID Token.

Both successful and error responses SHOULD be fragment-encoded.

Authorization Servers MUST support this response_type.

code token

When supplied as the value for the response_type parameter, a successful response MUST include both an Access Token and an Authorization Code as defined in the OAuth 2.0 specification.

Both successful and error responses SHOULD be fragment-encoded.

code id_token

When supplied as the value for the response_type parameter, a successful response MUST include both an Authorization Code as well as an ID Token.

Both successful and error responses SHOULD be fragment-encoded.

code id_token token

When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code, an ID Token, and an Access Token.

Both successful and error responses SHOULD be fragment-encoded.

The Authorization Server MUST support all three of the code, id_token, and id_token token values for response_type.

The Client may request any OAuth 2.0 registered response type supported by the Authorization Server.

scope

A space delimited, case sensitive list of ASCII string values.

The values specify an additive list of voluntary Claims that are returned from the UserInfo Endpoint unless the claims_in_id_token scope value is used, in which case the requested claims are instead returned in the ID Token.

The following scope values are defined:

openid

REQUIRED. Informs the Authorization Server that the Client is making an OpenID Connect request. If the openid scope is not present, the request MUST NOT be treated as an OpenID Connect request.

This scope value requests access to the user_id Claim at the UserInfo Endpoint.

profile
OPTIONAL. This scope value requests that access to the End-User’s default profile Claims at the UserInfo Endpoint be granted by the issued Access Token. These claims are: name, family_name, given_name, middle_name, nickname, profile, picture, website, gender, birthday, zoneinfo, locale, and updated_time.
email
OPTIONAL. This scope value requests that access to the email and email_verified Claims at the UserInfo Endpoint be granted by the issued Access Token.
address
OPTIONAL. This scope value requests that access to address Claim at the UserInfo Endpoint be granted by the issued Access Token.
phone
OPTIONAL. This scope value requests that access to the phone_number Claim at the UserInfo Endpoint be granted by the issued Access Token.
claims_in_id_token

OPTIONAL. Use of this scope value switches where the Claims requested via other scope values are returned.

If this scope value is present, the voluntary claims that are requested with the profile, email, address, and phone scope values are returned in the ID Token, rather than from the UserInfo Endpoint.

If finer grained control is required, an OpenID Request Object MUST be used.

Other REQUIRED OAuth 2.0 parameters in the request include:

client_id
The OAuth 2.0 Client Identifier.
redirect_uri
A redirection URI where the response will be sent.

The request MAY contain the following OAuth 2.0 parameters:

state
RECOMMENDED. An opaque value used to maintain state between the request and the callback; it can serve as a protection against XSRF attacks, among other uses.

The following extension parameters are also defined:

nonce
A random, unique string value used to mitigate replay attacks. Use of the nonce is REQUIRED when using the implicit flow and OPTIONAL when using the code flow.
display

OPTIONAL. An ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User.

page
The Authorization Server SHOULD display authentication and consent UI consistent with a full user-agent page view. If the display parameter is not specified this is the default display mode.
popup
The Authorization Server SHOULD display authentication and consent UI consistent with a popup user-agent window. The popup user-agent window SHOULD be 450 pixels wide and 500 pixels tall.
touch

The Authorization Server SHOULD display authentication and consent UI consistent with a device that leverages a touch interface.

The Authorization Server MAY attempt to detect the touch device and further customize the interface.

wap
The Authorization Server SHOULD display authentication and consent UI consistent with a “feature phone” type display.
prompt

OPTIONAL. A space delimited, case sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent.

The possible values are:

none

The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if the End-User is not already authenticated or the Client does not have pre-configured consent for the requested scopes.

This can be used as a method to check for existing authentication and/or consent.

login
The Authorization Server MUST prompt the End-User for reauthentication.
consent
The Authorization Server MUST prompt the End-User for consent before returning information to the Client.
select_account
The Authorization Server MUST prompt the End-User to select a user account. This allows a user who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they may have current sessions for.

The prompt parameter can be used by the Client to make sure that the End-User is still present for the current session or to bring attention to the request.

If this parameter contains none with any other value, an error is returned.

request
OPTIONAL. An OpenID Request Object value.
request_uri
OPTIONAL. An URL that points to an OpenID Request Object. This is used to pass an OpenID Request Object by reference.
id_token

OPTIONAL. An ID Token passed to the Authorization Server as a hint about the user’s current or past authenticated session with the client.

This SHOULD be present if prompt=none is sent.

(draft 10)

orphan:
2.1.2.1. ID Token

Note

The ID Token is a security token that contains Claims about the authentication event and other requested Claims. The ID Token is represented as a JSON Web Token (JWT) [JWT].

The ID Token is used to manage the authentication event and user identifier and is scoped to a particular Client via the aud (audience) and nonce Claims.

The following Claims are used within the ID Token:

iss

REQUIRED.

Issuer Identifier for the Issuer of the response.

sub

REQUIRED.

Subject identifier.

A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client. (ユニークだし、再利用するなよ)

e.g. 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4.

(* 255 バイトASCIIの制限、とれています Draft 17 )

aud

REQUIRED.

Audience that this ID Token is intended for.

It MUST contain the OAuth 2.0 client_id of the Client.

azp

OPTIONAL.

Authorized Presenter. This member identifies an OAuth 2.0 Client authorized to use this ID Token as an OAuth Access Token.

It MUST contain the client_id of the Authorized Presenter. This Claim is only needed when the party requesting the ID Token is not the same as the audience of the ID Token. It MAY be included even when the Authorized Presenter is the same as the audience.

exp

REQUIRED.

Expiration time on or after which the ID Token MUST NOT be accepted for processing.

The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value.

Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. The value is the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the desired date/time.

See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.

iat

REQUIRED.

Time at which the JWT was issued. The value is the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the desired date/time.

See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.

auth_time

OPTIONAL or REQUIRED.

Time when the End-User authentication occurred, specified as the number of seconds since 1970-01-01T0:0:0Z as measured in UTC.

When a max_age request is made or when auth_time is requested as an Essential Claim, then this Claim is REQUIRED.

(The auth_time Claim semantically corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] auth_time response parameter.)

nonce

OPTIONAL or REQUIRED. ( Clientが指定したnonce)

String value used to associate a Client session with an ID Token, and to mitigate replay attacks.

The value is passed through unmodified from the Authorization Request to the ID Token.

If present in the ID Token [id_token], Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authorization Request.

If present in the Authorization Request, Authorization Servers MUST include a nonce Claim in the ID Token [id_token] with the Claim Value being the nonce value sent in the Authorization Request.

Use of the nonce is REQUIRED for all requests where an ID Token is returned directly from the Authorization Endpoint.

It is OPTIONAL when the ID Token is returned from the Token Endpoint.

at_hash

OPTIONAL or REQUIRED.

Access Token hash value. If the ID Token is issued from the Authorization Endpoint with an access_token, this is REQUIRED.

This is OPTIONAL when the ID Token is issued from the Token Endpoint. The value is produced by base64url encoding the left-most half of the hash created by hashing the access_token with the hash algorithm specified in JWS [JWA] for the alg parameter in the JWS [JWS] header.

For instance, if the alg is RS256, hash access_token with SHA-256, then take the left-most 128 bits and base64url encode them.

c_hash

OPTIONAL or REQUIRED.

Code hash value.

If the ID Token is issued from the Authorization Endpoint with a code, this is REQUIRED. This is OPTIONAL when the ID Token is issued from the Token Endpoint. The value is produced by base64url encoding the left-most half of the hash created by hashing the code with the hash algorithm specified in JWS [JWA] for the alg parameter in the JWS [JWS] header.

For instance, if the alg is HS512, hash code with SHA-512, then take the left-most 256 bits and base64url encode them.

acr

OPTIONAL.

Authentication Context Class Reference.

String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value “0” indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 [ISO29115] level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of “level 0” is appropriate. Authentications with level 0 should never be used to authorize access to any resource of any monetary value. (This corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] nist_auth_level 0.) An absolute URI or a registered name [RFC6711] MAY be used as an acr value.

amr

OPTIONAL.

Authentication Methods References.

JSON array of strings that are identifiers for authentication methods used in the authentication.

For instance, values might indicate that both password and OTP authentication methods were used.

The definition of particular values to be used in the amr Claim is beyond the scope of this specification.

sub_jwk

NOT RECOMMENDED or REQUIRED.

Public key value used to check the signature of an ID Token issued by a Self-Issued OpenID Provider, as specified in Section 7.

The key is a bare key in JWK format (not an X.509 certificate value).

Use of the sub_jwk Claim is REQUIRED when the OP is a Self-Issued OP and is NOT RECOMMENDED when the OP is not Self-Issued.

The JWT MAY contain other Claims. Any Claims used that are not understood MUST be ignored.

ID Tokens MUST be signed using JWS [JWS] and OPTIONALLY both signed and encrypted using JWS [JWS] and JWE [JWE] respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality [signing_order].

Clients MUST directly validate the ID Token per ID Token Validation [id.token.validation].

The following is a non-normative example of a base64url decoded ID Token (with line wraps for display purposes only):

{
 "iss": "https://server.example.com",
 "sub": "24400320",
 "aud": "s6BhdRkqt3",
 "nonce": "n-0S6_WzA2Mj",
 "exp": 1311281970,
 "iat": 1311280970,
 "auth_time": 1311280969,
 "acr": "urn:mace:incommon:iap:silver",
 "at_hash": "MTIzNDU2Nzg5MDEyMzQ1Ng"
}

(draft 15)

2.1.2.1.1. “userinfo” member

The structure of the userinfo (UserInfo Request) member is a JSON object that MAY contain the following members:

claims

OPTIONAL.

(Requested Claims): A JSON object containing a set of individual Claims being requested from the UserInfo Endpoint in addition to those requested by the scope values used.

If not present, only the UserInfo Claims held by the OP that are requested by the scope values used are returned. For details about this claim, refer to “claims” member in “userinfo” and “id_token” section.

preferred_locales

OPTIONAL.

A list of preferred languages and scripts for the entire Claims request, represented as a JSON array of BCP47 [RFC5646] language tag values, ordered by preference.

All members of the userinfo object are OPTIONAL. Other members MAY be present and if so, SHOULD understood by both parties

(draft 10)

2.1.2.1.2. “id_token” member

The structure and function of the id_token (ID Token request) member of the OpenID Request Object is similar to that of the userinfo member. It MAY include the OPTIONAL claims and preferred_locales members. The structure of these members is the same as that for the userinfo member. If the claims member is present in the id_token object, the Claims requested within it modify the Claim set that would otherwise be returned in the ID Token. Unlike for the userinfo member, typically these Claims will augment, rather than override the default set.

Following Claims in addition to the claims described in “claims” member in “userinfo” and “id_token” section., MAY be requested in the ID Token by specifying it in the claims member:

user_id

OPTIONAL. (User Identifier): The User Identifier for which an ID Token is being requested. If the specified user is not currently authenticated to the Authorization Server, they may be prompted for authenticated, unless the prompt parameter in the Authorization Request is set to none.

The Claim Value in the request is an object containing the single element value.

"user_id": {"value":"248289761001"}
auth_time
OPTIONAL. (authenticated at): Requests that the auth_time Claim be present in the “id_token” response. The Claim Value in the request is null.
acr

OPTIONAL. (Authentication Context Class Reference): Requests the desired Authentication Context Class References. The element values is an ordered array of strings representing acceptable Authentication Context Class Reference values appearing in order of preference.

"acr": {"values":["2","http://id.incommon.org/assurance/bronze"]}

In addition to the claims member, these additional members are defined within the id_token member of the OpenID Request Object:

max_age

OPTIONAL. (max authentication age): Specifies that the End-User must be actively authenticated if any present authentication is older than the specified number of seconds.

(The max_age request parameter corresponds to the OpenID 2.0 PAPE max_auth_age request parameter.)

It is anticipated that additional id_token parameters MAY be defined to request that additional properties hold for the authentication - for instance, that certain authentication policies be applied (in the same spirit of the OpenID 2.0 PAPE auth_policies values), or that the authentication conform to the policies defined by a specified trust framework. These parameters MAY be defined by extension specifications.

All members of the id_token object are OPTIONAL. Other members MAY be present and if so, SHOULD be understood by both parties.

(draft 10)

2.1.2.1.3. “claims” member with “userinfo” and “id_token” members

The claims member is a JSON object with a member for each requested Claim. The member names are the requested Claim names. Each Claim MAY either be an essential claim or voluntary claim. The default is voluntary.

By requesting Claims as essential, the client indicates to the user that releasing these claims will ensure a smooth authorization for the specific task requested by the user. Note that even if the claims are not available because the user did not authorize their release or they are not present, the Authorization Server MUST NOT generate an error when essential claims are not returned.

The Client may request additional Claims on voluntary basis that it requires to perform other tasks offered to the user.

The member values MAY be either:

null
This indicates that this Claim is being requested in the default manner. In particular, this is a voluntary Claim.
A JSON Object

This is used to provide additional information about the Claim being requested. This specification defines the following member:

essential
OPTIONAL. If the value is set to true, this indicates that the claim being requested is an essential claim. If the value is set to false, it indicates that it is a voluntary claim. The default is false.

Other members MAY be defined to provide additional information about the requested Claim.

The Claims MAY be represented in multiple languages and scripts. To specify languages and scripts for the Claim request, BCP47 [RFC5646] language tags delimited by a “#” MUST be added to each requested Claim Name for which a particular language and script is requested. For example, the Claim family_name#ja-Kana-JP is used for expressing Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same value represented as family_name#ja-Hani-JP.

All members of the claims object are OPTIONAL.

(draft 10)

2.1.3. Authorization Response

When the response_type in the request is token, the Authorization Response MUST return the parameters defined in section 4.2.2 of OAuth 2.0 [OAuth2.0]. This specification only supports Bearer Tokens [OAuth.Bearer]. The OAuth 2.0 response parameter “token_type” MUST be set to “Bearer”.

When the response_type in the request is code, the Authorization Response MUST return the parameters defined in section 4.1.2 of OAuth 2.0 [OAuth2.0].

When the response_type includes other values, they must be returned as defined by their registration. The id_token return type is defined in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses].

(draft 07)

2.2. Token Endpoint

The Client sends an Access Token Request to the Token Endpoint to obtain Access Token Response, which MAY include Access Token, Refresh Token, ID Token, and other variables.

(draft 07)

2.2.1. Client Authentication

During Client Registration, the Client MAY register an authentication method. If no method is registered, the default method of client_secret_basic MUST be used.

The Supported options are:

client_secret_basic
Clients in possession of a client password authenticate with the Authorization Server in accordance with section 3.2.1 of OAuth 2.0 [OAuth2.0] using HTTP Basic authentication scheme.
client_secret_post
Clients in possession of a client password authenticate with the Authorization Server in accordance with section 3.2.1 of OAuth 2.0 [OAuth2.0] by including the client credentials in the request body.
client_secret_jwt

Clients in possession of a client password create a JWT using the HS256 algorithm. The HMAC (Hash-based Message Authentication Code) is calculated using the client_secret as the shared key. The client Authenticates in accordance with section 2.2 of (JWT) Bearer Token Profiles [OAuth.JWT] and OAuth 2.0 Assertion Profile [OAuth.Assertions]. The JWT MUST contain the Claims:

iss
REQUIRED. The iss (issuer) claim. This MUST contain the client_id of the OAuth client.
prn
REQUIRED. The prn (principal) claim. This MUST contain the client_id of the OAuth client.
aud
REQUIRED. The aud (audience) claim. A value that identifies the Authorization Server as the intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server’s Token Endpoint.
jti
REQUIRED. The jti (JWT ID) claim. A unique identifier for the token. The JWT ID MAY be used by implementations requiring message de-duplication for one-time use assertions.
exp
REQUIRED. The exp (expiration) claim that limits the time window during which the JWT can be used.
iat
OPTIONAL. The iat (issued at) claim that identifies the time at which the JWT was issued.

The authentication token MUST be sent as the value of the client_assertion parameter. The value of “client_assertion_type” parameter MUST be “urn:ietf:params:oauth:client-assertion-type:jwt-bearer”.

private_key_jwt

Clients that have registered a public key sign a JWT using the RS256 algorithm if a RSA key was registered or the ES256 algorithm if a EC key was registered. The client Authenticates in accordance with section 2.2 of (JWT) Bearer Token Profiles [OAuth.JWT] and OAuth 2.0 Assertion Profile [OAuth.Assertions]. The JWT MUST contain the Claims:

iss
REQUIRED. The iss (issuer) claim. This MUST contain the client_id of the OAuth client.
prn
REQUIRED. The prn (principal) claim. This MUST contain the client_id of the OAuth client.
aud
REQUIRED. The aud (audience) claim. A value that identifies the Authorization Server as the intended audience. The Authorization Server MUST verify that it is an intended audience for the assertion. The Audience SHOULD be the URL of the Authorization Server’s Token Endpoint.
jti
REQUIRED. The jti (JWT ID) claim. A unique identifier for the token. The token ID MAY be used by implementations requiring message de-duplication for one-time use assertions.
exp
REQUIRED. The exp (expiration) claim that limits the time window during which the JWT can be used.
iat
OPTIONAL. The iat (issued at) claim that identifies the time at which the JWT was issued.

The authentication token MUST be sent as the value of the client_assertion parameter. The value of “client_assertion_type” parameter MUST be “urn:ietf:params:oauth:client-assertion-type:jwt-bearer”.

For example:

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=i1WsRn1uB1&
client_id=s6BhdRkqt3&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT

(draft 07)

2.2.2. Access Token Request

The Client obtains an Access Token by authenticating with the Authorization Server and presenting its access grant (in the form of an Authorization Code, or Refresh Token).

In addition to the client authentication parameters, if this is a Refresh Token Request, the Client MUST send the additional parameters specified in Section 6 of OAuth 2.0 [OAuth2.0].

Otherwise the Client MUST send the request parameter for the Access Token Endpoint as specified in section 4.1.3 of OAuth 2.0 [OAuth2.0].

Note

In short, follow the OAuth 2.0.

(draft 07)

2.2.3. Access Token Response

After receiving and verifying a valid and authorized Access Token Request from the Client, the Authorization Server returns a successful response that includes an Access Token and an ID Token. The parameters in the successful response are defined in Section 4.1.4 of OAuth 2.0 [OAuth2.0].

This specification further constrains that only Bearer Tokens [OAuth.Bearer] are issued at the Token Endpoint. The OAuth 2.0 response parameter “token_type” MUST be set to “Bearer”.

In addition to the OAuth 2.0 response parameters, the following parameters MUST be included in the response if the Authorization Request scope parameter contains openid:

Note that id_token MUST NOT be returned if the grant_type is not authorization_code.

id_token
The ID Token value associated with the authentication session.

Following is a non-normative example:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
}

As in the OAuth 2.0 [OAuth2.0], Clients SHOULD ignore unrecognized response parameters.

(draft 12)

2.2.4. Token Error Response

If the token request is invalid or unauthorized, the Authorization Server constructs the error response. The parameters of the Token Error Response are defined as in Section 5.2 of OAuth 2.0 [OAuth2.0].

(draft 12, http://openid.bitbucket.org/openid-connect-messages-1_0.html#anchor7 )

2.3. UserInfo Endpoint

The UserInfo Endpoint is a Protected Resource that returns Claims about the authenticated End-User.

Claims are represented by a JSON object that contains a collection of name and value pairs for the Claims.

(Draft 12, http://openid.bitbucket.org/openid-connect-messages-1_0.html#userinfo_ep )

2.3.2. UserInfo Response

If the requested schema is openid, the response MUST return a JSON object that contains the full set or subset of Claims that are defined below. Additional Claims (not specified below) MAY also be returned.

If a Claim is not returned, that Claim Name SHOULD be omitted from the JSON object representing the Claims; it SHOULD NOT be present with a null or empty string value.

Note

Drop claims if you don’t want to return.

The members MAY be represented in multiple languages and scripts. To specify the languages and scripts, BCP47 [RFC5646] language tags MUST be added to each member names delimited by a #, e.g., familyName#ja-Kana-JP for expressing Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same represented as familyName#ja-Hani-JP.

Reserved Member Definitions
Member Type Description
user_id string REQUIRED Identifier for the End-User at the Issuer.
name string End-User’s full name in displayable form including all name parts, ordered according to End-User’s locale and preferences.
given_name string Given name or first name of the End-User.
family_name string Surname or last name of the End-User.
middle_name string Middle name of the End-User.
nickname string Casual name of the End-User that may or may not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael.
preferred_username string

Shorthand name that the End-User wishes to be referred to at the RP, such as janedoe or j.doe.

This value MAY be any valid JSON string including special characters such as @, /, or whitespace. This value MUST NOT be relied upon to be unique by the RP. (See Section 2.3.2.2.)

profile string URL of End-User’s profile page.
picture string URL of the End-User’s profile picture.
website string URL of End-User’s web page or blog.
email string The End-User’s preferred e-mail address.
email_verified boolean True if the End-User’s e-mail address has been verified; otherwise false.
gender string The End-User’s gender: Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable.
birthday string The End-User’s birthday, represented as a date string in MM/DD/YYYY format. The year MAY be 0000, indicating that it is omitted.
zoneinfo string String from zoneinfo [zoneinfo] time zone database. For example, Europe/Paris or America/Los_Angeles.
locale string The End-User’s locale, represented as a BCP47 [RFC5646] language tag. This is typically an ISO 639-1 Alpha-2 [ISO639‑1] language code in lowercase and an ISO 3166-1 Alpha-2 [ISO3166‑1] country code in uppercase, separated by a dash. For example, en-US or fr-CA. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, en_US; Implementations MAY choose to accept this locale syntax as well.
phone_number string The End-User’s preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim. For example, +1 (425) 555-1212 or +56 (2) 687 2400.
address JSON object The End-User’s preferred address. The value of the address member is a JSON [RFC4627] structure containing some or all of the members defined in Section 2.4.2.1.
updated_time string Time the End-User’s information was last updated, represented as a RFC 3339 [RFC3339] datetime. For example, 2011-01-03T23:58:42+0000.

For privacy reasons, OpenID Providers MAY elect to not provide values for some schema elements as part of the openid scope.

The user_id Claim in the UserInfo Endpoint response MUST exactly match the user_id Claim in the ID Token, before using additional UserInfo Endpoint Claims.

The UserInfo Endpoint MUST return Claims in JSON format unless a different format was specified during OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration].

The UserInfo Endpoint MAY return Claims in JWT format, which can be signed and/or encrypted. The UserInfo Endpoint MUST return a content-type header to indicate the format that is being returned. The following are accepted content types:

Content-Type Format Returned
application/json plain text JSON object
application/jwt A JWT

Following is a non-normative example of such response:

{
 "user_id": "248289761001",
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}

(draft 12, http://openid.bitbucket.org/openid-connect-messages-1_0.html#anchor9 )

2.3.2.1. Address Claim

The components of a physical mailing address. Implementations MAY return only a subset of the fields of an address, depending upon the information available and the End-User’s privacy preferences.

For example, the country and region might be returned without returning more fine-grained address information.

Implementations MAY return just the full address as a single string in the formatted sub-field, or they MAY return just the individual component fields using the other sub-fields, or they MAY return both. If both variants are returned, they SHOULD be describing the same address, with the formatted address indicating how the component fields should be combined.

formatted
The full mailing address, formatted for display or use with a mailing label. This field MAY contain newlines. This is the Primary Sub-Field for this field, for the purposes of sorting and filtering.
street_address
The full street address component, which may include house number, street name, PO BOX, and multi-line extended street address information. This field MAY contain newlines.
locality
The city or locality component.
region
The state, province, prefecture or region component.
postal_code
The zip code or postal code component.
country
The country name component.

(draft 12, http://openid.bitbucket.org/openid-connect-messages-1_0.html#address_claim )

2.3.2.2. Claim Stability and Uniqueness

The user_id claim is the only claim that a client can rely upon to be stable, since the user_id claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2.1.1.

Therefore, the only guaranteed unique identifier for a given End-User is a combination of the Issuer‘s identifier and the user_id claim; other fields such as preferred_username and email MUST NOT be used as unique identifiers for a given End-User.

All other claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users, and Issuers are permitted to apply local restrictions and policies. For instance, an Issuer MAY re-use a given preferred_username or email address claim across different End-Users at different points in time, and the claimed preferred_username or email address for a given End-User MAY change over time.

(draft 12, http://openid.bitbucket.org/openid-connect-messages-1_0.html#claim.stability )

2.3.3. UserInfo Error Response

When an error condition occurs, the UserInfo Endpoint returns an Error Response. In addition to the error codes defined in Section 3.1 of OAuth 2.0 Bearer Tokens [OAuth.Bearer], this specification defines the following error codes:

invalid_schema
The requested schema is invalid or unsupported.

(draft 12, http://openid.bitbucket.org/openid-connect-messages-1_0.html#anchor10 )

2.4. Scope Values

OpenID Connect Clients use scope values as defined in 3.3 of OAuth 2.0 [RFC6749] to specify what access privileges are being requested for Access Tokens.

The scopes associated with Access Tokens determine what resources will be available when they are used to access OAuth 2.0 protected endpoints.

For OpenID Connect, scopes can be used to request that specific sets of information be made available as Claim Values. This specification describes only the scope values used by OpenID Connect.

OpenID Connect allows additional scope values to be defined and used. Scope values used that are not understood by an implementation SHOULD be ignored.

Claims requested by the following scopes are treated by Authorization Servers as Voluntary Claims.

OpenID Connect defines the following scope values:

openid

REQUIRED.

Informs the Authorization Server that the Client is making an OpenID Connect request. If the openid scope value is not present, the behavior is entirely unspecified.

profile
OPTIONAL. This scope value requests access to the End-User’s default profile Claims, which are: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at.
email
OPTIONAL. This scope value requests access to the email and email_verified Claims.
address
OPTIONAL. This scope value requests access to the address Claim.
phone
OPTIONAL. This scope value requests access to the phone_number and phone_number_verified Claims.
offline_access
OPTIONAL. This scope value requests that an OAuth 2.0 Refresh Token be issued that can be used to obtain an Access Token that grants access to the End-User’s UserInfo Endpoint even when the user is not present (not logged in).

Multiple scope values MAY be used by creating a space delimited, case sensitive list of ASCII scope values.

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 2.3.2, when a response_type value is used that results in an Access Token being issued.

However, when the response_type value used is id_token (which issues no Access Token), the resulting Claims are returned in the ID Token.

Note

response_type = id_token だったら、クレームは ID Tokenに入れる。 なぜならば、access token を返さないから。

In some cases, the End-User will be given the option to have the OpenID Provider decline to provide some or all information requested by Clients.

To minimize the amount of information that the user is being asked to disclose, a Client may elect to only request a subset of the information available from the UserInfo Endpoint.

The following is a non-normative example of a scope Request.

scope=openid profile email phone

( draft 18 )

2.4.1. UserInfo Request

Clients MAY send requests with the following parameters to the UserInfo Endpoint to obtain further information about the End-User.

access_token
REQUIRED. The Access Token obtained from an OpenID Connect Authorization Request. This parameter MUST NOT be sent if the Access Token is sent in the HTTP Authorization header as described in Section 7.1 of OAuth 2.0 [OAuth2.0]. Access Tokens sent in the authorization header MUST be Bearer tokens [OAuth.Bearer].
schema
REQUIRED. The schema in which the data is to be returned. The only defined value is openid.
id
This identifier is reserved. It MUST be ignored by the endpoint when the openid schema is used.

(draft 07)

2.4.2. UserInfo Response

If the requested schema is openid, the response MUST return a JSON object that contains the full set or a subset of the Claims that are defined below. Additional Claims (not specified below) MAY also be returned.

If a Claim is not returned, that Claim Name SHOULD be omitted from the JSON object representing the Claims; it SHOULD NOT be present with a null or empty string value.

The members MAY be represented in multiple languages and scripts. To specify the languages and scripts, BCP47 [RFC5646] language tags MUST be added to each member names delimited by a #, e.g., familyName#ja-Kana-JP for expressing Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same represented as familyName#ja-Hani-JP.

Table 1: Reserved Member Definitions
Member Type Description
user_id

string

REQUIRED Identifier for the End-User at the Issuer.

name

string

End-User’s full name in displayable form including all name parts, ordered according to End-User’s locale and preferences.

given_name

string

Given name or first name of the End-User.

family_name

string

Surname or last name of the End-User.

middle_name

string

Middle name of the End-User.

nickname

string

Casual name of the End-User that MAY or MAY not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael.

profile

string

URL of End-User’s profile page.

picture

string

URL of the End-User’s profile picture.

website

string

URL of End-User’s web page or blog.

email

string

The End-User’s preferred e-mail address.

verified

boolean

True if the End-User’s e-mail address has been verified; otherwise false.

gender

string

The End-User’s gender: Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable.

birthday

string

The End-User’s birthday, represented as a date string in MM/DD/YYYY format. The year MAY be 0000, indicating that it is omitted.

zoneinfo

string

String from zoneinfo [zoneinfo] time zone database. For example, Europe/Paris or America/Los_Angeles.

locale

string

The End-User’s locale, represented as a BCP47 [RFC5646] language tag. This is typically an ISO 639-1 Alpha-2 [ISO639‑1] language code in lowercase and an ISO 3166-1 Alpha-2 [ISO3166‑1] country code in uppercase, separated by a dash. For example, en-US or fr-CA. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, en_US; Implementations MAY choose to accept this locale syntax as well.

phone_number

string

The End-User’s preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this claim. For example, +1 (425) 555-1212 or +56 (2) 687 2400.

address

JSON object

The End-User’s preferred address. The value of the address member is a JSON [RFC4627] structure containing some or all of the members defined in Section 2.4.2.1.

updated_time

string

Time the End-User’s information was last updated, represented as a RFC 3339 [RFC3339] datetime. For example, 2011-01-03T23:58:42+0000.

For privacy reasons, OpenID Providers MAY elect to not provide values for some schema elements as part of the openid scope.

The user_id claim in the UserInfo Endpoint response MUST exactly match the user_id claim in the ID Token, before using additional UserInfo Endpoint claims.

The UserInfo Endpoint MUST return Claims in JSON format unless a different format was specified during OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration]. The UserInfo Endpoint MAY return Claims in JWT format, which can be signed and/or encrypted. The UserInfo Endpoint MUST return a content-type header to indicate the format that is being returned. The following are accepted content types:

Accepted Content Types for UserInfo Endpoint response
Content-Type Format Returned
application/json plain text JSON object
application/jwt A JWT

The following is a non-normative example of such a response:

{
 "user_id": "248289761001",
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}

(draft 07 : http://openid.bitbucket.org/openid-connect-messages-1_0.html#anchor14 )

2.4.2.1. Address Claim

The components of a physical mailing address. Implementations MAY return only a subset of the fields of an address, depending upon the information available and the End-User’s privacy preferences. For example, the country and region might be returned without returning more fine-grained address information.

Implementations MAY return just the full address as a single string in the formatted sub-field, or they MAY return just the individual component fields using the other sub-fields, or they MAY return both. If both variants are returned, they SHOULD be describing the same address, with the formatted address indicating how the component fields should be combined.

formatted
The full mailing address, formatted for display or use with a mailing label. This field MAY contain newlines. This is the Primary Sub-Field for this field, for the purposes of sorting and filtering.
street_address
The full street address component, which may include house number, street name, PO BOX, and multi-line extended street address information. This field MAY contain newlines.
locality
The city or locality component.
region
The state, province, prefecture or region component.
postal_code
The zip code or postal code component.
country
The country name component.

(draft 07: http://openid.bitbucket.org/openid-connect-messages-1_0.html#address_claim )

2.4.3. UserInfo Error Response

When an error condition occurs, the UserInfo Endpoint returns an Error Response. In addition to the error codes defined in section 3.1 of OAuth 2.0 Bearer Tokens [OAuth.Bearer], this specification defines the following error codes:

invalid_schema
The requested schema is invalid or unsupported.

(draft 07)

2.5. Claim Types

The UserInfo Endpoint MAY return the following three types of Claims:

Normal Claims
Claims that are directly asserted by the OpenID Provider.
Aggregated Claims
Claims that are asserted by a Claims Provider other than the OpenID Provider but are returned by OpenID Provider.
Distributed Claims
Claims that are asserted by a Claims Provider other than the OpenID Provider but are returned as references by the OpenID Provider.

The UserInfo endpoint MUST support normal Claims.

Aggregated and Distributed Claims support is OPTIONAL.

(draft 13)

2.5.1. Normal Claims

Normal Claims are represented as members in a JSON object. The Claim Name is the member name and the Claim Value is the member value.

The following is a non-normative normal Claims response:

{
 "name": "Jane Doe"
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}

(draft13)

2.5.2. Aggregated and Distributed Claims

Aggregated and distributed Claims are represented by using special _claim_names and _claim_sources members of the JSON object containing the Claims.

_claim_names

This value is a JSON object whose member names are the Claim Names for the Aggregated and Distributed Claims.

The member values are references to the member names in the _claim_sources member from which the actual Claim Values can be retrieved.

_claim_sources

This value is a JSON object whose member names are referenced by the member values of the _claim_names member.

The member values contain sets of Aggregated Claims or reference locations for Distributed Claims.

The member values can have one of the following formats depending on whether it is providing Aggregated or Distributed Claims:

Aggregated Claims

A JSON object that MUST contain the JWT member whose value is a JWT [JWT] that MUST contain all the Claims in the _claim_names object that references the corresponding _claim_sources member.

Other members MAY be present if they are understood by both parties.

JWT
REQUIRED. JWT Value.
Distributed Claims

A JSON object that contains the following members and values:

endpoint
REQUIRED. The value is the OAuth 2.0 resource endpoint from which the associated Claim can be retrieved. The endpoint URL MUST return the Claim as a JWT.
access_token

OPTIONAL. Access Token enabling retrieval of the Claims from the endpoint URL by using the OAuth 2.0 Bearer [OAuth.Bearer] scheme.

Claims SHOULD be requested using the Authorization Request header field and Claims Sources MUST support this method.

If the Access Token is not available, Clients MAY need to retrieve the Access Token out of band or use an a priori Access Token that was negotiated between the Claim Source and Client, or the Claim Source MAY reauthenticate the End-User and/or reauthorize the Client.

Other members MAY be present, if understood by both parties.

The following is a non-normative response with Aggregated Claims:

Claims Provider A contains the following Claims for Jane Doe:

{
 "address": {
   "street_address": "1234 Hollywood Blvd.",
   "locality": "Los Angeles",
   "region": "CA",
   "postal_code": "90210",
   "country": "US"},
 "phone_number": "+1 (310) 123-4567"
}

Claims Provider A signs the JSON Claims, resulting in a signed JWT:

jwt_header.jwt_part2.jwt_part3

Authorization Server returns Jane Doe’s Aggregated Claims from Claims Provider A:

{
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "birthdate": "2001-03-23",
 "eye_color": "blue",
 "email": "janedoe@example.com",

 "_claim_names": {
  "address": "src1",
  "phone_number": "src1"

 },
 "_claim_sources": {
  "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
 }
}

The following is a non-normative response with Distributed Claims:

Claims Provider A (Jane Doe’s Bank) contains the following Claims for Jane Doe:

{
 "shipping_address": {
   "street_address": "1234 Hollywood Blvd.",
   "locality": "Los Angeles",
   "region": "CA",
   "postal_code": "90210",
   "country": "US"},
 "payment_info": "Some_Card 1234 5678 90123 4562",
 "phone_number": "+1 (310) 123-4567"
}

A Claims Provider B (Credit Agency) contains the following Claims for Jane Doe:

{
 "credit_score": "650"
}

Authorization Server returns Jane Doe’s Claims along with the Distributed Claims from Claims Provider A and B by sending the Access Tokens and URL locations where the Claims may be retrieved:

{
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "birthdate": "2001-03-23",
 "eye_color": "blue",
 "_claim_names": {
  "payment_info": "src1",
  "shipping_address": "src1",
  "credit_score": "src2"
 },
 "_claim_sources": {
  "src1": {"endpoint": "https://bank.example.com/claimsource"},
  "src2": {"endpoint": "https://creditagency.example.com/claimshere",
           "access_token": "ksj3n283dke"}
 }
}
orphan:

2.7. Claim Types

The UserInfo Endpoint MAY return the following three types of Claims:

Normal Claims
Claims that are directly asserted by the OpenID Provider.
Aggregated Claims
Claims that are asserted by a Claims Provider other than the OpenID Provider but are returned by OpenID Provider.
Distributed Claims
Claims that are asserted by a Claims Provider other than the OpenID Provider but are returned as references by the OpenID Provider.

The UserInfo endpoint MUST support normal Claims.

Aggregated and Distributed Claims support is OPTIONAL.

(draft 15)

2.7.1. Normal Claims

Normal Claims are represented as members in a JSON object. The Claim Name is the member name and the Claim Value is the member value.

The following is a non-normative normal Claims response:

{
 "name": "Jane Doe"
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}

(draft 15)

2.7.2. Aggregated and Distributed Claims

Aggregated and distributed Claims are represented by using special _claim_names and _claim_sources members of the JSON object containing the Claims.

_claim_names
JSON object whose member names are the Claim Names for the Aggregated and Distributed Claims. The member values are references to the member names in the _claim_sources member from which the actual Claim Values can be retrieved.
_claim_sources

JSON object whose member names are referenced by the member values of the _claim_names member. The member values contain sets of Aggregated Claims or reference locations for Distributed Claims. The member values can have one of the following formats depending on whether it is providing Aggregated or Distributed Claims:

Aggregated Claims

JSON object that MUST contain the JWT member whose value is a JWT [JWT] that MUST contain all the Claims in the _claim_names object that references the corresponding _claim_sources member. Other members MAY be present if they are understood by both parties.

JWT
REQUIRED. JWT value containing claim values.
Distributed Claims

JSON object that contains the following members and values:

endpoint
REQUIRED. OAuth 2.0 resource endpoint from which the associated Claim can be retrieved. The endpoint URL MUST return the Claim as a JWT.
access_token
OPTIONAL. Access Token enabling retrieval of the Claims from the endpoint URL by using the OAuth 2.0 Bearer Token Usage [RFC6750] protocol. Claims SHOULD be requested using the Authorization Request header field and Claims Sources MUST support this method. If the Access Token is not available, Clients MAY need to retrieve the Access Token out of band or use an a priori Access Token that was negotiated between the Claim Source and Client, or the Claim Source MAY reauthenticate the End-User and/or reauthorize the Client.

Other members MAY be present, if understood by both parties.

The following is a non-normative response with Aggregated Claims:

Claims Provider A contains the following Claims for Jane Doe:

{
 "address": {
   "street_address": "1234 Hollywood Blvd.",
   "locality": "Los Angeles",
   "region": "CA",
   "postal_code": "90210",
   "country": "US"},
 "phone_number": "+1 (310) 123-4567"
}

Claims Provider A signs the JSON Claims, resulting in a signed JWT:

jwt_header.jwt_part2.jwt_part3

Authorization Server returns Jane Doe’s Aggregated Claims from Claims Provider A:

{
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "birthdate": "2001-03-23",
 "eye_color": "blue",
 "email": "janedoe@example.com",
 "_claim_names": {
   "address": "src1",
   "phone_number": "src1"
 },
 "_claim_sources": {
   "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
 }
}

The following is a non-normative response with Distributed Claims:

Claims Provider A (Jane Doe’s Bank) contains the following Claims for Jane Doe:

{
 "shipping_address": {
   "street_address": "1234 Hollywood Blvd.",
   "locality": "Los Angeles",
   "region": "CA",
   "postal_code": "90210",
   "country": "US"},
 "payment_info": "Some_Card 1234 5678 90123 4562",
 "phone_number": "+1 (310) 123-4567"
}

Claims Provider B (Credit Agency) contains the following Claims for Jane Doe:

{
 "credit_score": "650"
}

Authorization Server returns Jane Doe’s Claims along with the Distributed Claims from Claims Provider A and Claims Provider B by sending the Access Tokens and URL locations where the Claims may be retrieved:

{
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "birthdate": "2001-03-23",
 "eye_color": "blue",
 "_claim_names": {
   "payment_info": "src1",
   "shipping_address": "src1",
   "credit_score": "src2"
  },
 "_claim_sources": {
   "src1": {"endpoint":
              "https://bank.example.com/claimsource"},
   "src2": {"endpoint":
              "https://creditagency.example.com/claimshere",
            "access_token": "ksj3n283dke"}
 }
}

(draft 15)

2.9. Request Object

The request parameter enables OpenID Connect requests to be passed in a single, self-contained parameter and to be signed and optionally encrypted. It represents the request as a JWT whose Claims are the request parameters specified in Section 2.1.1.1. This JWT is called a Request Object.

Support for the request parameter is OPTIONAL. The request_parameter_supported Discovery result indicates whether the OP supports this parameter. Should an OP not support this parameter and an RP uses it, the OP MUST return the request_not_supported error.

When the request parameter is used, the OpenID Connect request parameter values contained in the JWT supersede those passed using the OAuth 2.0 request syntax. However, some parameters MAY be passed using the OAuth 2.0 request syntax even when a Request Object is used; this would typically be done to enable a cached, pre-signed (and possibly pre-encrypted) Request Object value to be used containing the fixed request parameters, while parameters that may vary with each request, such as state and nonce, are passed as OAuth 2.0 parameters.

Even if a scope parameter is present in the Request Object value, a scope parameter MUST always be passed using the OAuth 2.0 request syntax containing the openid scope value to indicate to the underlying OAuth 2.0 logic that this is an OpenID Connect request.

Note

scope は必ずOAuthで渡す事

The Request Object MAY be signed or unsigned (plaintext). When it is plaintext, this is indicated by use of the none algorithm [JWA] in the JWS header. If signed, the Request Object SHOULD contain the Claims iss (issuer) and aud (audience) as members, with their semantics being as defined in the JWT [JWT] specification.

The Request Object MAY also be encrypted using JWE [JWE], with nested signing and encryption performed as described in the JWT [JWT] specification.

request and request_uri parameters MUST NOT be included in Request Objects.

An example set of Request Object Claims before base64url encoding and JWS signing is as follows:

{
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.org/cb",
 "scope": "openid",
 "state": "af0ifjsldkj",
 "login_hint": "janedoe@example.org",
 "max_age": 86400,
 "claims":
  {
   "userinfo":
    {
     "given_name": {"essential": true},
     "nickname": null,
     "email": {"essential": true},
     "email_verified": {"essential": true},
     "picture": null
    },
   "id_token":
    {
     "auth_time": {"essential": true},
     "acr": { "values":["urn:mace:incommon:iap:silver"] }
    }
  }
}

( draft 18 , http://openid.bitbucket.org/openid-connect-messages-1_0.html#RequestObject )

2.10. Using the “request_uri” Parameter

The request_uri parameter enables OpenID Connect requests to be passed by reference, rather than by value. This parameter is used identically to the request parameter, other than that the Request Object value is retrieved from the resource at the specified URL, rather than passed by value.

The request_uri_parameter_supported Discovery result indicates whether the OP supports this parameter. Should an OP not support this parameter and an RP uses it, the OP MUST return the request_uri_not_supported error.

When the request_uri parameter is used, the OpenID Connect request parameter values contained in the referenced JWT supersede those passed using the OAuth 2.0 request syntax. However, some parameters MAY be passed using the OAuth 2.0 request syntax even when a request_uri is used; this would typically be done to enable a cached, pre-signed (and possibly pre-encrypted) Request Object value to be used containing the fixed request parameters, while parameters that may vary with each request, such as state and nonce, are passed as OAuth 2.0 parameters.

Even if a scope parameter is present in the referenced Request Object, a scope parameter MUST always be passed using the OAuth 2.0 request syntax containing the openid scope value to indicate to the underlying OAuth 2.0 logic that this is an OpenID Connect request.

Servers MAY cache the contents of the resources referenced by request URIs. If the contents of the referenced resource could ever change, the URI SHOULD include the base64url encoded SHA-256 hash of the referenced resource contents as the fragment component of the URI. If the fragment value used for a URI changes, that signals the server that any cached value for that URI with the old fragment value is no longer valid.

Note that Clients MAY pre-register request_uri values using the request_uris parameter defined in Section 2 of the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specification.

( draft 18, http://openid.bitbucket.org/openid-connect-messages-1_0.html#RequestUriParameter )

2.10.1. “request_uri” Rationale

Note

論理的根拠。基本原則。

  • request パラメータのデータがでかすぎる

There are several reasons that one might choose to use the request_uri parameter:

The set of request parameters can become large, and may exceed browser URI size limitations. Passing the request parameters by reference can solve this problem. Passing a request_uri value, rather than a complete request by value, may reduce request latency. Most requests for Claims from an RP are constant. The request_uri is a way of creating and sometimes also signing and encrypting a constant set of request parameters in advance. (The request_uri value becomes an “artifact” representing a particular fixed set of request parameters.) Pre-registering a fixed set of request parameters at registration time enables OPs to cache and pre-validate the request parameters at registration time, meaning they need not be retrieved at request time.

Note

URLにRequest Objectのハッシュ追加しなくてよいすかね。

( draft 18,, http://openid.bitbucket.org/openid-connect-messages-1_0.html#RequestUriRationale )

3. Serializations

Parameter names and values MAY be JSON serialized into a JSON structure.

(draft 07: http://openid.bitbucket.org/openid-connect-messages-1_0.html#Serializations )

3.1. JSON Serialization

The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. Each parameter MAY have JSON Structure as its value.

Following is a non-normative example of such serialization:

{
 "access_token":"SlAV32hkKG",
 "expires_in":3600,
 "refresh_token":"8xLOxBtZp8"
}

(draft 07: http://openid.bitbucket.org/openid-connect-messages-1_0.html#js )

4. Signatures and Encryption

Depending on the transport through which the messages are sent, the integrity of the message may not be guaranteed and the originator of the message may not be authenticated. To mitigate these risks, OpenID Connect messages MAY utilize JSON Web Signature (JWS) [JWS] to sign the content.

To achieve message confidentiality, OpenID Connect messages MAY use JSON Web Encryption (JWE) [JWE] to encrypt the content.

When the message is both signed and encrypted, it MUST be signed first then encrypted. The value of the typ parameter in the enclosing JWT header MUST be “JWS”

(draft 07: http://openid.bitbucket.org/openid-connect-messages-1_0.html#sigenc )

4.1. Supported Algorithms

The server advertises its supported signing and encryption algorithms in its discovery document. The related elements are:

userinfo_algs_supported
A JSON array containing a list of the JWS [JWS] and JWE [JWE] signing and encryption algorithms supported by the UserInfo Endpoint.
id_token_algs_supported
A JSON array containing a list of the JWS [JWS] and JWE [JWE] signing and encryption algorithms supported by the Authorization Server for the ID Token.
request_object_algs_supported
A JSON array containing a list of the JWS [JWS] and JWE [JWE] signing and encryption algorithms supported by the Authorization Server for the OpenID Request Object. Servers SHOULD support HS256.
token_endpoint_auth_algs_supported
A JSON array containing a list of the JWS [JWS] signing algorithms supported by the Token Endpoint for the private_key_jwt method. Servers SHOULD support RS256.

The Client registers its required algorithms for Signing and Encryption using the following Registration parameters:

require_signed_request_object
OPTIONAL. The JWS [JWS] signature algorithm that MUST be required by the Authorization Server. All OpenID Request Objects from this client_id MUST be rejected if not signed by this algorithm.
userinfo_signed_response_algs
OPTIONAL. The JWS [JWS] signature algorithm required for userinfo responses. If this is specified the response will be JWT [JWT] serialized.
userinfo_encrypted_response_algs
OPTIONAL. A space separated list of the JWE [JWE] alg and enc algorithms required for userinfo responses. If this is requested in combination with signing the response MUST signed first then encrypted. If this is specified the response will be JWT [JWT] serialized.
id_token_signed_response_algs
OPTIONAL. The JWS [JWS] signing algorithm required for id_token issued to this client_id. The default if not specified is HS256 using the provided client_secret as the shared key.
id_token_encrypted_response_algs
OPTIONAL. A space separated list of the JWE [JWE] alg and enc algorithms required for :term`id_token` issued to this client_id. If this is requested the response MUST be signed then encrypted. The default if not specified is no encryption.

(defat 07: http://openid.bitbucket.org/openid-connect-messages-1_0.html#sigenc.alg )

4.2. Keys

The Server advertises its supported signing and encryption algorithms in its discovery document. The related elements are:

The Provider provides its public Keys during Discovery in the following elements:

jwk_url
URL of the OP’s JSON Web Key [JWK] document that contains the Server’s signing key that is used for JWS signing the JWT. It MAY also be used by the Client to JWE encrypt the JWT to the Server if x509_encryption_url or jwk_encryption_url is not specified, but this is discouraged. A separate encryption key SHOULD be used.
jwk_encryption_url
URL of the OP’s JSON Web Key [JWK] document that contains the Server’s encryption key that is used by the Client to JWE encrypt the JWT to the Server. If it is not present, its value is the same as the URL provided by jwk_url.
x509_url
URL of the OP’s X.509 certificates in PEM format that are used by the Server for Signing the JWT. It MAY also be used by the Client to JWE Encrypt the JWT to the Server if x509_encryption_url is not specified and the key usage includes keyEncipherment.
x509_encryption_url
URL of the OP’s X.509 certificates in PEM format that contains the Server’s encryption key that is used by the Client to JWE encrypt the JWT to the Server. If it is not present, the URL provided by the x509_url is used instead. The certificate MUST include keyEncipherment in the key usage.

Todo

keyEncipherment seems to be abrupt here. X.509 Key Usage for Connect should be described somewhere.

The Client provides its public Keys during Registration, in the following elements:

jwk_url
OPTIONAL. URL for the Client’s JSON Web Key [JWK] document that is used for JWS [JWS] signing of the Request Objects. If jwk_encryption_url is not provided, it is also used by the Server for JWE [JWE] encryption of JWT [JWT] to the Client.
jwk_encryption_url
OPTIONAL. URL for the Client’s JSON Web Key [JWK]. It is used by the Server for JWE [JWE] encryption of the response objects.
x509_url
OPTIONAL. URL for the Client’s PEM encoded X.509 Certificate or Certificate chain. It is used by the Client for JWS [JWS] signing of the request objects. If x509_encryption_url is not present, it is also used for JWE [JWE] encryption of the JWT [JWT] to the Client if the key usage includes keyEncipherment.
x509_encryption_url
OPTIONAL. URL for the Client’s PEM encoded X.509 Certificate or Certificate chain, used for JWE [JWE] encryption of JWT [JWT] to the Client.

If keys are specified in both x509 and jwk, they MUST be the same keys.

Key algorithms like Elliptic Curve signing and key agreement require separate keys for signing and encryption for security. For RSA a single key MAY be used for both, but it is good practice to separate them.

(draft 07: http://openid.bitbucket.org/openid-connect-messages-1_0.html#sigenc.key )

4.3. Signing

The signing party MUST select a signature algorithm based on the supported algorithms of the recipient in Section 4.1.

Symmetric Signatures
When using HMAC Signatures, the alg Claim of the JWS header MUST be set to the appropriate algorithm as defined in JSON Web Signature [JWS]. The client_secret MUST be used as the signature key.
Asymmetric Signatures

When using RSA or ECDSA Signatures, the alg Claim of the JWS header MUST be set to the appropriate algorithm as defined in JSON Web Signature [JWS].

The private key MUST be the one associated with the Public Signing Key provided in Section 4.2.

If there are multiple keys in the referenced JWK document , the kid MUST be specified in the JWS header.

If there are multiple certificates at the referenced certificate location, then x5t MUST be specified in the JWS header. The key usage of the respective keys MUST include signature. In particular, if the key found through x5u is used, the key usage MUST include digitalSignature.

Note

Key Usage “digitalSignature” should be described with more words.

( draft 07: http://openid.bitbucket.org/openid-connect-messages-1_0.html#sigs )

4.4. Encryption

The encrypting party MUST select an encryption algorithm based on the supported algorithms of the recipient in Section 4.1.

All JWT MUST be signed before encryption to provide integrity and to verify the Issuer.

Symmetric Encryption algorithms that provide an integrated integrity check MUST be used if supported by both the sender and receiver. The A128GCM and A256GCM algorithms support this.

Symmetric Encryption
Use the client_secret to KeyWrap a random Content Encryption Key to be used for encrypting the signed JWT.
Asymmetric Encryption RSA

Use the link registered/discovered in Section 4.2 to retrieve the relevant key. The jwk_encryption_url or x509_encryption_url link MUST be used if provided.

If there are multiple keys in the referenced JWK document, the kid MUST be specified in the JWS header.

If there are multiple certificates at the referenced certificate location, then x5t MUST be specified in the JWS header. Use the supported RSA KeyWrap algorithm to KeyWrap a random Content Encryption Key to be used for encrypting the signed JWT.

The key usage of the respective keys MUST include encryption. In particular, if the key found through x5u is used, the key usage MUST include keyEncipherment.

Asymmetric Encryption Elliptic Curve

Create an ephemeral Elliptic Curve public key for the epk element of the JWE header. Use the link registered/discovered in Section 4.2 to retrieve the relevant key.

The jwk_encryption_url or x509_encryption_url link MUST be used if provided.

If there are multiple keys in the referenced JWK document, the kid MUST be specified in the JWE header.

If there are multiple certificates at the referenced certificate location, then x5t MUST be specified in the JWS header.

Use the ECDH-ES algorithm to KeyWrap a random Content Encryption Key to be used for encrypting the signed JWT.

The key usage of the respective keys MUST include encryption. In particular, if the key found through x5u is used, the key usage MUST include keyEncipherment.

( draft 07 : http://openid.bitbucket.org/openid-connect-messages-1_0.html#enc )

5. Verification

(draft 07)

5.1. Authorization Request Verification

Authorization Request Verification consists of two main steps. (1) Encryption and Signature validation of the value of request or the content of request_uri, (2) Parameter verification.

If an OpenID Request Object was sent in the request parameter or by reference in the request_uri parameter, the Request Object MUST verify as JWS [JWS] or JWE [JWE] objects that are encoded in the JWT [JWT].

(draft 07 : http://openid.bitbucket.org/openid-connect-messages-1_0.html#anchor20)

5.1.1. Encrypted Request Object

If the Authorization Server has advertised JWE encryption algorithms in the request_object_algs_supported element of its Discovery Document, these are used by the Client to JWE encrypt the JWT.

The Authorization Server MUST decode the JWT in accordance with JSON Web Encryption [JWE] specification. The result MAY be either OpenID Request Object or a JWS Signed JWT. In the latter case, the signature verification MUST be performed as defined in Signed Request Object.

The Authorization Server MUST return the error if there is a decryption error.

Note

Decription error should be JWE decription error. Look at JWE error.

( draft 07 )

5.1.2. Signed Request Object

To perform Signature Verification, the alg parameter in the JWT header MUST match the value of the require_signed_request_object set during Client Registration [OpenID.Registration] or otherwise pre-registered value.

The signature must be validated against the key registered for that client_id and algorithm, in accordance with the JSON Web Signature [JWS] specification.

The Authorization Server MUST return the error authorization response if there is a signature validation error.

Todo

Signature validation error should be looked at JSON Web Signature (JWS).

( draft 07 )

5.1.3. Parameter Verification

The Authorization Server MUST construct the Authorization Request Message from the OpenID Request Object and other parameters. Note that if the same parameter exists both in the OpenID Request Object and other parameters, the former takes precedence. Using this Authorization Request Message, the Authorization Server performs the following steps of the request verification:

  1. The Authorization Server MUST understand all the parameters except for the unsupported claims. If there is any parameters that it does not understand except for the unsupported claims, it MUST return an error response.

  2. The Authorization Server MUST verify that all the OAuth 2.0 variables according to OAuth 2.0.

  3. The Authorization Server MUST verify that all the required parameters are present.

  4. If the User ID claim as a member of id_token claim is requested with a specific value, the Authorization Server MUST only send a positive response if that user has an active session with the authorization server.

    The Authorization server MUST not reply with an ID Token or Access Token for a different user, even if they have an active session with the Authorization Server.

  5. If the acr required claim is requested as a member of id_token member with values as a paramater, the Authorization Server MUST return a acr claim value that matches one of the requested values. The Authorization server MAY ask the user to re-authenticate with additional factors to meet the requirements.

    If this is a required claim and the requirement cannot be met, then the Authorization Server MUST return an error.

    The client MAY make this claim optional by including “optional”: true in the acr object.

    If the claim is optional and the requested value for the user cannot be provided, the Authorization server SHOULD return the sessions current acr as the value of the acr claim.

    If the claim is optional the Authorization server is not requited to provide this claim in it’s response.

If the Authorization Server encounters any error, it MUST return the error response.

Todo

Check error response... JW*? Connect bindings?

( draft 07)

5.2. ID Token Verification

To verify the validity of ID Token in the Authorization or Token Endpoint Response, the Client MUST do the following:

  1. If the Client has provided an id_token_encrypted_response_algs parameter during Registration, decrypt the id_token [JWE], using the key pair specified during Registration.
  2. The Client MUST validate that the client_id in the aud (audience) Claim is one it has registered for the Issuer identified by the value in the iss (issuer) Claim. The ID Token MUST be rejected if the value of aud (audience) is not valid for the Issuer.
  3. The Client MUST verify the ID Token signature according to Section 5 of JWS [JWS] using the algorithm specified in the alg parameter of the JWT header.
  4. The value of alg SHOULD be the algorithm sent by the Client in the id_token_signed_response_algs parameter during Registration.
  5. If the alg parameter of the JWT header is one of HS256, HS384, or HS512, the client_secret for the client_id contained in the aud (audience) Claim is used to validate the signature.
  6. For other Signing algorithms the Client must use the signing key provided in Discovery by the Issuer exactly matching the value of the iss (issuer) Claim.
  7. The current time MUST be less than the value of the exp Claim.
  8. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authorization Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is client specific.
  9. If the acr Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of acr Claim Values is out of scope for this specification.
  10. If the auth_time Claim was requested, the Client SHOULD check the value and request re-authentication if it determines too much time has elapsed since the last user authentication.

(draft 07)

5.3. Check ID Request Verification

The Authorization Server MUST check that the access_token is present in the request and if it is signed, it MUST verify the signature according to Section 5 of JWS [JWS].

If the JWS algorithm is symmetric, such as the default HS256 for id_token, the client_secret for the client_id contained in the aud (audience) Claim MUST be used to validate the signature.

The Authorization Server MUST check that the id_token provided as the access_token contains all REQUIRED Claims.

(draft 07)

5.4. Check ID Response Verification

If the Client does not directly verify the ID Token signature, it MUST make a request to the Check ID Endpoint to validate the ID Token.

Note

  1. OP server
  2. client_id = aud = RP = Client
  3. iss = OP
  4. exp
  5. nonce
  6. acr
  7. auth_time
  8. response error
  9. issuer identifier

To verify the validity of the Token response, the Client MUST do the following:

  1. Check that the OP that responded was really the intended OP [1].
  2. The Client MUST validate that the client_id in the aud (audience) Claim is one it has registered for the Issuer identified by the value in the iss (issuer) Claim. [2] The ID Token MUST be rejected if the value of aud (audience) is not valid for the Issuer.
  3. The value of the iss (issuer) Claim must match the Issuer for the Check ID Endpoint

4 The current time MUST be less than the value of the exp Claim.

  1. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authorization Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is client specific.
  2. If the acr Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of acr Claim Values is out of scope for this specification.
  3. If the auth_time Claim was requested, the Client SHOULD check the value and request re-authentication if it determines too much time has elapsed since the last user authentication.
  4. The Check ID Endpoint has not returned an error for the ID Token being expired or invalid.
  5. Check that the iss (issuer) is equal to that of the pre-configured or discovered Issuer Identifier for the user session.
[1]RP(Client) is the subject of this sentense.
[2]iss = Issuer = OP. aud = Audience = RP = Client

(draft 07)

5.5. UserInfo Response Verification

To verify the validity of the UserInfo response, the Client MUST do the following:

  1. If the Client has provided a userinfo_encrypted_response_algs parameter during Registration, decrypt the id_token [JWE], using the key pair specified during Registration.
  2. If the response was signed, the Client SHOULD validate the signature according to Section 5 of JWS [JWS].
  3. Check that the OP that responded was really the intended OP through a TLS/SSL server certificate check, per RFC 6125 [RFC6125].

( draft 07 )

5.6. Access Token Verification

To verify the validity of an Access Token issued with an ID Token in the implicit flow, the client SHOULD do the following:

Hash the access_token with the SHA hash algorithm of the same length as the hash used in the alg paramater of the JWS header of the ID Token.

Take the left-most half of the hash and base64url encode it. The value of at_hash in the ID Token MUST match the value produced in step 3 above if at_hash is present in the ID Token.

(Draft 09) ( http://openid.bitbucket.org/openid-connect-messages-1_0.html#access.token.verification )

5.7. Code Verification

To verify the validity of a code issued with an ID Token in the implicit flow, the client SHOULD do the following:

Hash the code with the SHA hash algorithm of the same length as the hash used in the alg paramater of the JWS header of the ID Token.

Take the left-most half of the hash and base64url encode it. The value of c_hash in the ID Token MUST match the value produced in step 3 above if c_hash is present in the ID Token.

(Draft 09) ( http://openid.bitbucket.org/openid-connect-messages-1_0.html#code.verification )

6. String Operations

Processing some OpenID Connect messages requires comparing values in the messages to known values. For example, the Claim Names returned by the UserInfo Endpoint might be compared to specific Claim Names such as user_id. Comparing Unicode strings, however, has significant security implications.

Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below:

  1. Remove any JSON applied escaping to produce an array of Unicode code points.
  2. Unicode Normalization [USA15] MUST NOT be applied at any point to either the JSON string or to the string it is to be compared against.
  3. Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison.

In several places, this specification uses space delimited lists of strings. In all such cases, only the ASCII space character (0x20) MAY be used for this purpose.

( draft 07 )

8. Security Considerations

OAuth 2.0 Threat Model and Security Considerations [OAuth.Threat] provides an extensive list of threats and controls that applies to this standard as well. In addition, this standard provides additional control measures listed below.

(draft 07)

8.1. Assertion Manufacture/Modification

To mitigate this attack, there are two ways to mitigate it.

  • The assertion may be digitally signed by the OP. The Relying Party SHOULD check the digital signature to verify that it was issued by a legitimate OP.
  • The assertion may be sent over a protected channel such as TLS/SSL. In order to protect the integrity of assertions from malicious attack, the OP MUST be authenticated. In this specification, the assertion is always sent over TLS/SSL protected channel.

8.2. Assertion Disclosure

The Assertion disclosure can be mitigated in the following two ways.

  • Assertion is sent over TLS/SSL protected channel, where RP is authenticated by “client_id” and “client_secret”.
  • Signed Assertion is encrypted by the RP’s public key.

8.3. Assertion Repudiation

To mitigate this threat, the assertion may be digitally signed by the OP using a key that supports non-repudiation. The RP SHOULD check the digital signature to verify that it was issued by a legitimate OP.

8.4. Assertion Redirect

To mitigate this threat, the assertion includes the identity of the RP for whom it was generated as “client_id”. The RP verifies that incoming assertions include its identity as the recipient of the assertion.

8.5. Assertion Reuse

The assertion includes a timestamp and a short lifetime of validity. The Relying Party checks the timestamp and lifetime values to ensure that the assertion is currently valid.

8.6. Secondary Authenticator Manufacture

Due to the large entropy requirement of the Artifact (“code”) and short life nature of its validity, the success probability of this attack is extremely low.

8.7. Secondary Authenticator Capture

Secondary authenticator (=”code”) is transmitted only through HTTPS, thus it is protected between the OP and the User-Agent, and User-Agent and the RP.

Only the place it can be captured is the User-Agent where the TLS session is terminated, and is possible if the User-Agent is infested by malwares. However, it renders no usefulness as long as the profile in use either RP authentication or assertion encryption.

8.8. Assertion Substitution

Responses to assertion requests is bound to the corresponding requests by message order in HTTP, as both assertions and requests are protected by TLS that can detect and disallow malicious reordering of packets.

8.9. Authentication Request Disclosure

If the authentication request is POSTed directly through a protected channel, it is not possible to disclose the authentication request.

If the Request File is encrypted by the OP’s public key, the authentication request will not be disclosed unless OP’s private key gets compromised or the encryption algorithm becomes vulnerable.

8.10. Timing Attack

Timing attacks [3] can be used to reduce the effective key length of the signature if the time required to return the response in case of a signature error and a correct signature differs. Care should be taken in the implementation to avoid this attack.

[3]http://en.wikipedia.org/wiki/Timing_attack

8.11. Authentication Process Threats

In the category of Authentication Process Threats, following threats exists.

Authentication process per se as described in NIST SP800-63-rev1 is out of scope for this protocol, but care SHOULD be taken to achieve appropriate protection.

8.13. Signing and Encryption order

Signatures over encrypted text are not considered valid in many jurisdictions. For the integrity of non-repudiation this specification requires signing of the plain text JSON.

It is however strongly RECOMMENDED that the selected Encryption algorithm include integrity to protect against padding oracle and other decryption attacks.

Implementation should consult the security consideration around the JWE [JWE] to avoid the vulnerability around these specifications.

(draft 07)

8.14. Issuer Identifier

OpenID Connect supports a single issuer per Host and Port combination.

It is RECOMMENDED that only a single issuer per host be used. Simple Web Discovery treats the path component of any URI as part of the user identifier.

(draft 07)

8.15. TLS Requirements

Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] is the most widely deployed version, and will give the broadest interoperability.

To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

(draft 07)

9. Privacy Considerations

The UserInfo response typically contains Personally Identifiable Information. As such, End-User consent for the release of the information for the specified purpose SHOULD be obtained at or prior to the authorization time in accordance with relevant regulations. The purpose of use is typically registered in association with the redirect_uris.

Only necessary UserInfo data should be stored at the Client and the Client SHOULD associate the received data with the purpose of use statement.

The Resource Server SHOULD make the UserInfo access log available to the End-User so that the End-User can monitor who accessed his data.

To protect the End-User from a possible correlation among Clients, the use of a Pairwise Pseudonymous Identifier (PPID) as the user_id SHOULD be considered.

(draft 07)

9.1. Refresh Token, and Access Token Lifetime

Access Token grants are not revocable by the Authorization Server. Access Token grant lifetimes SHOULD be kept to single use or very short lifetimes.

If access to the User Info Endpoint or other protected resources is required, a Refresh Token should be used. The Client may then exchange the Refresh Token at the Token Endpoint for a fresh short lived Access Token, that can be used to access the resource.

Note

If the Client accesses the User Info Endpoint or other portected resource sometime later after the grant lifetime is over, .....

The Authorization Server SHOULD clearly identify long term grants to the User during Authorization. [4]

[4]Difficult to grasp.

The Authorization Server MUST provide a mechanisim for the user to revoke Refresh Tokens granted to a client.

(draft 07)

10. IANA Considerations

This document makes no requests of IANA.

(draft 07)

11. References

(draft 07)

11.1. Normative References

E.164
International Telecommunication Union, “E.164 : The international public telecommunication numbering plan,” 2010.
ISO29115
McCallister, E., “ITU-T Recommendation X.1254 | ISO/IEC DIS 29115 – Information technology - Security techniques - Entity authentication assurance framework,” ISO/IEC 29115, November 2011.
ISO3166-1
International Organization for Standardization, “ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions – Part 1: Country codes,” 1997.
ISO639-1
International Organization for Standardization, “ISO 639-1:2002. Codes for the representation of names of languages – Part 1: Alpha-2 code,” 2002.
JWE
Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.
JWK
Jones, M., “JSON Web Key (JWK),” December 2011.
JWS
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature,” December 2011.
JWT
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” December 2011.
LoA.Registry
Johansson, L., “An IANA registry for SAML 2.0 Level of Assurance Context Classes,” June 2011.
OAuth.Assertions
Mortimore, C., Ed., Campbell, B., Jones, M., and Y. Goland, “OAuth 2.0 Assertion Profile,” October 2011.
OAuth.Bearer
Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” December 2011.
OAuth.JWT
Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” December 2011.
OAuth.Responses
de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” December 2011.
OAuth.Threat
Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” October 2011.
OAuth2.0
Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.
OpenID.Basic
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Basic Client 1.0,” December 2011.
OpenID.Discovery
Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” December 2011.
OpenID.Registration
Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2011.
OpenID.Session
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” December 2011.
OpenID.Standard
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” December 2011.
RFC2119
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
RFC2246
Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT).
RFC3339
Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
RFC4627
Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
RFC5246
Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
RFC5646
Phillips, A. and M. Davis, “Tags for Identifying Languages,” BCP 47, RFC 5646, September 2009 (TXT).
RFC6125
Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” RFC 6125, March 2011 (TXT).
USA15
Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.
zoneinfo
Public Domain, “The tz database,” June 2011.

( draft 07 )

11.2. Informative References

OpenID.2.0
specs@openid.net, “OpenID Authentication 2.0,” 2007 (TXT, HTML).
RESPONSE.TYPES
de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” October 2011.

(draft 07)

My Note

Note

  • Simplified version of Aggregated and Distributed Claim

2.5.2. Aggregated and Distributed Claims

Aggregated and distributed Claims are represented by a JSON object including folowing claims:

_source

For Aggregated claim, this value is JWT string to contain the name of the claim.

For Distributed clamin, this value is URL of the endpoint to get JSON.

Otherwise, value is a key in “_sources” mapper in JSON.

_access_token
REQUIRED if this claim is distributed.

And at the same JSON node level, a mapper can be used to define Aggreated and Distributed Claims:

_sources
Disctionay JSON object. Keys MUST be unique for other A & D Claims to index. Values are concrete A & D Claims.

The following is a non-normative response:

{
    ....
    "address"        : { "_source": "jwt_header.jwt_2nd.jwt_3rd" },
    "pension_number" : { "_source": "http://japan.inc/pension/number", "_access_token" :  "ksj3n283dke"},
    ....
}

If a single source holds multiple claims, a dictinaly “_sources” can hold this JSON objects:

{
    ....
    "address":       : { "_source": "mybank" },
    "bank_account"   : { "_source": "mybank" },
    "pension_number" : { "_source": "mypension"},
    "pension_office" : { "_source": "mypension"},
    ....

    "_sources" : {
      "mybank" : { "_source": "jwt_header.jwt_2nd.jwt_3rd" },
      "mypension" : { "_source": "http://japan.inc/pension/number", "_access_token" :  "ksj3n283dke"}
    }
}

Where a aggregated JWT, contains the following JSON:

{
    "address" : {
        "country" : "Japan",
        "postal_code : "1500053",
        "region" : "Tokyo",
        .....
    },
    "bank_account" :  "0000-1111-2222"
}

and the distributed endpoint returns the following JSON:

{
    "pension_number" : "1432143",
    "pension_office" : "Shibuya,Tokyo"
}

«  OpenID Connect Standard 1.0   ::   Contents   ::   OpenID Connect Dynamic Client Registration 1.0  »