TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 B. de Medeiros
 Google
 E. Jay
 Illumila
 May 3, 2013


OpenID Connect Standard 1.0 - draft 19

Abstract

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

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



Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
    1.2.  Terminology
2.  Authorization Endpoint
    2.1.  Protocol Flows
        2.1.1.  Obtaining the Authorization Code, ID Token, and Access Token
        2.1.2.  Authorization Code Flow
        2.1.3.  Implicit Flow
    2.2.  Authorization Request
        2.2.1.  Client Prepares Authorization Request
            2.2.1.1.  Request Parameters
        2.2.2.  Request Methods
            2.2.2.1.  Simple Request Method
                2.2.2.1.1.  Client Sends Request to Authorization Server
            2.2.2.2.  Request Parameter Method
                2.2.2.2.1.  Client Sends Request to Authorization Server
            2.2.2.3.  Request File Method
                2.2.2.3.1.  Client Generates the URL of the Request File
                2.2.2.3.2.  Client Sends Request to Authorization Server via HTTPS Redirect
                2.2.2.3.3.  Authorization Server Fetches Request File
        2.2.3.  Authorization Server Validates Request Object
        2.2.4.  Authorization Server Authenticates End-User
        2.2.5.  Authorization Server Obtains End-User Consent/Authorization
        2.2.6.  Authorization Server Sends End-User Back to Client
            2.2.6.1.  End-User Grants Authorization
            2.2.6.2.  End-User Denies Authorization or Invalid Request
3.  Token Endpoint
    3.1.  Requesting Access Token
        3.1.1.  Access Token Request
        3.1.2.  Access Token Response
        3.1.3.  Access Token Error Response
    3.2.  Refreshing Access Token
        3.2.1.  Refresh Token Response
        3.2.2.  Refresh Token Error Response
4.  UserInfo Endpoint
    4.1.  UserInfo Request
    4.2.  UserInfo Response
    4.3.  UserInfo Error Response
5.  Self-Issued OpenID Provider
6.  Initiating Login at Client from Third Party
7.  Serializations
    7.1.  Query String Serialization
    7.2.  Form Serialization
    7.3.  JSON Serialization
8.  Implementation Considerations
    8.1.  Discovery and Registration
9.  Security Considerations
    9.1.  Implicit Grant Flow Threats
    9.2.  TLS Requirements
10.  Privacy Considerations
11.  IANA Considerations
12.  References
    12.1.  Normative References
    12.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
§  Authors' Addresses




 TOC 

1.  Introduction

This specification describes the binding of the HTTP protocol with the endpoints described in OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].



 TOC 

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] (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 

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 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749], and the terms defined by OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].

This specification also defines the following terms:

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


 TOC 

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 that 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 that asserts the End-User's identifier and an Access Token that 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 by using the response_type parameter in the Authorization Request.



 TOC 

2.1.  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 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]. 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 that 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 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.



 TOC 

2.1.1.  Obtaining the Authorization Code, ID Token, and Access Token

In this specification, the Client sends the Authorization Request to the Authorization Endpoint through the User-Agent to obtain the ID Token and Access Token. It can obtain them from the Token Endpoint utilizing the Authorization Code that it obtained from the Authorization Endpoint using the Authorization Code Flow or from the Authorization Endpoint using the Implicit Flow.



 TOC 

2.1.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, per Section 3 (Token Endpoint).
  7. Client receives a response that contains an Access Token and ID Token in the response body.
  8. Client validates the ID Token and retrieves the End-User's subject identifier.
  9. (OPTIONAL) Client accesses the UserInfo Endpoint with the Access Token, per Section 4 (UserInfo Endpoint).
  10. (OPTIONAL) Client receives UserInfo Response.

Note that in each step, the party that receives a message MUST validate it according to the validation rules in OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].



 TOC 

2.1.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. Client validates the ID Token and retrieves the End-User's subject identifier.
  7. (OPTIONAL) Client accesses the UserInfo Endpoint with the Access Token, per Section 4 (UserInfo Endpoint).
  8. (OPTIONAL) Client receives UserInfo Response.

Note that in each step, the party that receives a message MUST validate it according to the validation rules in OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].



 TOC 

2.2.  Authorization Request

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

Communication with the Authorization Endpoint MUST utilize TLS. See Section 9.2 (TLS Requirements) for more information on using TLS.

Authorization Servers MUST support the use of the HTTP GET and POST methods defined in RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] at the Authorization Endpoint.

Clients MAY use the HTTP GET or POST methods 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, per Section 7.1 (Query String Serialization). If using the HTTP POST method, the request parameters are serialized using Form Serialization, per Section 7.2 (Form Serialization).



 TOC 

2.2.1.  Client Prepares 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.



 TOC 

2.2.1.1.  Request Parameters

OpenID Connect uses the following OAuth 2.0 request parameters:

response_type
REQUIRED. OAuth 2.0 registered response type value that determines how the Authorization Response is returned to the Client. As described in OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” November 2012.) [OAuth.Responses], the following registered values are supported by OpenID Connect:
  • code
  • code id_token
  • id_token
  • token id_token
  • code token
  • code token id_token
client_id
REQUIRED. OAuth 2.0 Client Identifier.
scope
REQUIRED. Space delimited, case sensitive list of ASCII OAuth 2.0 scope values. OpenID Connect requests MUST contain the openid scope value. OPTIONAL scope values of profile, email, address, phone, and offline_access are also defined. Section 2.4 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages] defines the OpenID Connect scope values.
redirect_uri
REQUIRED. Redirection URI to which the response will be sent. The Scheme, Host, Path, and Query Parameter 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 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2013.) [OpenID.Registration] specification.
state
RECOMMENDED. Opaque value used to maintain state between the request and the callback.

This specification also uses the following request parameters. Refer to OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages] for more information about these parameters.

nonce
REQUIRED or OPTIONAL. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authorization Request to the ID Token. Use of the nonce is REQUIRED when using the implicit flow and OPTIONAL when using the code flow.
display
OPTIONAL. ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User. The defined values are: page, popup, touch, and wap.
prompt
OPTIONAL. Space delimited, case sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent. The defined values are: none, login, consent, and select_account.
max_age
OPTIONAL. Maximum Authentication Age. Specifies that the End-User must be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds.
ui_locales
OPTIONAL. End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [RFC5646] language tag values, ordered by preference.
claims_locales
OPTIONAL. End-User's preferred languages and scripts for Claims being returned, represented as a space-separated list of BCP47 (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [RFC5646] language tag values, ordered by preference.
id_token_hint
OPTIONAL. Previously issued ID Token passed to the Authorization Server as a hint about the End-User this request is about.
login_hint
OPTIONAL. Hint to the Authorization Server about the login identifier the End-User may use to log in (if necessary).
acr_values
OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server MUST use for processing requests from this Client.
claims
OPTIONAL. This parameter is used to request that specific Claims be returned. The value is a JSON object listing the requested Claims.
registration
OPTIONAL. This parameter is used by the Client to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration.
request
OPTIONAL. Request Object value.
request_uri
OPTIONAL. URL that references a resource containing a Request Object value.



 TOC 

2.2.2.  Request Methods

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 can be used in cases where signed or encrypted requests are not needed and where the size of the request does not exceed limits imposed by User-Agents.

The Request Parameter Method is used when the Client wants or needs to send an OpenID Connect request as a single, self-contained Request Object value. This method enables requests to be signed and optionally encrypted. Like the Simple Request Method, some requests using this method may exceed limits imposed by User-Agents.

The Request File Method works similarly to the Request Parameter Method but differs in that it sends a URL as a reference to the Request Object. It enables large requests to be sent securely and compactly even on User-Agents with limited capabilities. Clients MAY use the Request File Method to minimize the request size.



 TOC 

2.2.2.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, per Section 7.1 (Query String Serialization). If using the HTTP POST method, the request parameters are serialized using Form Serialization, per Section 7.2 (Form Serialization).

The following is a non-normative example of an Authorization Request URL (with line wraps within the values for display purposes only):

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


 TOC 

2.2.2.1.1.  Client Sends Request to Authorization Server

Having constructed the Authorization Request, the Client sends it to the Authorization Endpoint using HTTPS.

Following is a non-normative example using HTTP redirect (with line wraps within the values for display purposes 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.example.org%2Fcb
    &scope=openid
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj


 TOC 

2.2.2.2.  Request Parameter Method

The Client prepares an Authorization Request to the Authorization Endpoint using the appropriate HTTP parameter 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 Section 2.2.1.1 (Request Parameters). The Authorization Request MUST NOT include the request_uri parameter.

The request parameter is a Request Object represented as a JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” April 2013.) [JWT] containing a set of OpenID Connect request parameters. The Request Object MAY be signed or signed and encrypted via JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” April 2013.) [JWS] and JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” April 2013.) [JWE] respectively, thereby providing authentication, integrity, non-repudiation and/or confidentiality.

The following is a non-normative example of the Claims in a Request Object before base64url encoding and signing:

  {
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",
   "redirect_uri": "https://client.example.org/cb",
   "scope": "openid",
   "state": "af0ifjsldkj",
   "nonce": "n-0S6_WzA2Mj",
   "max_age": 86400,
   "claims":
    {
     "userinfo":
      {
       "given_name": {"essential": true},
       "nickname": null,
       "email": {"essential": true},
       "email_verified": {"essential": true},
       "picture": null
      },
     "id_token":
      {
       "gender": null,
       "birthdate": {"essential": true},
       "acr": {"values": ["urn:mace:incommon:iap:silver"]}
      }
    }
  }

Signing it with the RS256 algorithm results in this Request Object value (with line breaks for display purposes only):

  eyJhbGciOiJSUzI1NiJ9.ew0KICJyZXNwb25zZV90eXBlIjogImNvZGUgaWRfdG9rZW
  4iLA0KICJjbGllbnRfaWQiOiAiczZCaGRSa3F0MyIsDQogInJlZGlyZWN0X3VyaSI6I
  CJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQogInNjb3BlIjogIm9wZW5p
  ZCIsDQogInN0YXRlIjogImFmMGlmanNsZGtqIiwNCiAibm9uY2UiOiAibi0wUzZfV3p
  BMk1qIiwNCiAibWF4X2FnZSI6IDg2NDAwLA0KICJjbGFpbXMiOiANCiAgew0KICAgIn
  VzZXJpbmZvIjogDQogICAgew0KICAgICAiZ2l2ZW5fbmFtZSI6IHsiZXNzZW50aWFsI
  jogdHJ1ZX0sDQogICAgICJuaWNrbmFtZSI6IG51bGwsDQogICAgICJlbWFpbCI6IHsi
  ZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW5
  0aWFsIjogdHJ1ZX0sDQogICAgICJwaWN0dXJlIjogbnVsbA0KICAgIH0sDQogICAiaW
  RfdG9rZW4iOiANCiAgICB7DQogICAgICJnZW5kZXIiOiBudWxsLA0KICAgICAiYmlyd
  GhkYXRlIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImFjciI6IHsidmFsdWVz
  IjogWyIyIl19DQogICAgfQ0KICB9DQp9.bOD4rUiQfzh4QPIs_f_R2GVBhNHcc1p2cQ
  TgixB1tsYRs52xW4TO74USgb-nii3RPsLdfoPlsEbJLmtbxG8-TQBHqGAyZxMDPWy3p
  hjeRt9ApDRnLQrjYuvsCj6byu9TVaKX9r1KDFGT-HLqUNlUTpYtCyM2B2rLkWM08ufB
  q9JBCEzzaLRzjevYEPMaoLAOjb8LPuYOYTBqshRMUxy4Z380-FJ2Lc7VSfSu6HcB2nL
  SjiKrrfI35xkRJsaSSmjasMYeDZarYCl7r4o17rFclk5KacYMYgAs-JYFkwab6Dd56Z
  rAzakHt9cExMpg04lQIux56C-Qk6dAsB6W6W91AQ

The following is the RSA public key in JWK format that can be used to validate the Request Object signature in the above example (with line breaks for display purposes only):

  {
   "kty":"RSA",
   "n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKG
  HAtKlE5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF
  I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZaZEN9lsn_
  GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYRadBJVoWZowDNTpKp
  k2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xVW53am_UZZ3tZbFTIh557JICW
  KHlWj5uzeJXaw",
   "e":"AQAB"
  }

The following is a non-normative example of an Authorization Request using the request parameter (with line wraps within the values for display purposes only):

  https://server.example.com/authorize?
    response_type=code%02id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &request=eyJhbGciOiJSUzI1NiJ9.ew0KICJyZXNwb25zZV90eXBlIjogImNvZG
    UgaWRfdG9rZW4iLA0KICJjbGllbnRfaWQiOiAiczZCaGRSa3F0MyIsDQogInJlZG
    lyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQogIn
    Njb3BlIjogIm9wZW5pZCIsDQogInN0YXRlIjogImFmMGlmanNsZGtqIiwNCiAibm
    9uY2UiOiAibi0wUzZfV3pBMk1qIiwNCiAibWF4X2FnZSI6IDg2NDAwLA0KICJjbG
    FpbXMiOiANCiAgew0KICAgInVzZXJpbmZvIjogDQogICAgew0KICAgICAiZ2l2ZW
    5fbmFtZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJuaWNrbmFtZSI6IG
    51bGwsDQogICAgICJlbWFpbCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgIC
    JlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJwaW
    N0dXJlIjogbnVsbA0KICAgIH0sDQogICAiaWRfdG9rZW4iOiANCiAgICB7DQogIC
    AgICJnZW5kZXIiOiBudWxsLA0KICAgICAiYmlydGhkYXRlIjogeyJlc3NlbnRpYW
    wiOiB0cnVlfSwNCiAgICAgImFjciI6IHsidmFsdWVzIjogWyIyIl19DQogICAgfQ
    0KICB9DQp9.bOD4rUiQfzh4QPIs_f_R2GVBhNHcc1p2cQTgixB1tsYRs52xW4TO7
    4USgb-nii3RPsLdfoPlsEbJLmtbxG8-TQBHqGAyZxMDPWy3phjeRt9ApDRnLQrjY
    uvsCj6byu9TVaKX9r1KDFGT-HLqUNlUTpYtCyM2B2rLkWM08ufBq9JBCEzzaLRzj
    evYEPMaoLAOjb8LPuYOYTBqshRMUxy4Z380-FJ2Lc7VSfSu6HcB2nLSjiKrrfI35
    xkRJsaSSmjasMYeDZarYCl7r4o17rFclk5KacYMYgAs-JYFkwab6Dd56ZrAzakHt
    9cExMpg04lQIux56C-Qk6dAsB6W6W91AQ


 TOC 

2.2.2.2.1.  Client Sends Request to Authorization Server

Having constructed the Authorization Request, the Client sends it to the Authorization Endpoint using HTTPS.

Following is a non-normative example using HTTP redirect (with line wraps within the values for display purposes 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.example.org%2Fcb
    &scope=openid
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &request=eyJhbGciOiJSUzI1NiJ9.ew0KICJyZXNwb25zZV90eXBlIjogImNvZG
    UgaWRfdG9rZW4iLA0KICJjbGllbnRfaWQiOiAiczZCaGRSa3F0MyIsDQogInJlZG
    lyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQogIn
    Njb3BlIjogIm9wZW5pZCIsDQogInN0YXRlIjogImFmMGlmanNsZGtqIiwNCiAibm
    9uY2UiOiAibi0wUzZfV3pBMk1qIiwNCiAibWF4X2FnZSI6IDg2NDAwLA0KICJjbG
    FpbXMiOiANCiAgew0KICAgInVzZXJpbmZvIjogDQogICAgew0KICAgICAiZ2l2ZW
    5fbmFtZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJuaWNrbmFtZSI6IG
    51bGwsDQogICAgICJlbWFpbCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgIC
    JlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJwaW
    N0dXJlIjogbnVsbA0KICAgIH0sDQogICAiaWRfdG9rZW4iOiANCiAgICB7DQogIC
    AgICJnZW5kZXIiOiBudWxsLA0KICAgICAiYmlydGhkYXRlIjogeyJlc3NlbnRpYW
    wiOiB0cnVlfSwNCiAgICAgImFjciI6IHsidmFsdWVzIjogWyIyIl19DQogICAgfQ
    0KICB9DQp9.bOD4rUiQfzh4QPIs_f_R2GVBhNHcc1p2cQTgixB1tsYRs52xW4TO7
    4USgb-nii3RPsLdfoPlsEbJLmtbxG8-TQBHqGAyZxMDPWy3phjeRt9ApDRnLQrjY
    uvsCj6byu9TVaKX9r1KDFGT-HLqUNlUTpYtCyM2B2rLkWM08ufBq9JBCEzzaLRzj
    evYEPMaoLAOjb8LPuYOYTBqshRMUxy4Z380-FJ2Lc7VSfSu6HcB2nLSjiKrrfI35
    xkRJsaSSmjasMYeDZarYCl7r4o17rFclk5KacYMYgAs-JYFkwab6Dd56ZrAzakHt
    9cExMpg04lQIux56C-Qk6dAsB6W6W91AQ


 TOC 

2.2.2.3.  Request File Method

The Request File Method differs from the other methods in that it uses a Request File that contains a 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 Authorization Request MUST NOT include the request parameter. The Authorization Request MUST include the request_uri parameter. The contents of the resource referenced by the URL must be a Request Object. The scheme used in the request_uri value MUST be https, unless the target Request Object 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.

Following is a non-normative example of the contents of a Request File (with line wraps within the values for display purposes only):

  eyJhbGciOiJSUzI1NiJ9.ew0KICJyZXNwb25zZV90eXBlIjogImNvZGUgaWRfdG9rZ
  W4iLA0KICJjbGllbnRfaWQiOiAiczZCaGRSa3F0MyIsDQogInJlZGlyZWN0X3VyaSI
  6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQogInNjb3BlIjogIm9wZ
  W5pZCIsDQogInN0YXRlIjogImFmMGlmanNsZGtqIiwNCiAibm9uY2UiOiAibi0wUzZ
  fV3pBMk1qIiwNCiAibWF4X2FnZSI6IDg2NDAwLA0KICJjbGFpbXMiOiANCiAgew0KI
  CAgInVzZXJpbmZvIjogDQogICAgew0KICAgICAiZ2l2ZW5fbmFtZSI6IHsiZXNzZW5
  0aWFsIjogdHJ1ZX0sDQogICAgICJuaWNrbmFtZSI6IG51bGwsDQogICAgICJlbWFpb
  CI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJlbWFpbF92ZXJpZmllZCI6IHs
  iZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJwaWN0dXJlIjogbnVsbA0KICAgIH0sD
  QogICAiaWRfdG9rZW4iOiANCiAgICB7DQogICAgICJnZW5kZXIiOiBudWxsLA0KICA
  gICAiYmlydGhkYXRlIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImFjciI6I
  HsidmFsdWVzIjogWyIyIl19DQogICAgfQ0KICB9DQp9.bOD4rUiQfzh4QPIs_f_R2G
  VBhNHcc1p2cQTgixB1tsYRs52xW4TO74USgb-nii3RPsLdfoPlsEbJLmtbxG8-TQBH
  qGAyZxMDPWy3phjeRt9ApDRnLQrjYuvsCj6byu9TVaKX9r1KDFGT-HLqUNlUTpYtCy
  M2B2rLkWM08ufBq9JBCEzzaLRzjevYEPMaoLAOjb8LPuYOYTBqshRMUxy4Z380-FJ2
  Lc7VSfSu6HcB2nLSjiKrrfI35xkRJsaSSmjasMYeDZarYCl7r4o17rFclk5KacYMYg
  As-JYFkwab6Dd56ZrAzakHt9cExMpg04lQIux56C-Qk6dAsB6W6W91AQ


 TOC 

2.2.2.3.1.  Client Generates the URL of the Request File

The Client stores the Request File either locally or remotely. This is the Request URI, request_uri. Servers MAY cache the contents of the files referenced by request URIs. If the contents of the Request File could ever change, the URI SHOULD include the base64url encoded SHA-256 hash of the referenced file contents as the fragment component of the URI. If the fragment value used for a URI changes, that signals the server that any cached value for that URI with the old fragment value is no longer valid.

Note that Clients MAY pre-register request_uri values using the request_uris parameter defined in Section 2 of the OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2013.) [OpenID.Registration] specification. OPs can require that request_uri values used be pre-registered with the require_request_uri_registration discovery parameter.

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

Following is a non-normative example (with line wraps for display purposes only):

  https://client.example.org/rf.txt
    #GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM


 TOC 

2.2.2.3.2.  Client Sends 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 (with line wraps within the values for display purposes only):

  HTTP/1.1 302 Found
  Location: https://server.example.com/authorize
    ?response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &request_uri=https%3A%2F%2Fclient.example.org%2Frf.txt
    %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
    &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj&scope=openid


 TOC 

2.2.2.3.3.  Authorization Server Fetches 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.

Note that the RP SHOULD use a unique URI for each request utilizing distinct parameters, or otherwise prevent the Authorization Server from caching the request_uri.

Following is a non-normative example of this fetch process:

  GET /rf.txt HTTP/1.1
  Host: client.example.org


 TOC 

2.2.3.  Authorization Server Validates Request Object

The Authorization Server validates the request according to Section 5.1 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].



 TOC 

2.2.4.  Authorization Server Authenticates 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:



 TOC 

2.2.5.  Authorization Server Obtains End-User Consent/Authorization

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

The Authorization Server MUST attempt to request authorization from the End-User in the following cases:

The Authorization Server MUST NOT request End-User authorization in the following cases:



 TOC 

2.2.6.  Authorization Server Sends End-User Back to Client

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



 TOC 

2.2.6.1.  End-User Grants Authorization

If the Resource Owner grants the access request, the Authorization Server issues an Authorization Response as described in Section 2.1.2 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages] to the Client by adding the response parameters to redirect_uri specified in the Authorization Request using the "application/x-www-form-urlencoded" format.

Note that if the response_type parameter in the Authorization Request includes the string value token or id_token, all 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 are non-normative examples of requests with differing response_type values and their responses (with line wraps within the values for display purposes only):

Case 1: response_type=code

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

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

Case 2: response_type=token id_token

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

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &token_type=Bearer
    &id_token=eyJhbGciOiJSUzI1NiJ9.ew0KICJpc3MiOiAiaHR0cDovL3NlcnZlc
    i5leGFtcGxlLmNvbSIsDQogInN1YiI6ICIyNDgyODk3NjEwMDEiLA0KICJhdWQiO
    iAiczZCaGRSa3F0MyIsDQogIm5vbmNlIjogIm4tMFM2X1d6QTJNaiIsDQogImV4c
    CI6IDEzMTEyODE5NzAsDQogImlhdCI6IDEzMTEyODA5NzAsDQogImF0X2hhc2giO
    iAiNzdRbVVQdGpQZnpXdEYyQW5wSzlSUSINCn0.g7UR4IDBNIjoPFV8exQCosUNV
    eh8bNUTeL4wdQp-2WXIWnly0_4ZK0sh4A4uddfenzo4Cjh4wuPPrSw6lMeujYbGy
    zKspJrRYL3iiYWc2VQcl8RKdHPz_G-7yf5enut1YE8v7PhKucPJCRRoobMjqD73f
    1nJNwQ9KBrfh21Ggbx1p8hNqQeeLLXb9b63JD84hVOXwyHmmcVgvZskge-wExwnh
    Ivv_cxTzxIXsSxcYlh3d9hnu0wdxPZOGjT0_nNZJxvdIwDD4cAT_LE5Ae447qB90
    ZF89Nmb0Oj2b1GdGVQEIr8-FXrHlyD827f0N_hLYPdZ73YK6p10qY9oRtMimg
    &state=af0ifjsldkj

Verifying and decoding the ID Token will yield the following Claims:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "77QmUPtjPfzWtF2AnpK9RQ"
  }

Case 3: response_type=code id_token

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

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &id_token=eyJhbGciOiJSUzI1NiJ9.ew0KICJpc3MiOiAiaHR0cDovL3NlcnZlc
    i5leGFtcGxlLmNvbSIsDQogInN1YiI6ICIyNDgyODk3NjEwMDEiLA0KICJhdWQiO
    iAiczZCaGRSa3F0MyIsDQogIm5vbmNlIjogIm4tMFM2X1d6QTJNaiIsDQogImV4c
    CI6IDEzMTEyODE5NzAsDQogImlhdCI6IDEzMTEyODA5NzAsDQogImNfaGFzaCI6I
    CJMRGt0S2RvUWFrM1BrMGNuWHhDbHRBIg0KfQ.dAVXerlNOJ_tqMUysD_k1Q_bRX
    RJbLkTOsCPVxpKUis5V6xMRvtjfRg8gUfPuAMYrKQMEqZZmL87Hxkv6cFKavb4ft
    BUrY2qUnrvqe_bNjVEz89QSdxGmdFwSTgFVGWkDf5dV5eIiRxXfIkmlgCltPNocR
    AyvdNrsWC661rHz5F9MzBho2vgi5epUa_KAl6tK4ksgl68pjZqlBqsWfTbGEsWQX
    Efu664dJkdXMLEnsPUeQQLjMhLH7qpZk2ry0nRx0sS1mRwOM_Q0Xmps0vOkNn284
    pMUpmWEAjqklWITgtVYXOzF4ilbmZK6ONpFyKCpnSkAYtTEuqz-m7MoLCD_A
    &state=af0ifjsldkj

Verifying and decoding the ID Token will yield the following Claims:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }

Case 4: response_type=token code

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

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

Case 5: response_type=token code id_token

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

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &token_type=Bearer
    &id_token=eyJhbGciOiJSUzI1NiJ9.ew0KICJpc3MiOiAiaHR0cDovL3NlcnZlc
    i5leGFtcGxlLmNvbSIsDQogInN1YiI6ICIyNDgyODk3NjEwMDEiLA0KICJhdWQiO
    iAiczZCaGRSa3F0MyIsDQogIm5vbmNlIjogIm4tMFM2X1d6QTJNaiIsDQogImV4c
    CI6IDEzMTEyODE5NzAsDQogImlhdCI6IDEzMTEyODA5NzAsDQogImF0X2hhc2giO
    iAiNzdRbVVQdGpQZnpXdEYyQW5wSzlSUSIsDQogImNfaGFzaCI6ICJMRGt0S2RvU
    WFrM1BrMGNuWHhDbHRBIg0KfQ.JQthrBsOirujair9aD5gj1Yd5qEv0j4fhLgl8h
    3RaH3soYhwPOiN2Iy_yb7wMCO6I3bPoGJc3zCkpjgUtdB4O2eEhFqXHdwnE4c0oV
    TaTHJi_PdV2ox9g-1ikDB0ckWk0f0SzBd7yM2RoYYxJCiGBQlsSSRQz6ehykonI3
    hLAhXFdpfbK-3_a3HBNKOv_9Mr_JJrz2pqSygk5IBNvwzf1ouVeM91KKvr7EdriK
    N8ysk68fctbFAga1p8rE3cfBOX7Acn4p9QSNpUx0i_x4WHktyKDvH_hLdUw91Fql
    _UOgMP_9h8TYdkAjcq8n1tFzaO7kVaazlZ5SM32J7OSDgNSA
    &state=af0ifjsldkj

Verifying and decoding the ID Token will yield the following Claims:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "77QmUPtjPfzWtF2AnpK9RQ",
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }

This following example makes a request using a request parameter value requesting that specific Claims be returned in the ID Token. The sample Request Object used is described in Section 2.2.2.2 (Request Parameter Method).

Case 6: response_type=code id_token

  https://server.example.com/op/authorize?
    response_type=code%20id_token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid
    &request=eyJhbGciOiJSUzI1NiJ9.ew0KICJyZXNwb25zZV90eXBlIjogImNvZG
    UgaWRfdG9rZW4iLA0KICJjbGllbnRfaWQiOiAiczZCaGRSa3F0MyIsDQogInJlZG
    lyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQogIn
    Njb3BlIjogIm9wZW5pZCIsDQogInN0YXRlIjogImFmMGlmanNsZGtqIiwNCiAibm
    9uY2UiOiAibi0wUzZfV3pBMk1qIiwNCiAibWF4X2FnZSI6IDg2NDAwLA0KICJjbG
    FpbXMiOiANCiAgew0KICAgInVzZXJpbmZvIjogDQogICAgew0KICAgICAiZ2l2ZW
    5fbmFtZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJuaWNrbmFtZSI6IG
    51bGwsDQogICAgICJlbWFpbCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgIC
    JlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICJwaW
    N0dXJlIjogbnVsbA0KICAgIH0sDQogICAiaWRfdG9rZW4iOiANCiAgICB7DQogIC
    AgICJnZW5kZXIiOiBudWxsLA0KICAgICAiYmlydGhkYXRlIjogeyJlc3NlbnRpYW
    wiOiB0cnVlfSwNCiAgICAgImFjciI6IHsidmFsdWVzIjogWyIyIl19DQogICAgfQ
    0KICB9DQp9.bOD4rUiQfzh4QPIs_f_R2GVBhNHcc1p2cQTgixB1tsYRs52xW4TO7
    4USgb-nii3RPsLdfoPlsEbJLmtbxG8-TQBHqGAyZxMDPWy3phjeRt9ApDRnLQrjY
    uvsCj6byu9TVaKX9r1KDFGT-HLqUNlUTpYtCyM2B2rLkWM08ufBq9JBCEzzaLRzj
    evYEPMaoLAOjb8LPuYOYTBqshRMUxy4Z380-FJ2Lc7VSfSu6HcB2nLSjiKrrfI35
    xkRJsaSSmjasMYeDZarYCl7r4o17rFclk5KacYMYgAs-JYFkwab6Dd56ZrAzakHt
    9cExMpg04lQIux56C-Qk6dAsB6W6W91AQ
    &nonce=n-0S6_WzA2Mj
    &state=af0ifjsldkj

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &token_type=Bearer
    &id_token=eyJhbGciOiJSUzI1NiJ9.ew0KICJpc3MiOiAiaHR0cDovL3NlcnZlc
    i5leGFtcGxlLmNvbSIsDQogInN1YiI6ICIyNDgyODk3NjEwMDEiLA0KICJhdWQiO
    iAiczZCaGRSa3F0MyIsDQogIm5vbmNlIjogIm4tMFM2X1d6QTJNaiIsDQogImV4c
    CI6IDEzMTEyODE5NzAsDQogImlhdCI6IDEzMTEyODA5NzAsDQogImdlbmRlciI6I
    CJmZW1hbGUiLA0KICJiaXJ0aGRhdGUiOiAiMDAwMC0xMC0zMSIsDQogImFjciI6I
    CIyIiwNCiAiY19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEEiDQp9.d8vv
    NPuPR01zA_6RTArFMCtct1Oy6Q0gTCTXa9oDEuk7Sd3Hv0i34M6xFccrrbYtCzVn
    AjnJnJCgixJSlMsYJBTx168HgqdBcBwFLmd28i1Q_7cyfoglw4GkblXn7UxUgdAZ
    1ILyDAOV3dMS2ZxaCPK_HE2-_kzlIXtOamdWruHickUBA3_xlzMorMvbmHnU47qA
    u3AgCJF9RmKhgVY1cjUiHmEF8GBugxMn6eE7-ji6houeM-WL0nudHJEBikVmpnhQ
    ezFyj6tZhfeVcWoEsCwzbDts4pPQVcDHFq2dSnq1ZuhX1svDYnV-TRUW9ri7V9ik
    K7TBhtqtk7e5cIWSPw
    &state=af0ifjsldkj

Verifying and decoding the ID Token will yield the following Claims:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "gender": "female",
   "birthdate": "0000-10-31",
   "acr": "urn:mace:incommon:iap:silver",
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }

The following is the RSA public key in JWK format that can be used to validate the Request Object signature in the above examples (with line breaks for display purposes only):

  {
   "kty":"RSA",
   "n":"zhEWTBJVTfcUeqnMzOQFMCEVQWOyOUZwP8LrBWh88tKrZyPGCvBkT
  Dp-E2BzyHMQV4pK51Uys2YOwzL9se5THDWMda9rtsCJVcj1V7WaE7wPgl-kIIdWWf4o2g
  6ZszOy_Fp4q0nG3OTtDRCkBu2iEP21j82pRSRrkCBxnzaChflA7KZbI1n_yhKtxyA7FdA
  480LaSVZyKApvrKiYhocACSwf0y6CQ-wkEi6mVXRJt1aBSywlLYA08ojp5hkZQ39eCM2k
  1EdXdhbar998Q9PZTwXA1cfvuGTZbDWxEKLjMKVuKrT1Yvs-2NTXhZAW1KjFS_3UwLkDk
  -w4dVN-x5tDnw",
   "e":"AQAB"
  }


 TOC 

2.2.6.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 Authorization Error Response as defined in Section 2.1.3 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [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. Error code.
error_description
OPTIONAL. Human-readable ASCII encoded text description of the error.
error_uri
OPTIONAL. URI of a web page that includes additional information about the error.
state
OAuth 2.0 state value. 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 (with line wraps within the values for the display purposes only):

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


 TOC 

3.  Token Endpoint

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, per Section 7.2 (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 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].

The Token Endpoint MUST support the use of the HTTP POST method defined in RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] at the Token Endpoint.

Communication with the Token Endpoint MUST utilize TLS. See Section 9.2 (TLS Requirements) for more information on using TLS.

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



Header NameHeader Value
Cache-Control no-store
Pragma no-cache

 HTTP Response Headers and Values 



 TOC 

3.1.  Requesting Access Token

To retrieve an Access Token when using the Authorization Code Flow, a Client MUST have an Authorization Code obtained as described in Section 2.1.2 (Authorization Code Flow).



 TOC 

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 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages]. The Client sends the parameters via HTTPS POST to the Token Endpoint using Form Serialization, per Section 7.2 (Form Serialization), as described in Section 4.1.3 of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749].

The following is a non-normative example of an Access Token Request:

  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.example.org%2Fcb

The Authorization Server MUST:



 TOC 

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 Section 2.2.3 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [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": "eyJhbGciOiJSUzI1NiJ9.ew0KICAgICJpc3MiOiAiaHR0cDovL
     3NlcnZlci5leGFtcGxlLmNvbSIsDQogICAgInVzZXJfaWQiOiAiMjQ4Mjg5NzYxM
     DAxIiwNCiAgICAiYXVkIjogInM2QmhkUmtxdDMiLA0KICAgICJub25jZSI6ICJuL
     TBTNl9XekEyTWoiLA0KICAgICJleHAiOiAxMzExMjgxOTcwLA0KICAgICJpYXQiO
     iAxMzExMjgwOTcwDQp9.lsQI_KNHpl58YY24G9tUHXr3Yp7OKYnEaVpRL0KI4szT
     D6GXpZcgxIpkOCcajyDiIv62R9rBWASV191Akk1BM36gUMm8H5s8xyxNdRfBViCa
     xTqHA7X_vV3U-tSWl6McR5qaSJaNQBpg1oGPjZdPG7zWCG-yEJC4-Fbx2FPOS7-h
     5V0k33O5Okd-OoDUKoFPMd6ur5cIwsNyBazcsHdFHqWlCby5nl_HZdW-PHq0gjzy
     JydB5eYIvOfOHYBRVML9fKwdOLM2xVxJsPwvy3BqlVKc593p2WwItIg52ILWrc6A
     tqkqHxKsAXLVyAoVInYkl_NDBkCqYe2KgNJFzfEC8g"
  }


 TOC 

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 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [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"
  }


 TOC 

3.2.  Refreshing 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 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages]. The Client sends the parameters via HTTPS POST to the Token Endpoint using Form Serialization, per Section 7.2 (Form Serialization), as described in Section 6 of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]:

The Authorization Server MUST validate the Refresh Token.



 TOC 

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 validation 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 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages] except that it MUST NOT return an id_token.

Following is a non-normative example of a 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%20profile

  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
  }


 TOC 

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 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749].



 TOC 

4.  UserInfo Endpoint

The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. To obtain the requested Claims about the End-User, the Client makes a GET or POST request to the UserInfo Endpoint as in Section 2.3.1 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].

Communication with the UserInfo Endpoint MUST utilize TLS. See Section 9.2 (TLS Requirements) for more information on using TLS.

The UserInfo Endpoint MUST support the use of the HTTP GET and HTTP POST methods defined in RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] at the UserInfo Endpoint.

The UserInfo Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750].

The UserInfo Endpoint SHOULD support the use of Cross Origin Resource Sharing (CORS) (Opera Software ASA, “Cross-Origin Resource Sharing,” July 2010.) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint.



 TOC 

4.1.  UserInfo Request

Client SHOULD send the UserInfo Request defined in Section 2.3.1 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages] either in an HTTPS GET or HTTPS POST request.

The Access Token obtained from an OpenID Connect Authorization Request MUST be sent as a Bearer Token. Section 2 of the OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] specification documents the permissible methods of sending the Access Token.

It is RECOMMENDED that the Client use the Authorization header field method for all requests and that they use the GET method.

The following is a non-normative example of a UserInfo request:

  GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG


 TOC 

4.2.  UserInfo Response

The sub (subject) Claim in the UserInfo Endpoint response MUST exactly match the sub 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 Section 2.3.2 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages] in the HTTP response body unless a different format was specified during Registration [OpenID.Registration] (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2013.). The content-type of the HTTP response MUST be set to application/json if the response body is a text JSON structure; the response body SHOULD be encoded using UTF-8. If the JSON response is signed or 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.3 (UserInfo Response Validation) of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].

Following is a non-normative example of such response:

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

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


 TOC 

4.3.  UserInfo Error Response

When an error condition occurs, the UserInfo Endpoint returns an Error Response as defined in Section 3 of the OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] specification utilizing an error code as specified in Section 2.3.3 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [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"


 TOC 

5.  Self-Issued OpenID Provider

OpenID Connect supports Self-Issued OpenID Providers - personal OPs that issue self-signed ID Tokens. Self-Issued OPs use the special Issuer Identifier https://self-issued.me.

The messages used to communicate with Self-Issued OPs are mostly the same as those used to communicate with other OPs. Specifications for the few additional parameters used and for the values of some parameters in the Self-Issued case are described in Section 7 of the OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages] specification.



 TOC 

6.  Initiating Login at Client from Third Party

In some cases, the login flow may start at the Authorization Server or another party by contacting the Client via a stored link. The target resource at the Client may be a deep link, rather than a default landing page.

The Client may optionally register (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2013.) [OpenID.Registration] an initiate_login_uri that can be used by the Authorization Server or another party to initiate a login for an End-User at the Client.

The Authorization Server or a third party sends a Login Initiation Request to the Client Initiation URI with the following parameters:

login_hint
REQUIRED. Hint to the Authorization Server about the login identifier the End-User may use to log in (if necessary).
iss
REQUIRED. Issuer Identifier for the Issuer that the Client is to send the authentication request to. Its value MUST be a URL using the https scheme.
target_link_uri
OPTIONAL. URI that the Client is requested to redirect to after authentication. Clients MUST verify the value of the target_link_uri to prevent being used as an open redirector to external sites.

Other parameters MAY be sent, if defined by extensions. Any parameters used that are not understood MUST be ignored by the Client.

Clients SHOULD employ frame busting and other techniques to prevent users from being logged in by third party sites without their knowledge.



 TOC 

7.  Serializations

Messages are serialized using one of the following methods:

  1. Query String Serialization
  2. Form Serialization
  3. JSON Serialization

Not all methods can be used for all messages.



 TOC 

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] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.). 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.example.org%2Fcb HTTP/1.1
  Host: server.example.com


 TOC 

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] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.). 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.example.org%2Fcb


 TOC 

7.3.  JSON Serialization

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

Following is a non-normative example of such serialization:

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


 TOC 

8.  Implementation Considerations

This specification defines features used by both Relying Parties and OpenID Providers. Features that are mandatory to implement for Relying Parties are already described in the OpenID Connect Basic Client Profile 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” May 2013.) [OpenID.Basic] and OpenID Connect Implicit Client Profile 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Implicit Client Profile 1.0,” May 2013.) [OpenID.Implicit] specifications, and so are not discussed again here.

All OpenID Providers MUST implement the features that are already listed elsewhere in this specification as being "REQUIRED" or are described with a "MUST". Since this specification is a protocol binding for the OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages] specification, all the implementation considerations described in that specification also apply here.



 TOC 

8.1.  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 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” May 2013.) [OpenID.Discovery] and OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2013.) [OpenID.Registration] specifications.



 TOC 

9.  Security Considerations

This specification references the security considerations defined in OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) [OpenID.Messages].

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



 TOC 

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



 TOC 

9.2.  TLS Requirements

Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) is the most widely deployed version, and will give the broadest interoperability.

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

Whenever TLS is used, a TLS server certificate check MUST be performed, per RFC 6125 (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),” March 2011.) [RFC6125].



 TOC 

10.  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 sub (subject) SHOULD be considered.



 TOC 

11.  IANA Considerations

This document makes no requests of IANA.



 TOC 

12.  References



 TOC 

12.1. Normative References

[JWE] Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” draft-ietf-jose-json-web-encryption (work in progress), April 2013 (HTML).
[JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” draft-ietf-jose-json-web-signature (work in progress), April 2013 (HTML).
[JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” draft-ietf-oauth-json-web-token (work in progress), April 2013 (HTML).
[OAuth.Responses] de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” November 2012.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” May 2013.
[OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2013.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT).
[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).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
[RFC5646] Phillips, A. and M. Davis, “Tags for Identifying Languages,” BCP 47, RFC 5646, September 2009 (TXT).
[RFC6125] Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” RFC 6125, March 2011 (TXT).
[RFC6749] Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).
[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT).
[W3C.REC-html401-19991224] Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).


 TOC 

12.2. Informative References

[CORS] Opera Software ASA, “Cross-Origin Resource Sharing,” July 2010.
[OpenID.Basic] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” May 2013.
[OpenID.Implicit] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Implicit Client Profile 1.0,” May 2013.


 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.

Naveen Agarwal (naa@google.com), Google

John Bradley (ve7jtb@ve7jtb.com), Ping Identity

Tim Bray (tbray@textuality.com), Google

Breno de Medeiros (breno@gmail.com), Google

George Fletcher (gffletch@aol.com), AOL

Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.

Michael B. Jones (mbj@microsoft.com), Microsoft

Hideki Nara (hideki.nara@gmail.com), Takt Communications

Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom

Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.



 TOC 

Appendix B.  Notices

Copyright (c) 2013 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.



 TOC 

Appendix C.  Document History

[[ To be removed from the final specification ]]

-19

-18

-17

-16

-15

-14

-13

-12

-11

-10

-09

-08

-07

-06

-05

-04

-03

-02

-01



 TOC 

Authors' Addresses

  Nat Sakimura
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Ping Identity
Email:  ve7jtb@ve7jtb.com
  
  Michael B. Jones
  Microsoft
Email:  mbj@microsoft.com
  
  Breno de Medeiros
  Google
Email:  breno@google.com
  
  Edmund Jay
  Illumila
Email:  ejay@mgi1.com