identity 1.0 documentation

OpenID Connect Standard 1.0

«  OpenID Connect Implicit Client Profile 1.0   ::   Contents   ::   OpenID Connect Messages 1.0  »

OpenID Connect Standard 1.0

Connect Standard

Based on OpenID Connect Standard 1.0 - draft 13 ( August 13, 2012 )

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 [1] and RESTful manner.

OpenID Connect Standard 1.0 is an HTTP protocol binding for OpenID Connect Messages 1.0 request and response messages.

[1]How interoperable ?

(draft 07, 2011-12-22)

1. Introduction

This specification describes the binding of the HTTP protocol with the endpoints described in OpenID Connect Messages [OpenID.Messages].

(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 [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.

(draft 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”, and “Token Endpoint” defined by OAuth 2.0 [OAuth2.0], and the terms defined by OpenID Connect Messages 1.0 [OpenID.Messages]. This specification also defines the following terms:

Request File
A document whose contents is a JWT representing a set of Authorization Request parameters.
Request File URI
A URL that references a Request File. The Request File contents MUST be retrievable by the Authorization Server.

(draft 07, 2011-12-22)

2. Authorization Endpoint

The Authorization Endpoint performs authentication services for the End-User and requests authorization from the End-User to release information to OpenID Connect Relying Party Clients. When an End-User accesses a Relying Party Client application which requires the End-User‘s identifier and other information, it sends the End-User to the Authorization Server‘s Authorization Endpoint for authentication and authorization. The Authorization Server then issues an ID Token which asserts the End-User‘s identifier and an Access Token which allows the Client to access the End-User‘s information at Protected Resource endpoints. Protected Resource endpoints MAY perform different actions or return different information based on the scopes associated with the presented Access Token. Clients MUST specify how the Access Token and ID Token are to be returned using the response_type parameter in the Authorization Request.

(draft 07)

2.1. OpenID Connect Scopes

Clients MUST specify the desired scopes in an authorization request to obtain an Access Token with the proper permissions.

Scopes names defined for OpenID Connect are in Section 2.1.2 of OpenID Connect Messages 1.0 [OpenID.Messages]. OAuth 2.0 allows additional scopes to be specified as extensions.

OpenID Connect’s scope use is consistent with Section 3.3 of OAuth 2.0 [OAuth2.0].

The Authorization Server MAY fully or partially ignore the scope requested by the Client based on the Authorization Server policy [2] or the End-User‘s instructions [3].

To increase new account activation, 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 [4] .

scope=openid profile email phone
[2]Policy sample ?
[3]Instruction at authetication and conscent process ?
[4]“Scope Request” ?

(draft 07)

2.2. Protocol Flows

Authorization Requests follow two main paths to obtain Access Tokens and ID Tokens, the Implicit Flow and the Authorization Code Flow. The flows determine how the Access Token and ID Token are returned to the Client. Access Tokens are credentials used to access Protected Resources, as defined in section 1.4 of OAuth 2.0 [OAuth2.0]. Access Tokens represent a Resource Owner‘s authorization and MUST NOT be exposed to unauthorized parties.

The Implicit Flow is mainly used by Clients implemented in a browser using a scripting language. The Access Token and ID Token are returned directly to the Client, which MAY expose them to the Resource Owner and other applications which have access to the Resource Owner‘s User-Agent. The Authorization Server does not perform Client authentication before issuing the Access Token.

The Authorization Code Flow returns an Authorization Code to the Client, which can then exchange it for an Access Token directly. This provides the added benefit of not exposing the Access Token to the Resource Owner and possibly other malicious applications with access to the Resource Owner‘s User-Agent. The Authorization Server can also authenticate the Client before [5] exchanging the Authorization Code for an Access Token. The Authorization Code flow is suitable for Clients that can securely maintain a Client Secret between themselves and the Authorization Server whereas the Implicit flow is suitable for Clients that cannot.

[5]“at the time when” ?

(draft 07)

2.2.1. How to Get an Authorization Code, Access Token, and ID Token

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 flows [RESPONSE.TYPES] 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.

Note

See response_types_supported in discovery.3.1

The Authorization Server MUST support both the code and the ‘id_token tokenresponse_type.

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

(draft 08, http://openid.bitbucket.org/openid-connect-standard-1_0.html#retrieving_code_token)

2.2.2. Authorization Code Flow

The Authorization Code Flow goes through the following steps.

  1. Client prepares an Authorization Request containing the desired request parameters.
  2. Client sends a request to the Authorization Server.
  3. Authorization Server Authenticates the End-User.
  4. Authorization Server Obtains the End-User Consent/Authorization.
  5. Authorization Server Sends the End-User back to the Client with an Authorization Code.
  6. Client requests a response using the Authorization Code at the Token Endpoint.
  7. Client receives a response which contains an Access Token and ID Token in the response body.
  8. (OPTIONAL) Client validates the ID Token at the Check ID Endpoint.
  9. (OPTIONAL) Client receives ID Token Response with the End-User‘s identifier.
  10. (OPTIONAL) Client accesses the UserInfo Endpoint with the Access Token.
  11. (OPTIONAL) Client receives UserInfo Response.

Note that in each step, the party that receives a message MUST verify it according to the verification rule set in OpenID Connect Messages 1.0 [OpenID.Messages].

(draft 07)

2.2.3. Implicit Flow

The implicit flow follows the following steps:

  1. Client prepares an Authorization Request containing the desired request parameters.
  2. Client sends a request to the Authorization Server.
  3. Authorization Server Authenticates the End-User.
  4. Authorization Server Obtains the End-User Consent/Authorization.
  5. Authorization Server Sends the End-User back to the Client with an Access Token and an ID Token if requested.
  6. (OPTIONAL) Client validates the ID Token at the Check ID Endpoint.
  7. (OPTIONAL) Client receives ID Token Response with the End-User‘s identifier.
  8. (OPTIONAL) Client accesses the UserInfo Endpoint with the Access Token.
  9. (OPTIONAL) Client receives UserInfo Response.

Note that in each step, the party that receives a message MUST verify it according to the verification rule set in OpenID Connect Messages 1.0 [OpenID.Messages].

(draft 07)

2.3. Authorization Request

When the End-User wishes to access a Protected Resource, and the End-User Authorization has not yet been obtained, the Client prepares an Authorization Request to the Authorization Endpoint.

Authorization Servers MUST require the use of a transport-layer security mechanism at the Authorization Endpoint. The Authorization Server MUST support TLS 1.2 as described in RFC 5246 [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support other transport-layer mechanisms with equivalent security.

Note

TLS
  • 1.2
  • 1.0

Authorization Servers MUST support the use of the HTTP “GET” and “POST” methods defined in RFC 2616 [RFC2616] at the Authorization Endpoint.

Clients MAY use the HTTP “GET” or “POST” method to send the Authorization Request to the Authorization Server. If using the HTTP “GET” method, the request parameters are serialized using URI query string serialization. If using the HTTP “POST” method, the request parameters are serialized using form serialization.

Note

Request Parameter Serialization

  • GET : Query String
  • POST : Form

(draft 10)

Note

An anonymous session may be provided to an user agent, and bind the Authorization Request to it. Session key MUST be unique to every each use agent, and not be hijaked by others as an web application.

2.3.1. Client Prepares an Authorization Request

The Client prepares an Authorization Request to the Authorization Endpoint with the request parameters using the HTTP “GET” or “POST” method. The scheme used in the Authorization URL MUST be HTTPS. The Client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125].

Note

Check the OP X.509 certificate when an Authorization Request is being provided at a Client.

The required Authorization Request parameters are as follows:

response_type

An OAuth 2.0 registered response type that determines how the Authorization Response is returned to the Client. As described in How to Get an Authorization Code, Access Token, and ID Token (2.2.1), the following registered values are supported:

  • code
  • code id_token
  • id_token
  • token
  • token id_token
  • code token
  • code token id_token
client_id
The client identifier.
scope
It MUST include openid as one of the space delimited ASCII strings. Other values that MAY be included are profile, and email, address. The values specify an additive list of Claims that are returned by the UserInfo Endpoint as described by OpenID Connect Scopes (2.1) <standard_2_1>`.
redirect_uri
A redirection URI where the response will be sent. The Scheme, Host, and Path segments of this URI MUST match one of the redirect_uris registered for the client_id in the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specification.
nonce
A string value used to associate a browser session with a id_token, and to mitigate replay attacks. The value is passed through unmodified to the ID Token. One method is to store a random value as a signed session cookie, and pass the value in the nonce paramater. The nonce in the returned id_token is compared to the signed session cookie to detect id_token replay by third parties.

The request can contain the following OPTIONAL parameters:

state
An opaque value used to maintain state between the request and the callback.
request
A JWT [JWT] encoded OpenID Request Object.
request_uri
A URL that points to an OpenID Request Object.
display
An ASCII string value that specifies how the Authorization Server displays the authentication page to the End-User. Refer to Sec 2.1.2 of OpenID Connect Messages 1.0 [OpenID.Messages] for more information.
prompt
A space delimited list of ASCII strings that can contain the values login, consent, select_account, and none. Refer to OpenID Connect Messages 1.0 [OpenID.Messages] for more information.

There are three methods to construct and send the request to the Authorization Endpoint:

  1. Simple Request Method
  2. Request Parameter Method
  3. Request File Method

The Simple Request Method is used in simple cases when default UserInfo and ID Token Claims are desired.

The Request Parameter Method is used by sending an OpenID Request Object when the Client desires to retrieve a different set of UserInfo and ID Token Claims. The request parameter method also allows requests to be signed or encrypted.

The Request File Method works similar to the Request Parameter Method but differs in that it sends an URL as a reference to the OpenID Request Object. It enables large requests to be sent securely and compactly even on browsers with limited capabilities. Clients SHOULD use the Request File Method to minimize the request size.

(draft 07)

2.3.1.1. Simple Request Method

The Client prepares an Authorization Request to the Authorization Endpoint using the appropriate parameters. If using the HTTP “GET” method, the request parameters are serialized using URI query string serialization. If using the HTTP “POST” method, the request parameters are serialized using form serialization.

The following is a non-normative example of an Authorization Request URL. Note that the line wraps within the values are for display purpose only:

https://server.example.com/op/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj

(draft 07)

2.3.1.2. Request Parameter Method

The Client prepares an Authorization Request to the Authorization Endpoint using the appropriate HTTP parameters serialization. The Client SHOULD construct the request using the HTTP “POST” method, but MAY use the HTTP “GET” method.

The Authorization Request MUST include the request parameter defined in the Client Prepares an Authorization Request section (2.3.1). The Authorization Request MUST NOT include the request_uri parameter.

The request parameter is a JWT [JWT] encoded OpenID Request Object which contains the Authorization Request and also specifies the content of the responses returned from the UserInfo and Check ID Endpoints. The JWT object MAY be signed or signed and encrypted via JWS [JWS] and JWE [JWE] respectively, thereby providing authentication, integrity, non-repudiation and/or confidentiality.

All Authorization Request parameters that are part of the Authorization Request excluding the request, request_uri, , redirect_uri, state, , client_id and nonce parameters MUST also be JSON Serialized into the OpenID Request Object with the same values. This allows the Client to send signed and/or encrypted requests to the Authorization Server and maintain conformance to OAuth 2.0.

The client_id , redirect_uri, state, , and nonce parameters MAY also be included in the OpenID Request Object.

The following is a non-normative example of an OpenID Request Object before JWT encoding. Note that the line wraps within the values are for display purpose only:

{
 "response_type": "code%20id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.com/cb",
 "scope": "openid profile",
 "state": "af0ifjsldkj",
 "nonce": "n-0S6_WzA2Mj",
 "userinfo":
   {
     "claims":
       {
         "name": null,
         "nickname": {"optional": true},
         "email": null,
         "verified": null,
         "picture": {"optional": true}
       }
   },
 "id_token":
   {
     "max_age": 86400,
     "iso29115": "2"
   }
}

The following is a non-normative example of a JWT [JWT] encoded OpenID Request Object. Note that the line wraps within the values are for display purpose only:

JWT algorithm = HS256
HMAC HASH Key = 'aaa'

JSON Encoded Header = "{"alg":"HS256","typ":"JWT"}"
JSON Encoded Payload = "{"response_type":"code id_token",
    "client_id":"s6BhdRkqt3",
    "redirect_uri":"https://client.example.com/cb",
    "scope":"openid profile",
    "state":"af0ifjsldkj",
    "nonce":"n-0S6_WzA2Mj",
    "userinfo":{"claims":{"name":null,"nickname":{"optional":true},
        "email":null,"verified":null,
        "picture":{"optional":true}}},
    "id_token":{"max_age":86400,"iso29115":"2"}}"

JWT = eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZ
    SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO
    iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI
    HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zI
    jp7Im5hbWUiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiO
    m51bGwsInZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sI
    mZvcm1hdCI6InNpZ25lZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvM
    jkxMTUiOiIyIn19.2OiqRgrbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY

The following is a non-normative example of an Authorization Request with the OpenID Request Method. Note that the line wraps within the values are for display purpose only:

https://server.example.com/authorize?
response_type=code%02id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY2
9kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi
JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2
ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zIjp7Im5hbW
UiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiOm51bGwsInZlcm
lmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ2
5lZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqR
grbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY

(draft 07)

2.3.1.2.1. Client Sends a Request to the Authorization Server

Having constructed the Authorization Request, the Client sends it to the HTTPS Authorization Endpoint. This MAY happen via HTTPS redirect, hyperlinking, or any other means of directing the User-Agent to the Authorization Endpoint.

Following is a non-normative example using HTTP redirect. Note: Line wraps are for display purpose only.

HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY2
9kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi
JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2
ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zIjp7Im5hbW
UiOm51bGwsIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiOm51bGwsInZlcm
lmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ2
5lZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqR
grbrHkA1FZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY

(draft 07)

2.3.1.3. Request File Method

The Request File Method differs from the other methods in that it uses a Request File that contains a OpenID Request Object. It then sends the Request File URL as part of the Authorization Request.

The Client prepares an Authorization Request using the desired HTTP “GET” or “POST” method. The Client SHOULD use the HTTP “GET” method, but MAY use the HTTP “POST” method. The scheme used in the Authorization URL MUST be HTTPS. The Client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125].

The Authorization Request MUST NOT include the request parameter. The Authorization Request MUST include the request_uri parameter. The target of the URL is a JWT which is a OpenID Request Object. The scheme used in the request_uri value MUST be HTTPS, unless the target JWT is signed in a way that is verifiable by the Authorization server. The request_uri value MUST be reachable by the Authorization Server, and SHOULD be reachable by the Client.

All Authorization Request parameters that are part of the Authorization Request excluding the request parameter MUST also be JSON Serialized into the OpenID Request Object with the same values. This allows the Client to send signed and/or encrypted requests to the Authorization Server and maintain conformance to OAuth 2.0. The OpenID Request Object MAY be signed and encrypted via JWS [JWS] and JWE [JWE] respectively, thereby providing authentication, integrity, non-repudiation and/or confidentiality.

Following is a non-normative example of a Request File. Note that the line wraps within the values are for display purpose only:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF9
0b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczp
cL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJ
zdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaW1zIjp7Im5hbWUiOm51bGw
sIm5pY2tuYW1lIjp7Im9wdGlvbmFsIjp0cnVlfSwiZW1haWwiOm51bGwsInZlcmlmaWVkIjp
udWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcm1hdCI6InNpZ25lZCJ9LCJ
pZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyIn19.2OiqRgrbrHkA1F
Z5p_7bc_RSdTbH-wo_Agk-ZRpD3wY

(draft 07)

2.3.1.3.1. Client Generates the URL of the Request File

The Client then stores the Request File either locally or remotely. This is the Request URI, “request_uri”. The URI MAY be appended with the SHA256 [FIPS180-2] hash of the file after “#” so that the Authorization Server can detect whether the file has changed. “#” MUST be escaped.

It should be noted that if the Request File includes user’s attribute values, it MUST NOT be revealed to anybody but the Authorization Server. As such, the “request_uri” MUST have an appropriate entropy for its lifetime, and must be removed after successful authentication or a reasonable timeout.

The Client then records the Request File either locally or remotely and obtains the Request File URI, “request_uri”.

(draft 07)

2.3.1.3.2. Client Sends a Request to Authorization Server via HTTPS Redirect

The Client sends the Authorization Request to the Authorization Endpoint.

The entire URL MUST NOT exceed 512 bytes.

Following is a non-normative example. Note: Line wraps are for display purpose only:

HTTP/1.1 302 Found
Location: https://server.example.com/authorize
?response_type=code%20id_token
&cliend_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Frf%2Ejs
&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj&scope=openid

(draft 07)

2.3.3. Authorization Server Authenticates the End-User

The Authorization Server validates the request to ensure all required parameters are present and valid. If the request is valid, the Authorization Server MUST authenticate the End-User. The way in which the Authorization Server authenticates the End-User (e.g. username and password login, session cookies) is beyond the scope of this specification. An authentication user interface MAY be displayed by the Authorization Server depending on the authentication method used.

The Authorization Server MUST attempt to authenticate the End-User in the following cases:

The Authorization Server MUST NOT attempt authentication in the following cases:

Note

“none” ask User to have already authenticated and logged in to OP before he starts Connect activities.

(draft 07)

2.3.5. Authorization Server Sends the End-User Back to the Client

Once the authorization is determined, the Authorization Server returns a successful or error response.

(draft 07)

2.3.5.1. End-User Grants Authorization

If the Resource Owner grants the access request, the Authorization Server issues an Authorization Response and delivers it to the Client by adding the response parameters to redirect_uri specified in the Authorization Request using the “application/x-www-form-urlencoded” format.

If the response_type parameter in the Authorization Request includes the string value “code”, the following response parameters are included:

code
REQUIRED. The Authorization Code.

Upon receipt of the “code”, the Client requests a response that includes the “access_token” and other variables. [#] The requests and responses are described in the Token Endpoint (3) section.

[6]Token request ?

If the response_type parameter in the Authorization Request includes the string value “token”, the following response parameters are included:

access_token
REQUIRED. The Access Token.
token_type
REQUIRED. This specification only supports the Bearer Token [OAuth2.0Bearer] scheme. As such, this value MUST be set to “Bearer”.
expires_in
OPTIONAL. The lifetime in seconds of the Access Token.
scope
OPTIONAL. The scopes of the issued Access Token.

If the response_type parameter in the Authorization Request includes the string value “id_token”, the following response parameters are returned:

id_token
REQUIRED. The ID Token of the for the authentication session.

The response parameters MAY also be include:

state
REQUIRED if the state parameter is present in the Authorization Request. Set it to the exact value of the state parameter received from the Client.

No other parameter SHOULD be returned.

If the response_type parameter in the Authorization Request includes the string value “token” or “id_token”, all response parameters MUST be added to the fragment component of the redirection URI. Otherwise, the response parameters are added to the query component of the redirection URI.

The following are non-normative examples of requests with differing return_type values and their responses. Line wraps are for display purpose only:

https://server.example.com/op/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.com/cb?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&state=af0ifjsldkj

https://server.example.com/op/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.com/cb#
access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ
&state=af0ifjsldkj

https://server.example.com/op/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ
&state=af0ifjsldkj

https://server.example.com/op/authorize?
response_type=token%20code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&state=af0ifjsldkj

https://server.example.com/op/authorize?
response_type=token%20code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ
&state=af0ifjsldkj

(draft 07)

2.3.5.2. End-User Denies Authorization or Invalid Request

If the End-User denies the authorization or the user authentication fails, the Authorization Server MUST return the error authorization response as defined in OpenID Connect Messages 1.0 [OpenID.Messages].

The Authorization Server returns the Client to the redirection URI specified in the Authorization Request with the appropriate error parameters. No other parameters SHOULD be returned.

The error response parameters are the following:

error
REQUIRED. The error code.
error_description
OPTIONAL. A human-readable UTF-8 encoded text description of the error.
error_uri
OPTIONAL. A URI to a web page that includes additional information about the error.
state
REQUIRED if the Authorization Request included the state parameter. Set to the exact value received from the Client.

If the response_type parameter in the Authorization Request includes the string value “token” or “id_token”, all error response parameters SHOULD be added to the fragment component of the redirection URI. Otherwise, the response parameters are added to the query component of the redirection URI.

The following is a non-normative example. Line wraps after the second line is for the display purpose only:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?
error=invalid_request
&error_description=the%20request%20is%20not%20valid%20or%20malformed
&state=af0ifjsldkj

(draft 07)

3. Token Endpoint

Note

  • Client: HTML FORM POST

  • Server

    • JSON : Access Token, ID Token ...
    • Cache-Content : no-store
    • Pragma : no-cache
  • TLS direct request and response

The Token Endpoint handles requests for retrieving and refreshing Access Tokens as well as ID Token and other variables.

Clients MUST use the HTTP “POST” method to make requests to the Token Endpoint. Request parameters are added using form serialization.

Clients MAY provide authentication parameters in the request to the Token Endpoint as described in Section 2.2.1 of OpenID Connect Messages [OpenID.Messages].

Authorization Servers MUST support the use of the HTTP “POST” method defined in RFC 2616 [RFC2616] at the Token Endpoint.

Authorization Servers MUST require the use of a transport-layer security mechanism. The Authorization Server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support other transport-layer mechanisms with equivalent security.

All Token Endpoint responses that contain tokens, secrets, or other sensitive information MUST include the following HTTP response header fields and values:

HTTP Response Headers and Values
Header Name Header Value
Cache-Control no-store
Pragma no-cache

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

3.1. Requesting an Access Token

To retrieve an Access Token, a Client MUST have an Authorization Code obtained via the method as described in Authorization Code Flow (2.2.2. Authorization Code Flow>).

(draft 12)

3.1.1. Access Token Request

To obtain an Access Token, Refresh Token or ID Token, the Client MUST authenticate to the Token Endpoint using the authentication method registered for its client_id, as documented in Section 2.2.1 of OpenID Connect Messages 1.0 [OpenID.Messages] The Client sends the parameters via HTTPS POST to the Token Endpoint using form serialization as specified in Section 4.1.3 of OAuth 2.0 [OAuth2.0]:

The following is a non-normative example. Line wraps after line 4 are for display purpose only:

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

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

The Authorization Server MUST:

(draft 12)

3.1.2. Access Token Response

Upon receipt of the Token Request, the Authorization Server MUST return either a successful response or an error response that corresponds to the received Authorization Code.

A successful response returns the “application/json” media type and the response body is the Access Token Response documented in Sec 2.2.3 of OpenID Connect Messages 1.0” [OpenID.Messages].

Following is a non-normative example of a successful response:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOl
wvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIj
oiaHR0cDpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0
vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ"
}

(draft 12)

3.1.3. Access Token Error Response

If the Token Request is invalid or unauthorized, the Authorization Server constructs the response by returning the Token Error Response defined in OpenID Connect Messages [OpenID.Messages] in the entity body of the HTTP response using the application/json media type with HTTP response code 400.

Following is a non-normative example:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_request"
}

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

3.2. Refreshing an Access Token

To refresh an Access Token, the Client MUST authenticate to the Token Endpoint using the authentication method registered for its client_id, as documented in Section 2.2.1 of OpenID Connect Messages 1.0 [OpenID.Messages] The Client sends the parameters via HTTPS POST to the Token Endpoint using form serialization as specified in Section 6 of OAuth 2.0 [OAuth2.0]:

The Authorization Server MUST verify the validity of the Refresh Token.

(draft 07)

3.2.1. Refresh Token Response

Upon receipt of the Refresh Token Request, the Authorization Server MUST return either a successful response or an error response that corresponds to the received Refresh Token.

Upon successful verification of the Refresh Token, a successful response returns the “application/json” media type and the response body is the Access Token Response of Section 2.2.3 of OpenID Connect Messages 1.0 [OpenID.Messages].

Following is a non-normative example of the Refresh Token request and response:

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

client_id=s6BhdRkqt3
&client_secret=some_secret12345
&grant_type=refresh_token
&refresh_token=8xLOxBtZp8
&scope=openid profile


HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "access_token": "TlBN45jURg",
 "token_type": "Bearer",
 "refresh_token": "9yNOxJtZa5",
 "expires_in": 3600,
 "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOl
wvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIj
oiaHR0cDpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0
vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ"
}

(draft 07)

3.2.2. Refresh Token Error Response

If the Refresh Token Request is invalid or unauthorized, the Authorization Server returns the Token Error Response as defined in Section 5.2 of OAuth 2.0 [OAuth2.0].

(draft 07)

4. Check ID Endpoint

The Check ID Endpoint validates the ID Token and returns a text JSON [RFC4627] object containing the Claims in the ID Token. [6] This endpoint is used by Clients that are not able to or do not wish to directly process ID Tokens. In this case, clients MAY treat ID Tokens as opaque values.

Check ID Endpoints MUST require the use of a transport-layer security mechanism. The endpoint MUST support TLS 1.2 as described in RFC 5246 [RFC5246]; when TLS is used, the Client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. Check ID Endpoints MAY support other transport-layer mechanisms with equivalent security.

[7]Should refer to Messages spec ?

(draft 07)

4.1. Check ID Request

To request the information about the authentication performed on the End-User, a request is made to the Check ID Endpoint sending the ID Token as the access_token by using the OAuth 2.0 Bearer [OAuth.Bearer] scheme. [7]

[8]Authorization Scheme.

Clients MAY send requests with the following parameter to the Check ID Endpoint:

access_token
REQUIRED. The ID 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].

The Following is a non-normative example of a Check ID request:

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

access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZX
J2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0cD
pcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1G
3liaTNOrfaeWYjuRCEPNXVtaazNQ

The Client MUST ensure that the Check ID Endpoint being used is the trusted Check ID Endpoint for the Entity via pre-configuration meta-data or discovery.

A request to the Check ID Endpoint MAY alternatively be made with the HTTP “GET” method, when using GET the access_token MUST be passed in the header.

(draft 07)

4.2. Check ID Response

The Check ID Endpoint MUST return the JSON serialized Claims associated with the ID Token as described in Check ID Response section of OpenID Messages [OpenID.Messages] in the HTTP response body. The content-type of the HTTP response MUST be set to application/json.

The following is a non-normative example of a response from a Check ID Endpoint:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "iss": "http://server.example.com",
 "user_id": "248289761001",
 "aud": "s6BhdRkqt3",
 "nonce": "n-0S6_WzA2Mj",
 "exp": 1311281970
}

(draft 07)

4.2.1. Response Verification

To verify the validity of the Response, the Client MUST do the following:

(draft 07)

4.3. Check ID Error Response

When an error condition occurs, the Check ID Endpoint returns an Error Response as defined in Section 3 of OAuth 2.0 Bearer Tokens [OAuth.Bearer] utilizing an error code as specified in Section 2.3.3 of OpenID Connect Messages 1.0 [OpenID.Messages].

Following is a non-normative example of an error response:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example.com",
                     error="invalid_id_token",
                     error_description="The ID token expired"

(draft 07)

5. UserInfo Endpoint

To obtain the requested Claims about the End-User, the Client makes a GET or POST request to the UserInfo Endpoint as in OpenID Connect Messages 1.0 [OpenID.Messages].

Authorization Servers MUST require the use of a transport-layer security mechanism. The Authorization Server MUST support TLS 1.2 as described in RFC 5246 [RFC5246] and MAY support other transport-layer mechanisms with equivalent security.

Authorization Servers MUST support the use of the HTTP “GET” and HTTP “POST” methods defined in RFC 2616 [RFC2616] at the UserInfo Endpoint.

Authorization Servers MUST be able to accept Access Tokens via Bearer Tokens [OAuth.Bearer] specification.

Authorization Servers SHOULD support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint.

(draft 08)

Note

CORS supports was added on Draft 08 ( https://bitbucket.org/openid/connect/issue/550 )

Note

Thinking of the indirect binding for OP in intranet. Seems to be OpenID 2.0 AX with JWT.

5.1. UserInfo Request

Client SHOULD send the UserInfo Request defined in section 2.4.1 of the OpenID Connect Messages 1.0 [OpenID.Messages] either in HTTP GET or POST request [#].

[9]Section 2.4.1 ? ( 2.4.1. UserInfo Request )

The Access Token obtained from an OpenID Connect Authorization Request MUST be sent as a Bearer Token [OAuth.Bearer]

Section 2 of the OAuth 2.0 Bearer Token [OAuth.Bearer] specification documents the permissible methods of sending the Access Token.

It is RECOMMENDED that the Client use the authorization header method for all requests using GET.

The following is a non-normative example. Line wraps are for display purpose only:

GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ ... fQ.8Gj_    sj ... _X

(Draft 08)

Note

Indirect binding will return HTML form with Javascript which automaticall POST the form to RP’s specifeid endpoint. So the endpoint expectes “return_to” query paramter or HTTP post parameter. Of source, a switch is required for OP to process indirect binding.

5.2. UserInfo Response

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.

Upon receipt of the UserInfo request, the UserInfo Endpoint MUST return the JSON Serialization of the UserInfo response as in OpenID Messages [OpenID.Messages] in the HTTP response body. The content-type of the HTTP response MUST be set to application/json if the response body is a text JSON structure. If the JSON response is JWS [JWS] signed or JWE [JWE] encrypted, then the content-type MUST be set to application/jwt.

Upon receipt of the UserInfo Response, the Client MUST verify the response in accordance with Section 5.5 (UserInfo Response Verification) of OpenID Connect Messages 1.0 [OpenID.Messages].

Following is a non-normative example of such response:

HTTP/1.1 200 OK
Content-Type: application/json

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

(draft 08)

Note

Indirect binding return a HTML form inlucde the JWT as a paramter.

5.3. UserInfo Error Response

When an error condition occurs, the UserInfo Endpoint returns an Error Response as defined in Section 3 of OAuth 2.0 Bearer Tokens [OAuth.Bearer] utilizing an error code as specified in Section 2.4.3 of OpenID Connect Messages 1.0 [OpenID.Messages].

Following is a non-normative example of an error response:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example.com",
                     error="invalid_token",
                     error_description="The access token expired"

(draft 07)

6. Discovery and Registration

Some OpenID Connect installations can use a pre-configured set of OpenID Providers and/or Relying Parties. In those cases, it may not be necessary to support dynamic discovery of information about identities or services or dynamic registration of Clients.

However, if installations choose to support unanticipated interactions between Relying Parties and OpenID Providers that do not have pre-configured relationships, they SHOULD accomplish this by implementing the facilities defined in the OpenID Connect Discovery 1.0 [OpenID.Discovery] and OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specifications.

(draft 07)

6.1. UserInfo Request

Client SHOULD send the UserInfo request defined in section 3.3 of the OpenID Connect Messages 1.0 [OpenID.Messages] either in HTTP GET or POST request.

The request parameters are the following:

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 [OAuth.2.0]. Access tokens sent in the authorization header must be Bearer tokens [OAuth.2.0.Bearer]. If the client is using the HTTP GET method, it SHOULD send the access token in the authorization header.
schema
OPTIONAL. The schema in which the data is to be returned. The only predefined value is openid. If this parameter is not included, the response may be a proprietary schema to support backwards compatibility. A URL MAY be passed to define custom schemes not specified by short names. Custom scheme names and responses are out of scope for this specification.
id
This identifier is reserved for backwards compatibility. It MUST be ignored by the endpoint if the openid schema is used.

The following is a non-normative example. Line wraps are for display purpose only:

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

access_token=SlAV32hkKG

6.2. UserInfo Response

Upon receipt of the UserInfo request, the UserInfo endpoint MUST return the JSON Serialization of the UserInfo response as in OpenID Messages [OpenID.Messages] in the HTTP response body. The content-type of the HTTP response MUST be set to application/json if the response body is a text JSON structure. If the JSON response is JWS [JWS] signed or JWE [JWE] encrypted, then the content-type MUST be set to application/jwt.

Following is a non-normative example of such response:

HTTP/1.1 200 OK
Content-Type: application/json

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

6.2.1. UserInfo Error Response

When some error condition arises, the UserInfo endpoint returns the JSON serialized Error Response defined in section 3.3.3 of OpenID Connect Messages 1.0 [OpenID.Messages] in the entity body of the HTTP response using the application/json media type with HTTP response code 400.

Following is a non-normative example of an error response:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error":"invalid_request"
}

7. Serializations

A request message MAY be serialized using one of the following methods:

  1. Query String Serialization
  2. Form Serialization

(draft 07)

7.1. Query String Serialization

In order to serialize the parameters using the query string serialization, the Client constructs the string by adding the parameters and values to the query component of a URL using the application/x-www-form-urlencoded format as defined by [W3C.REC‑html401‑19991224]. Query string serialization is typically used in HTTP GET requests.

Following is a non-normative example of such serialization:

GET /authorize?scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

(draft 07)

7.2. Form Serialization

Parameters and their values are form serialized by adding the parameter names and values to the entity body of the HTTP request using the application/x-www-form-urlencoded format as defined by [W3C.REC‑html401‑19991224]. Form serialization is typically used in HTTP POST requests.

Following is a non-normative example of such serialization:

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

scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

(draft 07)

8. Security Considerations

This specification references the security considerations defined in OpenID Connect Messages 1.0 [OpenID.Messages].

In addition, the following list of attack vectors and remedies are also considered.

(draft 07)

8.1. Implicit Grant Flow Threats

In the implicit grant flow, the Access Token is returned in the fragment part of the Client‘s redirect_uri through HTTPS, thus it is protected between the OP and the User-Agent, and User-Agent and the RP. The 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 malware.

Note

ARP Spoofing can read the SSL packet.

(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_uri.

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)

10. IANA Considerations

(draft 07)

10.1. OAuth Parameters Registry

(draft 07)

10.1.1. Scope Parameters

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

(draft 07)

10.1.2. Authorization Request Parameter (display)

The following is the parameter registration request for the Authorization Request in this specification:

  • Parameter name: display
  • Parameter usage location: Authorization Request
  • Change controller: IETF
  • Specification document(s): [[ this document ]]
  • Related information: None

(draft 07)

10.1.3. Authorization Request Parameter (prompt)

The following is the parameter registration request for the Authorization Request in this specification:

  • Parameter name: prompt
  • Parameter usage location: Authorization Request
  • Change controller: IETF
  • Specification document(s): [[ this document ]]
  • Related information: None

(draft 07)

10.1.4. Authorization Request Parameter (nonce)

The following is the parameter registration request for the Authorization Request in this specification:

  • Parameter name: nonce
  • Parameter usage location: Authorization Request
  • Change controller: IETF
  • Specification document(s): [[ this document ]]
  • Related information: None

(draft 07)

10.1.5. Authorization Request Parameter (request)

The following is the parameter registration request for the Authorization Request in this specification:

  • Parameter name: request
  • Parameter usage location: Authorization Request
  • Change controller: IETF
  • Specification document(s): [[ this document ]]
  • Related information: None

(draft 07)

10.1.6. Authorization Request Parameter (request_uri)

The following is the parameter registration request for the Authorization Request in this specification:

  • Parameter name: request_uri
  • Parameter usage location: Authorization Request
  • Change controller: IETF
  • Specification document(s): [[ this document ]]
  • Related information: None

(draft 07)

10.1.7. ID Token Response Parameters

The following is the parameter registration request for the ID Token Response in this specification:

(draft 07)

10.2. OAuth Extensions Error Registry

(draft 07)

10.2.1. Authorization Endpoint Error (invalid_request_redirect_uri)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: invalid_request_redirect_uri
  • Error usage location: Authorization Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

10.2.2. Authorization Endpoint Error (login_required)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: login_required
  • Error usage location: Authorization Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

10.2.3. Authorization Endpoint Error (session_selection_required)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: session_selection_required
  • Error usage location: Authorization Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

10.2.5. Authorization Endpoint Error (user_mismatched)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: user_mismatched
  • Error usage location: Authorization Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

10.2.6. Authorization Endpoint Error (invalid_request_request_uri)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: invalid_request_request_uri
  • Error usage location: Authorization Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

10.2.7. Authorization Endpoint Error (invalid_openid_request_object)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: invalid_openid_request_object
  • Error usage location: Authorization Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

10.2.8. Token Endpoint Error (invalid_authorization_code)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: invalid_authorization_code
  • Error usage location: Token Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

10.2.9. UserInfo Endpoint Error (invalid_schema)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: invalid_schema
  • Error usage location: UserInfo Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

10.2.10. Check ID Endpoint Error (invalid_id_token)

The following is the parameter value registration request for the “scope” parameter as defined in this specification:

  • Error name: invalid_schema
  • Error usage location: UserInfo Endpoint
  • Related protocol extension:
  • Change controller: IETF
  • Specification document(s): [[this document ]]

(draft 07)

11. Normative References

JWE
Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” 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.
OAuth.Bearer
Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” December 2011.
OAuth.Responses
de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” December 2011.
OAuth2.0
Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” September 2011.
OpenID.Discovery
Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” December 2011.
OpenID.Messages
Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Messages 1.0,” December 2011.
OpenID.Registration
Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 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).
RFC2616
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, 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).
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).
W3C.REC-html401-19991224
Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).

(draft 07)

«  OpenID Connect Implicit Client Profile 1.0   ::   Contents   ::   OpenID Connect Messages 1.0  »