TOC 
DraftN. Sakimura, Ed.
 NRI
 J. Bradley
 Protiviti Government Services
 B. de Medeiros
 Google
 M. Jones
 Microsoft
 E. Jay
 MGI1
 June 30, 2011


OpenID Connect HTTP Redirect Binding 1.0 - draft 01

Abstract

OpenID Connect HTTP Redirect Binding 1.0 is a HTTP protocol binding of OpenID Connect Core 1.0 and OpenID Framework 1.0 request and response messages.



Table of Contents

1.  Requirements Notation and Conventions
2.  Terminology
3.  Protocol Flows
    3.1.  Authorization Code Flow
        3.1.1.  Client prepares an Authorization Request
            3.1.1.1.  Query Parameters Method
            3.1.1.2.  Request Parameter Method
            3.1.1.3.  Request File Method
        3.1.2.  Authorization Server Authenticates the End-User
        3.1.3.  Authorization Server Obtains the End-User Consent/Authorization
        3.1.4.  Authorization Server Sends the End-User Back to the Client
            3.1.4.1.  End-User Grants Authorization
            3.1.4.2.  End-User Denies Authorization or Invalid Request
        3.1.5.  Client Requests Assertion Using the "code"
        3.1.6.  Client Receives Assertion in the Response Body
            3.1.6.1.  Positive Assertion
            3.1.6.2.  Error Response
        3.1.7.  Accessing UserInfo Endpoint
            3.1.7.1.  Requesting UserInfo
        3.1.8.  RP Receives UserInfo Response
            3.1.8.1.  Error Response
    3.2.  Implicit Flow
        3.2.1.  Client Prepares an Authorization Request URL
        3.2.2.  Client Sends a Request to the Authorization Server
        3.2.3.  Authorization Server Authenticates the End-User
        3.2.4.  Authorization Server Obtains the End-User Consent/Authorization
        3.2.5.  Authorization Server Sends the End-User Back to the Client
            3.2.5.1.  End-User Grants Authorization
            3.2.5.2.  End-User Denies Authorization or Invalid Request
4.  Security Considerations
    4.1.  Assertion Manufacture/Modification
    4.2.  Assertion Disclosure
    4.3.  Assertion Repudiation
    4.4.  Assertion Redirect
    4.5.  Assertion Reuse
    4.6.  Secondary Authenticator Manufacture
    4.7.  Secondary Authenticator Capture
    4.8.  Assertion Substitution
    4.9.  Authentication Request Disclosure
    4.10.  Timing Attack
    4.11.  Authentication Process Threats
    4.12.  Implicit Grant Flow Threats
5.  IANA Considerations
6.  Normative References
Appendix A.  Acknowledgements
Appendix B.  Document History
§  Authors' Addresses




 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) .

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.



 TOC 

2.  Terminology

Followings are the additional terminology defined in this specification in addition to those defined in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] and OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2.0].

Artifact
A small string that acts as a reference to the larger body of data.
Request File
A JSON structure that captures the OpenID Connect Framework 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Framework 1.0 - draft 00,” June 2011.) [OpenID.CF] Authorization Request parameters that can be pointed by a URL that is reachable by the Authorization Server.
Request URI
A URL that points to the Request File. It MUST be accessible by the Authorization Server.
Request Registration Endpoint
An HTTPS Endpoint URL provided by the Authorization Server so that the Client MAY register the Request File to obtain the Request URI.



 TOC 

3.  Protocol Flows

Authorization requests follow two paths, the authorization code flow and the implicit grant flow. The authorization code flow is suitable for clients that can securely maintain client state between itself and the authorization server whereas the implicit grant flow is suitable for clients that cannot.



 TOC 

3.1.  Authorization Code Flow

The authorization code protocol 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 Assertion using the Authorization Code
  7. Client receives Assertion in the response body
  8. (OPTIONAL) Client accesses the UserInfo Endpoint
  9. (OPTIONAL) Client receives UserInfo Response

Note that in each step, the party that receives message MUST verify it according to the verification rule set in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] and OpenID Connect Framework 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Framework 1.0 - draft 00,” June 2011.) [OpenID.CF].



 TOC 

3.1.1.  Client prepares an Authorization Request

When the 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.

The scheme used in the Authorization URL MUST be HTTPS.

This binding further constrains the following request parameters

response_type
It MUST include code.

Other required parameters in the request include the following:

client_id
The client identifier.
scope
It MUST include openid as one of the strings.
redirect_uri
A redirection URI where the response will be sent.

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 encoded OpenID Request Object.
request_uri
A URL that points to an OpenID Request Object.
display
A string value that can be none, popup, or mobile.
prompt
A space delimited list that can contain login, consent, an select_account
nonce
A random, unique string value.
id_token_audience
The target audience identifier for the ID Token.

There are three methods to send the request to the authorization endpoint: a) query parameters method b) request parameter method, and c) request file method.



 TOC 

3.1.1.1.  Query Parameters Method

In the query parameters method, the Client prepares an Authorization Request URL using URI query string serialization as defined in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC].

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.com/op/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj


 TOC 

3.1.1.1.1.  Client sends a request to the Authorization Server

Having constructed the URL, the client sends the End-User to the HTTPS End-User Authorization Endpoint using the URL. This MAY happen via HTTPS redirect, hyperlinking, or any other valid means of directing the User-Agent to the URL.

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.com/op/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&state=af0ifjsldkj



 TOC 

3.1.1.2.  Request Parameter Method

In the request parameter method, the Client prepares an Authorization Request URL using URI query string serialization as defined in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC]. The request parameters MUST include the request parameter defined in the Client Prepares an Authorization Request (Client prepares an Authorization Request) section. The request parameter is a JWT encoded OpenID Request Object which specifies the content and format of the response returned from the UserInfo Endpoint. The JWT object MAY be signed or signed and encrypted via JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS] and JWE (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.) [JWE] respectively, thereby providing non-repudiation and/or security of the request.

Request parameters in the OpenID Request Object takes precedence over query parameters.

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

{
 "inf":
   {
     "clm":
       {
         "name": null,
         "nickname": {"opt": true},
         "email": null,
         "verified": null,
         "picture": {"opt": true},
       },
     "fmt": "sig"
   }
 "idt":
   {
     "mxa": 86400,
     "eaa": "2"
   }
}

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

// replace with JWT string
jwt_header.jwt_payload.jwt_crypto

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.com/op/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj
&request=jwt_header.jwt_payload.jwt_crypto



 TOC 

3.1.1.2.1.  Client Sends a Request to the Authorization Server

Having constructed the URL, the client sends the End-User to the HTTPS End-User Authorization Endpoint using the URL. This MAY happen via HTTPS redirect, hyperlinking, or any other valid means of directing the User-Agent to the URL.

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.com/op/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=af0ifjsldkj&
request=jwt_header.jwt_payload.jwt_crypto



 TOC 

3.1.1.3.  Request File Method

The request file method differs from the other methods in that it uses a request file which contains all the authorization request parameters. It sends the request file URL to the authorization endpoint instead of the request parameters.

The Client prepares a file with a JSON serialized Authorization Request described in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] with a globally reachable URL. Optionally, the request may contain other extension parameters. It MAY be signed or signed and encrypted as in [JWT] (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.). If it is signed with an asymmetric key, then it may be possible to provide non-repudiation capability of the request. For signing, JWS (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.) [JWS] MUST be used. For encryption, JWE (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.) [JWE] MUST be used.

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

{
    "response_type": "code",
    "client_id": "s6BhdRkqt3",
    "redirect_uri": "https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb",
    "scope": "openid",
    "state": "af0ifjsldkj"
}


 TOC 

3.1.1.3.1.  Client Obtains the URL of the Request File

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

Optionally, the Authorization Server may provide the Request File registration service at the Request Registration Endpoint, which allows the Client to register the Request File and obtain the URL for it in exchange. This is especially useful for the cases when the RP is behind the firewall or lives on a client device that cannot be accessed from the Authorization Server.



 TOC 

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

The Client sends the user to the HTTPS End-User Authorization Endpoint through the HTTP 302 redirect with the following parameters

response_type
REQUIRED. "code".
client_id
REQUIRED. The Client Identifier.
request_uri
REQUIRED. The Request URI.
state
OPTIONAL. An opaque value used by the Client to maintain state between the request and callback. If provided, the Authorization Server MUST include this value when redirecting the user-agent back to the Client. Clients are strongly advised to use this variable to relate the request and response.

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://rp.example.com/rp.php?response_type=code&cliend_id=ab1
&request_uri=https://rp.example.com/rf.js%23Qfsoe2F
&state=A02FB8C



 TOC 

3.1.1.3.3.  Authorization Server Fetches the Request File

Upon receipt of the Request, the Authorization Server MUST send a GET request to the request_uri to retrieve the content unless it is already cached and parse it to recreate the authorization request parameters.

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

GET /rf.js HTTP/1.1
Host:rp.example.com


 TOC 

3.1.2.  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.



 TOC 

3.1.3.  Authorization Server Obtains the End-User Consent/Authorization

Once the user is authenticated, the Authorization Server MUST obtain an authorization decision. This MAY be done by presenting the user with a dialogue that allows the user to recognize what he is consenting to and obtain his consent or by establishing approval via other means ( for example, via previous administrative approval )



 TOC 

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

Once the authorization is determined, the Authorization Server returns a positive or negative response.



 TOC 

3.1.4.1.  End-User Grants Authorization

If the resource owner grants the access request, the authorization server issues an Authorization code and delivers it to the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format:

code
REQUIRED. The Authorization Code.
state
REQUIRED if the "state" parameter in the request. Set to the exact value of the "state" parameter received from the client.

No other parameter SHOULD be returned. The entire URL MUST NOT exceed 512 bytes.

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.com/rp?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&state=af0ifjsldkj



 TOC 

3.1.4.2.  End-User Denies Authorization or Invalid Request

If the user denies the authorization or the user authentication fails, the server MUST return the negative authorization response as defined in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC]. No other parameter SHOULD be returned.

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.com/rp?
error=invalid_request
&error_description=the%20request%20is%20not%20valid%20or%20malformed
&state=af0ifjsldkj


 TOC 

3.1.5.  Client Requests Assertion Using the "code"

Upon receipt of the "code", the Client requests an Assertion that includes the "access_token" and other variables. To obtain the assertion, the client send the following parameters via HTTPS POST to the token endpoint using application/x-www-form-urlencoded format in the HTTP request entity-body:

grant_type
REQUIRED. A string "authorization_code".
code
REQUIRED. The authorization code received from the authorization server.
client_id
REQUIRED. The client_id of the RP.
secret_type
OPTIONAL. Specifies the client authentication type which determines how the client_secret parameter is interpreted. It can be one of "basic" or "JWT". Defaults to "basic".
client_secret
OPTIONAL. Client Secret. If the secret_type is "basic", send the pre-shared secret. If the secret_type is "JWT", send the compact serialization of the JWT (Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.) [JWT] Signature over the 'code'.

TODO - we shouldn't constrain the authentication options here, but rather defer to OAuth2 and applicable extensions.

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

grant_type=authorization_code
&code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&client_id=s6BhdRkqt3
&client_secret=1234qwer
&secret_type=basic


 TOC 

3.1.6.  Client Receives Assertion in the Response Body

Upon receipt of the Token Request, the Server MUST return either Positive or Negative Assertion that corresponds to the received authorization code.



 TOC 

3.1.6.1.  Positive Assertion

A Positive Assertion response returns the "application/json" media type and the response body is the Access Token Response of the OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC].

The assertion is a JSON structure which MUST contain the following values:

access_token
The access token.
token_type
Specifies the access token type. This specification defines the "JWT" type for a JWT token.

In addition, it can contain the optional refresh_token, expires_in, scope, and ID Token values.

The authorization server MUST include a HTTP Cache-Control response header field with a value of no-store in any response containing tokens, secrets, or other sensitive information.

Following is a non-normative example of the Positive Assertion:

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

{
    "access_token": "SlAV32hkKG",
    "token_type": "JWT",
    "refresh_token": "8xLOxBtZp8",
    "user_id": "http://op.example.com/alice#1234",
    "domain": "op.example.com",
    "expires_in": 3600,
    "id_token":"jwtheader.jwtpayload.jwtcrypto"
}



 TOC 

3.1.6.2.  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 Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] 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

{
  "error":"invalid_request"
}


 TOC 

3.1.7.  Accessing UserInfo Endpoint

To obtain the additional attributes and tokens/assertions, the client makes a GET or POST request to the UserInfo Endpoint as in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] and OpenID Connect Framework 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Framework 1.0 - draft 00,” June 2011.) [OpenID.CF].



 TOC 

3.1.7.1.  Requesting UserInfo

Client SHOULD send the UserInfo request defined in section 4.3.1 of the OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC] either in HTTP GET or POST request.

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



 TOC 

3.1.8.  RP Receives UserInfo Response

Upon receipt of the UserInfo Request, the UserInfo Endpoint MUST return the JSON Serialization of the UserInfo Response as in [OpenID.CC] (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) in the HTTP response body.

Following is a non-normative example of such response.

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



 TOC 

3.1.8.1.  Error Response

When some error condition arises, the UserInfo endpoint returns the Error Response defined in section 4.3.3 of the OpenID Connect Core (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC]



 TOC 

3.2.  Implicit Flow

The implicit grant 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


 TOC 

3.2.1.  Client Prepares an Authorization Request URL

When the user wishes to access a Protected Resource, and the End-User Authorization has not yet been obtained, the Client prepares an Authorization Request URL using URI query string serialization as defined in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC].

The scheme used in the Authorization URL MUST be HTTPS.

This binding further constrains the following request parameters

response_type
It MUST include token.

The request MUST contain the other required parameters and MAY contain optional parameters as defined in the preparing an authorization request (Client prepares an Authorization Request) section.



 TOC 

3.2.2.  Client Sends a Request to the Authorization Server

Having constructed the URL, the client sends the End-User to the HTTPS End-User Authorization Endpoint using the URL. This MAY happen via HTTPS redirect, hyperlinking, or any other valid means of directing the User-Agent to the URL.

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.com/op/authorize?
response_type=token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&state=af0ifjsldkj



 TOC 

3.2.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.



 TOC 

3.2.4.  Authorization Server Obtains the End-User Consent/Authorization

Once the user is authenticated, the Authorization Server MUST obtain an authorization decision. This MAY be done by presenting the user with a dialogue that allows the user to recognize what he is consenting to and obtain his consent or by establishing approval via other means ( for example, via previous administrative approval )



 TOC 

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

Once the authorization is determined, the Authorization Server returns a positive or negative response.



 TOC 

3.2.5.1.  End-User Grants Authorization

If the resource owner grants the access request, the authorization server issues an access token and delivers it to the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format:

access_token
REQUIRED. The AccessToken
state
REQUIRED if the "state" parameter in the request. Set to the exact value of the "state" parameter received from the client.
id_token
REQUIRED if the response_type parameter in the request included the id_token value.

The client can then use the Access Token to access protected resources at resource servers.

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.com/rp#
access_token=jwt_header.jwt_payload.jwt_crypto&
token_type=JWT&
expires_in=3600&
&state=af0ifjsldkj



 TOC 

3.2.5.2.  End-User Denies Authorization or Invalid Request

If the user denies the authorization or the user authentication fails, the server MUST return the negative authorization response as defined in OpenID Connect Core 1.0 (Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.) [OpenID.CC]. No other parameter SHOULD be returned.



 TOC 

4.  Security Considerations

Followings are the list of attack vectors and remedies that were considered for this specification.

For details of the attack vector, see [SP800‑63] (National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” .).



 TOC 

4.1.  Assertion Manufacture/Modification

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

  1. 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.
  2. 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.


 TOC 

4.2.  Assertion Disclosure

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

  1. Assertion is sent over TLS/SSL protected channel, where RP is authenticated by "client_id" and "client_secret".
  2. Signed Assertion is encrypted by the RP's public key.


 TOC 

4.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.



 TOC 

4.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.



 TOC 

4.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.



 TOC 

4.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.



 TOC 

4.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.



 TOC 

4.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.



 TOC 

4.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.



 TOC 

4.10.  Timing Attack

Timing attack 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.



 TOC 

4.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.



 TOC 

4.12.  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 malwares.



 TOC 

5.  IANA Considerations

This specification does not request any additional parameters than what is defined in the OpenID Connect Core.



 TOC 

6. Normative References

[JWE] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.
[JWS] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.
[JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.
[OAuth2.0] Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2011.
[OpenID.CC] Recordon, D., Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, “OpenID Connect Core 1.0,” June 2011.
[OpenID.CF] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Framework 1.0 - draft 00,” June 2011.
[RFC1421] Linn, J., “Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures,” RFC 1421, February 1993 (TXT).
[RFC1422] Kent, S., “Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management,” RFC 1422, February 1993 (TXT).
[RFC1423] Balenson, D., “Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers,” RFC 1423, February 1993 (TXT).
[RFC1424] Kaliski, B., “Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services,” RFC 1424, February 1993 (TXT).
[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” RFC 1750, December 1994 (TXT).
[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).
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, June 1999 (TXT, HTML, XML).
[RFC3548] Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 3548, July 2003 (TXT).
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, November 2003 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[SP800-63] National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” NIST SP800-63.
[UserInfo.Endpoint] Sakimura, N., Bradley, J., de Medeiros, B., and M. Jones, “OpenID Connect UserInfo Endpoint 1.0,” June 2011.


 TOC 

Appendix A.  Acknowledgements

The OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification.

Axel Nennker (axel.nennker@telekom.de)

Breno de Medeiros (breno@gmail.com)

George Fletcher (gffletch@aol.com)

Hideki Nara (hideki.nara@gmail.com)

John Bradley (jbradely@mac.com)

Nat Sakimura (n-sakimura@nri.co.jp)

Ryo Itou (ritou@yahoo-corp.jp)



 TOC 

Appendix B.  Document History

-01
Initial draft


 TOC 

Authors' Addresses

  Nat Sakimura (editor)
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Protiviti Government Services
Email:  jbradley@mac.com
  
  Breno de Medeiros
  Google Inc.
Email:  breno@google.com
  
  Michael B. Jones
  Microsoft Corporation
Email:  mbj@microsoft.com
  
  Edmund Jay
  MGI1
Email:  ejay@mgi1.com