OpenID Connect Standard 1.0 - draft 16

Abstract

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

OpenID Connect Standard 1.0 is an HTTP protocol binding for 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.  OpenID Connect Scope Values
    2.2.  Protocol Flows
        2.2.1.  How to Get Authorization Code, Access Token, and ID Token
        2.2.2.  Authorization Code Flow
        2.2.3.  Implicit Flow
    2.3.  Authorization Request
        2.3.1.  Client Prepares Authorization Request
            2.3.1.1.  Simple Request Method
                2.3.1.1.1.  Client Sends Request to Authorization Server
            2.3.1.2.  Request Parameter Method
                2.3.1.2.1.  Client Sends Request to Authorization Server
            2.3.1.3.  Request File Method
                2.3.1.3.1.  Client Generates the URL of the Request File
                2.3.1.3.2.  Client Sends Request to Authorization Server via HTTPS Redirect
                2.3.1.3.3.  Authorization Server Fetches Request File
        2.3.2.  Authorization Server Validates Request Object
        2.3.3.  Authorization Server Authenticates End-User
        2.3.4.  Authorization Server Obtains End-User Consent/Authorization
        2.3.5.  Authorization Server Sends End-User Back to Client
            2.3.5.1.  End-User Grants Authorization
            2.3.5.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
    5.1.  Self-Issued OpenID Provider Discovery
    5.2.  Client Registration to Self-Issued OpenID Provider
    5.3.  Self-Issued OpenID Provider Request
    5.4.  Self-Issued OpenID Provider Response
    5.5.  Self-Issued ID Token Validation
6.  Initiating Login at Client from Third Party
7.  Serializations
    7.1.  Query String Serialization
    7.2.  Form Serialization
8.  Implementation Considerations
    8.1.  Discovery and Registration
9.  Security Considerations
    9.1.  Implicit Grant Flow Threats
10.  Privacy Considerations
11.  IANA Considerations
    11.1.  OAuth Parameters Registry
        11.1.1.  Registry Contents
12.  References
    12.1.  Normative References
    12.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
§  Authors' Addresses

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,” January 2013.) [OpenID.Messages].

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.

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,” January 2013.) [OpenID.Messages]. This specification also defines the following terms:

Request File

Document whose contents is an OpenID 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.

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 using the response_type parameter in the Authorization Request.

2.1.  OpenID Connect Scope Values

Clients MUST specify the desired scopes in an Authorization Request to obtain an Access Token with the proper permissions. The scope names used by OpenID Connect are defined 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,” January 2013.) [OpenID.Messages].

The Authorization Server MAY fully or partially ignore the scope values requested by the Client based on the Authorization Server policy or the End-User's instructions. A Client may elect to only request a subset of the information available from the UserInfo Endpoint.

The following is a non-normative example of a scope parameter in an Authorization Request:

  scope=openid profile email phone

2.2.  Protocol Flows

Authorization Requests follow two main paths to obtain Access Tokens and ID Tokens, the Implicit Flow and the Authorization Code Flow. The flows determine how the Access Token and ID Token are returned to the Client. Access Tokens are credentials used to access Protected Resources, as defined in Section 1.4 of OAuth 2.0 (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.

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

In this specification, the Client sends authorization request to the Authorization Endpoint through the User Agent to obtain the Access Token and ID Token. It MAY obtain them from the Authorization Endpoint or from Token Endpoint utilizing the code that it obtained from the Authorization Endpoint. The latter is called Code Flow (Authorization Code Flow) and the former is called Implicit Flow (Implicit Flow).

2.2.2.  Authorization Code Flow

The Authorization Code Flow goes through the following steps.

1. Client prepares an Authorization Request containing the desired request parameters.
2. Client sends a request to the Authorization Server.
3. Authorization Server Authenticates the End-User.
4. Authorization Server Obtains the End-User Consent/Authorization.
5. Authorization Server Sends the End-User back to the Client with an Authorization Code.
6. Client requests a response using the Authorization Code at the Token Endpoint (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 (UserInfo Endpoint) with the Access Token.
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,” January 2013.) [OpenID.Messages].

2.2.3.  Implicit Flow

The Implicit Flow follows the following steps:

1. Client prepares an Authorization Request containing the desired request parameters.
2. Client sends a request to the Authorization Server.
3. Authorization Server Authenticates the End-User.
4. Authorization Server Obtains the End-User Consent/Authorization.
5. Authorization Server Sends the End-User back to the Client with an Access Token and an ID Token if requested.
6. Client validates the ID Token and retrieves the End-User's subject identifier.
7. (OPTIONAL) Client accesses the UserInfo Endpoint (UserInfo Endpoint) with the Access Token.
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,” January 2013.) [OpenID.Messages].

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

Authorization Servers MUST require the use of a transport-layer security mechanism at the Authorization Endpoint. The Authorization Server MUST support TLS 1.2 RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] and/or TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) and MAY support other transport-layer mechanisms with equivalent security.

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" method to send the Authorization Request to the Authorization Server. If using the HTTP "GET" method, the request parameters are serialized using URI query string serialization (Query String Serialization). If using the HTTP "POST" method, the request parameters are serialized using form serialization (Form Serialization).

2.3.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. The Client MUST perform a TLS/SSL server certificate check, 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].

The required Authorization Request parameters are as follows:

response_type

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:

• code
• code id_token
• id_token
• token
• token id_token
• code token
• code token id_token

client_id

OAuth 2.0 Client identifier.

scope

OAuth 2.0 scope value. It MUST include openid as one of the space delimited ASCII strings. OPTIONAL scope values of profile, email, address, phone, and offline_access are also defined.

redirect_uri

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,” January 2013.) [OpenID.Registration] specification.

The request MAY contain the following OPTIONAL and sometimes REQUIRED parameters:

nonce

String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authorization Request to the ID Token. Use of the nonce is REQUIRED when using the implicit flow and OPTIONAL when using the code flow.

state

Opaque value used to maintain state between the request and the callback.

request

OpenID Request Object value.

request_uri

URL that references an OpenID Request Object.

display

ASCII string value that specifies how the Authorization Server displays the authentication page to the End-User. Refer to 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,” January 2013.) [OpenID.Messages] for more information.

prompt

Space delimited list of ASCII strings that can contain the values login, consent, select_account, and none. 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,” January 2013.) [OpenID.Messages] for more information.

id_token_hint

ID Token passed to the Authorization server as a hint. 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,” January 2013.) [OpenID.Messages] for more information.

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

a.

Simple Request Method

b.

Request Parameter Method

c.

Request File Method

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

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

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

2.3.1.1.  Simple Request Method

The Client prepares an Authorization Request to the Authorization Endpoint using the appropriate parameters. If using the HTTP "GET" method, the request parameters are serialized using URI query string serialization (Query String Serialization). If using the HTTP "POST" method, the request parameters are serialized using form serialization (Form Serialization).

The following is a non-normative example of an Authorization Request URL (with line wraps 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

2.3.1.1.1.  Client Sends Request to Authorization Server

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

Following is a non-normative example using HTTP redirect (with line wraps 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

2.3.1.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.3.1 (Client Prepares Authorization Request). The Authorization Request MUST NOT include the request_uri parameter.

The request parameter is an OpenID Request Object that contains the Authorization Request and also specifies the contents of the responses to be returned from the UserInfo Endpoint. The OpenID Request Object MAY be signed or signed and encrypted via JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012.) [JWS] and JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2012.) [JWE] respectively, thereby providing authentication, integrity, non-repudiation and/or confidentiality.

The following is a non-normative example of an OpenID Request Object before base64url encoding and signing:

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

The following is a non-normative example of an OpenID Request Object before base64url encoding and signing (with line wraps within the values for display purposes only):

  Algorithm = RS256

  JSON Encoded Header = {"alg":"RS256"}
  JSON Encoded Payload =
    {
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "scope": "openid profile",
      "state": "af0ifjsldkj",
      "nonce": "n-0S6_WzA2Mj",
      "userinfo":
        {
          "claims":
            {
              "name": {"essential": true},
              "nickname": null,
              "email": {"essential": true},
              "email_verified": {"essential": true},
              "picture": null
            }
        },
        "id_token":
          {
            "max_age": 86400,
            "claims":
              {
                "gender": null,
                "birthdate": {"essential": true},
                "acr": {"values": ["2"]}
              }
          }
    }

  OpenID Request Object =
    eyJhbGciOiJSUzI1NiJ9.ew0KICAicmVzcG9uc2VfdHlwZSI6ICJjb2RlIGlkX3Rv
    a2VuIiwNCiAgImNsaWVudF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAgInJlZGlyZWN0X
    3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQogICJzY29wZS
    I6ICJvcGVuaWQgcHJvZmlsZSIsDQogICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsDQo
    gICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICAidXNlcmluZm8iOiANCiAgICB7
    DQogICAgICAiY2xhaW1zIjogDQogICAgICAgIHsNCiAgICAgICAgICAibmFtZSI6I
    HsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICAgICAgIm5pY2tuYW1lIjogbnVsbC
    wNCiAgICAgICAgICAiZW1haWwiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICA
    gICAgICJlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAg
    ICAgICAgInBpY3R1cmUiOiBudWxsDQogICAgICAgIH0NCiAgICB9LA0KICAgICJpZ
    F90b2tlbiI6IA0KICAgICAgew0KICAgICAgICAibWF4X2FnZSI6IDg2NDAwLA0KIC
    AgICAgICAiY2xhaW1zIjogDQogICAgICAgICAgew0KICAgICAgICAgICAgImdlbmR
    lciI6IG51bGwsDQogICAgICAgICAgICAiYmlydGhkYXRlIjogeyJlc3NlbnRpYWwi
    OiB0cnVlfSwNCiAgICAgICAgICAgICJhY3IiOiB7InZhbHVlcyI6IFsiMiJdfQ0KI
    CAgICAgICAgIH0NCiAgICAgIH0NCn0.QO_PD7FOnOaDULViVR-a4RmgyZA-wz1p4a
    KiD8ucktrF2o62PmntJC6vR1Ne_rWXZaybM4ZFN_HzFmakwYMqrp-HBfcegj5-ifv
    wSOAo-EfQrr88Jd40rrnH-KdkjQQiu5BiE513o4XK-1p7lG8RmbQc3EJwJTimNC4E
    ijk1wp2D99IndyH9CrOp_M5X15iQjGGF65IWb-9ly1waEiJMFrO2BuDTKpImcjKe9
    odgtWRyZWs8KhfVwLVkrazhf8E08TEqK8Vuohg8FoCLLaw66IN4EVBMcEnncNyHId
    77ZeVOB-KGHJdIo75W7pc68GUc5dg1NXpBF2UqtHmoXVGisQ

  The following is the RSA public key information that can be used to
  validate the OpenID Request Object signature in the above example.
  The values are an array of hexadecimal digits in big endian format.

  modulus:
  [
    cb,d2,ea,bf,87,c2,a7,a1,22,fa,ed,be,64,22,aa,f3,
    76,2f,6c,51,24,e8,93,2c,fe,94,a3,ef,a7,8c,91,d7,
    56,46,e5,97,d9,a0,4a,18,70,2d,2a,51,39,3f,bf,ef,
    9f,ff,cf,08,a6,56,78,fb,77,bc,69,01,e9,e3,e0,cc,
    01,6e,d3,c3,66,29,e9,b0,13,96,d0,23,47,ba,90,80,
    a1,b6,df,fa,2b,34,f9,39,a6,97,0c,52,3a,a8,22,c9,
    9a,4e,75,09,ce,15,60,56,b1,82,a7,af,32,77,18,af,
    36,96,ff,9d,26,67,5c,86,48,52,10,cc,b6,0f,f1,b8,
    a3,00,71,95,8d,d1,05,81,96,99,10,df,65,b2,7f,c6,
    75,62,da,26,91,eb,07,74,4e,95,2e,74,13,8e,70,c6,
    b9,60,f7,13,27,71,56,fc,a8,33,ee,5d,96,ab,be,08,
    4b,2f,41,f3,3a,e6,11,69,d0,49,56,85,99,a3,00,cd,
    4e,92,a9,93,64,64,95,9e,d0,68,13,bb,5c,3b,f7,b9,
    1e,ec,fe,c7,f6,83,e6,c0,8d,26,31,61,41,ac,aa,43,
    40,f5,bd,f1,55,6e,77,6a,6f,d4,65,9d,ed,65,b1,53,
    22,1e,79,ec,92,02,58,a1,e5,5a,3e,6e,cd,e2,57,6b
  ]

  exponent: [01,00,01]

The following is a non-normative example of an Authorization Request with the OpenID Request Method (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.ew0KICAicmVzcG9uc2VfdHlwZSI6ICJjb2
    RlIGlkX3Rva2VuIiwNCiAgImNsaWVudF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAgIn
    JlZGlyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQ
    ogICJzY29wZSI6ICJvcGVuaWQgcHJvZmlsZSIsDQogICJzdGF0ZSI6ICJhZjBpZm
    pzbGRraiIsDQogICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICAidXNlcmluZm
    8iOiANCiAgICB7DQogICAgICAiY2xhaW1zIjogDQogICAgICAgIHsNCiAgICAgIC
    AgICAibmFtZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICAgICAgIm5pY2
    tuYW1lIjogbnVsbCwNCiAgICAgICAgICAiZW1haWwiOiB7ImVzc2VudGlhbCI6IH
    RydWV9LA0KICAgICAgICAgICJlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIj
    ogdHJ1ZX0sDQogICAgICAgICAgInBpY3R1cmUiOiBudWxsDQogICAgICAgIH0NCi
    AgICB9LA0KICAgICJpZF90b2tlbiI6IA0KICAgICAgew0KICAgICAgICAibWF4X2
    FnZSI6IDg2NDAwLA0KICAgICAgICAiY2xhaW1zIjogDQogICAgICAgICAgew0KIC
    AgICAgICAgICAgImdlbmRlciI6IG51bGwsDQogICAgICAgICAgICAiYmlydGhkYX
    RlIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgICAgICAgICJhY3IiOiB7In
    ZhbHVlcyI6IFsiMiJdfQ0KICAgICAgICAgIH0NCiAgICAgIH0NCn0.QO_PD7FOnO
    aDULViVR-a4RmgyZA-wz1p4aKiD8ucktrF2o62PmntJC6vR1Ne_rWXZaybM4ZFN_
    HzFmakwYMqrp-HBfcegj5-ifvwSOAo-EfQrr88Jd40rrnH-KdkjQQiu5BiE513o4
    XK-1p7lG8RmbQc3EJwJTimNC4Eijk1wp2D99IndyH9CrOp_M5X15iQjGGF65IWb-
    9ly1waEiJMFrO2BuDTKpImcjKe9odgtWRyZWs8KhfVwLVkrazhf8E08TEqK8Vuoh
    g8FoCLLaw66IN4EVBMcEnncNyHId77ZeVOB-KGHJdIo75W7pc68GUc5dg1NXpBF2
    UqtHmoXVGisQ

2.3.1.2.1.  Client Sends Request to Authorization Server

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

Following is a non-normative example using HTTP redirect (with line wraps 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.ew0KICAicmVzcG9uc2VfdHlwZSI6ICJjb2
    RlIGlkX3Rva2VuIiwNCiAgImNsaWVudF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAgIn
    JlZGlyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQ
    ogICJzY29wZSI6ICJvcGVuaWQgcHJvZmlsZSIsDQogICJzdGF0ZSI6ICJhZjBpZm
    pzbGRraiIsDQogICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICAidXNlcmluZm
    8iOiANCiAgICB7DQogICAgICAiY2xhaW1zIjogDQogICAgICAgIHsNCiAgICAgIC
    AgICAibmFtZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICAgICAgIm5pY2
    tuYW1lIjogbnVsbCwNCiAgICAgICAgICAiZW1haWwiOiB7ImVzc2VudGlhbCI6IH
    RydWV9LA0KICAgICAgICAgICJlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIj
    ogdHJ1ZX0sDQogICAgICAgICAgInBpY3R1cmUiOiBudWxsDQogICAgICAgIH0NCi
    AgICB9LA0KICAgICJpZF90b2tlbiI6IA0KICAgICAgew0KICAgICAgICAibWF4X2
    FnZSI6IDg2NDAwLA0KICAgICAgICAiY2xhaW1zIjogDQogICAgICAgICAgew0KIC
    AgICAgICAgICAgImdlbmRlciI6IG51bGwsDQogICAgICAgICAgICAiYmlydGhkYX
    RlIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgICAgICAgICJhY3IiOiB7In
    ZhbHVlcyI6IFsiMiJdfQ0KICAgICAgICAgIH0NCiAgICAgIH0NCn0.QO_PD7FOnO
    aDULViVR-a4RmgyZA-wz1p4aKiD8ucktrF2o62PmntJC6vR1Ne_rWXZaybM4ZFN_
    HzFmakwYMqrp-HBfcegj5-ifvwSOAo-EfQrr88Jd40rrnH-KdkjQQiu5BiE513o4
    XK-1p7lG8RmbQc3EJwJTimNC4Eijk1wp2D99IndyH9CrOp_M5X15iQjGGF65IWb-
    9ly1waEiJMFrO2BuDTKpImcjKe9odgtWRyZWs8KhfVwLVkrazhf8E08TEqK8Vuoh
    g8FoCLLaw66IN4EVBMcEnncNyHId77ZeVOB-KGHJdIo75W7pc68GUc5dg1NXpBF2
    UqtHmoXVGisQ

2.3.1.3.  Request File Method

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

The Client prepares an Authorization Request using the desired HTTP "GET" or "POST" method. The Client SHOULD use the HTTP "GET" method, but MAY use the HTTP "POST" method. The scheme used in the Authorization URL MUST be HTTPS. The Client MUST perform a TLS/SSL server certificate check, per RFC 6125 (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].

The Authorization Request MUST NOT include the request parameter. The Authorization Request MUST include the request_uri parameter. The contents of the target of the URL must be an OpenID Request Object. The scheme used in the request_uri value MUST be HTTPS, unless the target OpenID 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 a Request File (with line wraps for display purposes only):

  eyJhbGciOiJSUzI1NiJ9.ew0KICAicmVzcG9uc2VfdHlwZSI6ICJjb2RlIGlkX3R
  va2VuIiwNCiAgImNsaWVudF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAgInJlZGlyZWN
  0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQogICJzY29
  wZSI6ICJvcGVuaWQgcHJvZmlsZSIsDQogICJzdGF0ZSI6ICJhZjBpZmpzbGRraiI
  sDQogICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICAidXNlcmluZm8iOiANCiA
  gICB7DQogICAgICAiY2xhaW1zIjogDQogICAgICAgIHsNCiAgICAgICAgICAibmF
  tZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICAgICAgIm5pY2tuYW1lIjo
  gbnVsbCwNCiAgICAgICAgICAiZW1haWwiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0
  KICAgICAgICAgICJlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0
  sDQogICAgICAgICAgInBpY3R1cmUiOiBudWxsDQogICAgICAgIH0NCiAgICB9LA0
  KICAgICJpZF90b2tlbiI6IA0KICAgICAgew0KICAgICAgICAibWF4X2FnZSI6IDg
  2NDAwLA0KICAgICAgICAiY2xhaW1zIjogDQogICAgICAgICAgew0KICAgICAgICA
  gICAgImdlbmRlciI6IG51bGwsDQogICAgICAgICAgICAiYmlydGhkYXRlIjogeyJ
  lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgICAgICAgICJhY3IiOiB7InZhbHVlcyI
  6IFsiMiJdfQ0KICAgICAgICAgIH0NCiAgICAgIH0NCn0.QO_PD7FOnOaDULViVR-
  a4RmgyZA-wz1p4aKiD8ucktrF2o62PmntJC6vR1Ne_rWXZaybM4ZFN_HzFmakwYM
  qrp-HBfcegj5-ifvwSOAo-EfQrr88Jd40rrnH-KdkjQQiu5BiE513o4XK-1p7lG8
  RmbQc3EJwJTimNC4Eijk1wp2D99IndyH9CrOp_M5X15iQjGGF65IWb-9ly1waEiJ
  MFrO2BuDTKpImcjKe9odgtWRyZWs8KhfVwLVkrazhf8E08TEqK8Vuohg8FoCLLaw
  66IN4EVBMcEnncNyHId77ZeVOB-KGHJdIo75W7pc68GUc5dg1NXpBF2UqtHmoXVG
  isQ

2.3.1.3.1.  Client Generates the URL of the Request File

The Client then stores the Request File either locally or remotely. This is the Request URI, "request_uri". The URI MAY be appended with the base64url encoded SHA-256 hash of the file after "#" so that the Authorization Server can detect whether the file has changed.

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
    #V4pDyha4i12w7CrRxcSh9_GK562EW2y8MzxEGhXfdpk

2.3.1.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 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
    %23V4pDyha4i12w7CrRxcSh9_GK562EW2y8MzxEGhXfdpk
    &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj&scope=openid

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

2.3.2.  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,” January 2013.) [OpenID.Messages].

2.3.3.  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 End-User is not already authenticated by the Authorization Server.
• The Authorization Request contains the prompt parameter with the value login. The Authorization Server MUST reauthenticate the End-User even if the End-User is already authenticated.

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

• The Authorization Request contains the "prompt" parameter with the value none. The Authorization Server MUST return an error if the End-User is unauthenticated.

2.3.4.  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 End-User has not pre-authorized the Client for the authorization request.
• The Authorization Request contains the prompt parameter with the value consent. The Authorization Server MUST request End-User authorization even if the End-User has previously authorized the Client.

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

• The Authorization Request contains the "prompt" parameter with the value none. The Authorization Server MUST return an error if the End-User has not pre-authorized the Client.

2.3.5.  Authorization Server Sends End-User Back to Client

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

2.3.5.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.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,” January 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 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.ew0KICAgICJpc3MiOiAiaHR0cDovL3Nlc
    nZlci5leGFtcGxlLmNvbSIsDQogICAgInVzZXJfaWQiOiAiMjQ4Mjg5NzYxMDAxI
    iwNCiAgICAiYXVkIjogInM2QmhkUmtxdDMiLA0KICAgICJub25jZSI6ICJuLTBTN
    l9XekEyTWoiLA0KICAgICJleHAiOiAxMzExMjgxOTcwLA0KICAgICJpYXQiOiAxM
    zExMjgwOTcwLA0KICAgICJhdF9oYXNoIjogIjc3UW1VUHRqUGZ6V3RGMkFucEs5U
    ldwWHJXbHJlY2RiTFV5SkRJYjdTNlEiDQp9.ZP0kFjn7ZOYwga5dbfvvYLlu7DAa
    RRhgE7u88OEfRqmfWCB35mwSso1A255fbvdOPryGda3xy0t2P1gjNxc2cKA8T9Rm
    w0ae6UyLSaA9zROXfpdyRX6wEs_RMdnftBY60B_DCeFJkWQxUG6taXomiVH7Ozyk
    765VX3gRzSoxaJKbD1xo582s0dGmMvkUL4dg7-46eOrOLkQTujUAOnjqCfiqzL1C
    rchYsNZjwNBE8pySRhJTmedm882k0NRZPU1QMLJIVpB9e0Hiuwz1htHm3-XxZ63b
    bzRLG6jsWknphWIFraFrf59Kgmct7jfzBF5IOvfpcdFe9kHVkKX_acts-w

  Verifying and decoding the ID Token will yield the following
  ID Token JSON object:

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

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.ew0KICAgICJpc3MiOiAiaHR0cDovL3Nlc
    nZlci5leGFtcGxlLmNvbSIsDQogICAgInVzZXJfaWQiOiAiMjQ4Mjg5NzYxMDAxI
    iwNCiAgICAiYXVkIjogInM2QmhkUmtxdDMiLA0KICAgICJub25jZSI6ICJuLTBTN
    l9XekEyTWoiLA0KICAgICJleHAiOiAxMzExMjgxOTcwLA0KICAgICJpYXQiOiAxM
    zExMjgwOTcwLA0KICAgICJjX2hhc2giOiAiTERrdEtkb1FhazNQazBjblh4Q2x0Q
    mdfckNfM1RLVWI5T0xrNWZLTzl1QSINCn0.D6JxCgpOwlyuK7DPRu5hFOIJRSRDT
    B7TQNRbOw9Vg9WroDi_XNzaqXCFSDH_YqcE-CBhoxD-Iq4eQL4E2jIjil47u7i68
    Nheev7d8AJk4wfRimgpDhQX5K8YyGDWrTs7bhsMTPAPVa9bLIBndDZ2mEdmPcmR9
    mXcwJI3IGF9JOaStYXJXMYWUMCmQARZEKG9JxIYPZNhFsqKe4TYQEmrq2s_HHQwk
    XCGAmLBdptHY-Zx277qtidojQQFXzbD2Ak1ONT5sFjy3yxPnE87pNVtOEST5GJac
    O1O88gmvmjNayu1-f5mr5Uc70QC6DjlKem3cUN5kudAQ4sLvFkUr8gkIQ

  Verifying and decoding the ID Token will yield the following
  ID Token JSON object:

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

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.ew0KICAgICJpc3MiOiAiaHR0cDovL3Nlc
    nZlci5leGFtcGxlLmNvbSIsDQogICAgInVzZXJfaWQiOiAiMjQ4Mjg5NzYxMDAxI
    iwNCiAgICAiYXVkIjogInM2QmhkUmtxdDMiLA0KICAgICJub25jZSI6ICJuLTBTN
    l9XekEyTWoiLA0KICAgICJleHAiOiAxMzExMjgxOTcwLA0KICAgICJpYXQiOiAxM
    zExMjgwOTcwLA0KICAgICJhdF9oYXNoIjogIjc3UW1VUHRqUGZ6V3RGMkFucEs5U
    ldwWHJXbHJlY2RiTFV5SkRJYjdTNlEiDQogICAgImNfaGFzaCI6ICJMRGt0S2RvU
    WFrM1BrMGNuWHhDbHRCZ19yQ18zVEtVYjlPTGs1ZktPOXVBIg0KfQ.Jw-8W1LKps
    Go17BltEpLlq1AMhSw3IRBeZrS-P3cXrDebBn09G4DWnjhD2PPze_M3ldkqng3Xk
    0me_xWlg3VoJlveJ64lQ2oPe_8_0rT1sLM6UOy8-gPtwifxUfvrkpNX9KwqTju6W
    MfSlDWWxW8Y8GQBMWsG7xqjYANIr84bpQ-5KyHnDdYSEDf9Si7xa3uYsJVrv1M1o
    jF2tz_sNirH8aCmU1KpJ6nXPLw2uEo5slKp-b0-1AWoBcl0PSJpDJJCdTaXF_e_g
    Ovd5ko9ymTZ336ZQj630QjtGZ9E4b9C_HOnI15zXQ5mh6cb2VO2r5ckDtqBy0UL-
    QklkW8BfO9qg
    &state=af0ifjsldkj

  Verifying and decoding the ID Token will yield the following
  ID Token JSON object:

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

This following example makes a request with an OpenID Request Object containing custom ID Token return Claims. The sample OpenID Request Object is described in the Request Parameter Section (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.ew0KICAicmVzcG9uc2VfdHlwZSI6ICJjb2
    RlIGlkX3Rva2VuIiwNCiAgImNsaWVudF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAgIn
    JlZGlyZWN0X3VyaSI6ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsDQ
    ogICJzY29wZSI6ICJvcGVuaWQgcHJvZmlsZSIsDQogICJzdGF0ZSI6ICJhZjBpZm
    pzbGRraiIsDQogICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICAidXNlcmluZm
    8iOiANCiAgICB7DQogICAgICAiY2xhaW1zIjogDQogICAgICAgIHsNCiAgICAgIC
    AgICAibmFtZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICAgICAgIm5pY2
    tuYW1lIjogbnVsbCwNCiAgICAgICAgICAiZW1haWwiOiB7ImVzc2VudGlhbCI6IH
    RydWV9LA0KICAgICAgICAgICJlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIj
    ogdHJ1ZX0sDQogICAgICAgICAgInBpY3R1cmUiOiBudWxsDQogICAgICAgIH0NCi
    AgICB9LA0KICAgICJpZF90b2tlbiI6IA0KICAgICAgew0KICAgICAgICAibWF4X2
    FnZSI6IDg2NDAwLA0KICAgICAgICAiY2xhaW1zIjogDQogICAgICAgICAgew0KIC
    AgICAgICAgICAgImdlbmRlciI6IG51bGwsDQogICAgICAgICAgICAiYmlydGhkYX
    RlIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgICAgICAgICJhY3IiOiB7In
    ZhbHVlcyI6IFsiMiJdfQ0KICAgICAgICAgIH0NCiAgICAgIH0NCn0.QO_PD7FOnO
    aDULViVR-a4RmgyZA-wz1p4aKiD8ucktrF2o62PmntJC6vR1Ne_rWXZaybM4ZFN_
    HzFmakwYMqrp-HBfcegj5-ifvwSOAo-EfQrr88Jd40rrnH-KdkjQQiu5BiE513o4
    XK-1p7lG8RmbQc3EJwJTimNC4Eijk1wp2D99IndyH9CrOp_M5X15iQjGGF65IWb-
    9ly1waEiJMFrO2BuDTKpImcjKe9odgtWRyZWs8KhfVwLVkrazhf8E08TEqK8Vuoh
    g8FoCLLaw66IN4EVBMcEnncNyHId77ZeVOB-KGHJdIo75W7pc68GUc5dg1NXpBF2
    UqtHmoXVGisQ
    &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.ew0KICAgICJpc3MiOiAiaHR0cDovL3Nlc
    nZlci5leGFtcGxlLmNvbSIsDQogICAgInVzZXJfaWQiOiAiMjQ4Mjg5NzYxMDAxI
    iwNCiAgICAiYXVkIjogInM2QmhkUmtxdDMiLA0KICAgICJub25jZSI6ICJuLTBTN
    l9XekEyTWoiLA0KICAgICJleHAiOiAxMzExMjgxOTcwLA0KICAgICJpYXQiOiAxM
    zExMjgwOTcwLA0KICAgICJnZW5kZXIiOiAiZmVtYWxlIiwNCiAgICAiYmlydGhkY
    XRlIjogIjE5ODctMDEtMDEiLA0KICAgICJhY3IiOiAiMiIsDQogICAgImNfaGFza
    CI6ICJMRGt0S2RvUWFrM1BrMGNuWHhDbHRCZ19yQ18zVEtVYjlPTGs1ZktPOXVBI
    g0KfQ.zMHXQpGOkWyzZexs490gN4bx16lzSJcL_F_hRq1afrtwgEUX4X976wHv6T
    WmoYBEsO14DLxNqsuMi-FCISbzCbOOQwyh9OjbojZlHuwc9lZhRUREiBTT00vIYF
    AT7g4caDuSlWvUZL-K0pCpAtSdqFF7TeOmv1UFcGXSXrw6g9v-WjY6WlkDF8pl37
    ubHIGNnOJnxwq-zOTic1KTpqRHWnLdrEoaEA4eIMTotBg7HfcoooeCqMVdrDVvwu
    1hFLxpWtztRiAynT4M8Q4BZeMlFyyFV0sf3nu8ShB7617CtJHSSPryfrm1IvLpFC
    28V9c5LcaVekf9sQLcDUmdfxJ4DA
    &state=af0ifjsldkj

  Verifying and decoding the ID Token will yield the following
  ID Token JSON object:

  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "gender": "female",
   "birthdate": "1987-01-01",
   "acr": "2",
   "c_hash": "LDktKdoQak3Pk0cnXxCltBg_rC_3TKUb9OLk5fKO9uA"
  }

Public Key Information used to verify the ID Token

  The following is the RSA public key information that can be used to
  validate the ID Token signatures in the above examples.
  The values are an array of hexadecimal digits in big endian format.

  modulus:
  [
   ce,11,16,4c,12,55,4d,f7,14,7a,a9,cc,cc,e4,05,30,
   21,15,41,63,b2,39,46,70,3f,c2,eb,05,68,7c,f2,d2,
   ab,67,23,c6,0a,f0,64,4c,3a,7e,13,60,73,c8,73,10,
   57,8a,4a,e7,55,32,b3,66,0e,c3,32,fd,b1,ee,53,1c,
   35,8c,75,af,6b,b6,c0,89,55,c8,f5,57,b5,9a,13,bc,
   0f,82,5f,a4,20,87,56,59,fe,28,da,0e,99,b3,33,b2,
   fc,5a,78,ab,49,c6,dc,e4,ed,0d,10,a4,06,ed,a2,10,
   fd,b5,8f,cd,a9,45,24,6b,90,20,71,9f,36,82,85,f9,
   40,ec,a6,5b,23,59,ff,ca,12,ad,c7,20,3b,15,d0,38,
   f3,42,da,49,56,72,28,0a,6f,ac,a8,98,86,87,00,09,
   2c,1f,d3,2e,82,43,ec,24,12,2e,a6,55,74,49,b7,56,
   81,4b,2c,25,2d,80,34,f2,88,e9,e6,19,19,43,7f,5e,
   08,cd,a4,d4,47,57,76,16,da,af,df,7c,43,d3,d9,4f,
   05,c0,d5,c7,ef,b8,64,d9,6c,35,b1,10,a2,e3,30,a5,
   6e,2a,b4,f5,62,fb,3e,d8,d4,d7,85,90,16,d4,a8,c5,
   4b,fd,d4,c0,b9,03,93,ec,38,75,53,7e,c7,9b,43,9f
  ]

  exponent: [01,00,01]

2.3.5.2.  End-User Denies Authorization or Invalid Request

If the End-User denies the authorization or the user authentication fails, the Authorization Server MUST return the error authorization response as defined in Section 2.1.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,” January 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 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

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 (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,” January 2013.) [OpenID.Messages].

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

Authorization Servers MUST require the use of a transport-layer security mechanism. The Authorization Server MUST support TLS 1.2 RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] and/or TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) and MAY support other transport-layer mechanisms with equivalent security.

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

3.1.  Requesting Access Token

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

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,” January 2013.) [OpenID.Messages]. The Client sends the parameters via HTTPS POST to the Token Endpoint using form serialization (Form Serialization) as specified 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:

• Require client authentication for any Client issued client credentials (or with other authentication requirements),
• Authenticate the Client if client authentication is included and ensure the Authorization Code was issued to the authenticated Client,
• Verify that the Authorization Code is valid, and
• Ensure that, if redirect_uri parameter is present (which it should be), that the Scheme, Host, Path, and Query Parameter segments are identical to the redirect_uri parameter value that was included in the initial Authorization Request (which also should have been present). Should the redirect_uri parameter value not be present when there is only one registered redirect_uri value, the Authorization Server MAY return an error (since the client should have included the parameter) or MAY proceed without an error (since OAuth 2.0 permits the parameter to be omitted in this case).

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,” January 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"
  }

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,” January 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"
  }

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,” January 2013.) [OpenID.Messages]. The Client sends the parameters via HTTPS POST to the Token Endpoint using form serialization (Form Serialization) as specified 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.

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,” January 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
  }

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

4.  UserInfo Endpoint

To obtain the requested Claims about the End-User, the Client makes a GET or POST request to the UserInfo Endpoint as in OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.) [OpenID.Messages].

Authorization Servers MUST require the use of a transport-layer security mechanism. The Authorization Server MUST support TLS 1.2 RFC 5246 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] and/or TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) and MAY support other transport-layer mechanisms with equivalent security.

Authorization Servers MUST support the use of the HTTP "GET" and HTTP "POST" methods defined in RFC 2616 (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.

Authorization Servers 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].

Authorization Servers SHOULD support the use of Cross Origin Resource Sharing (CORS) (van Kesteren, “Cross-Origin Resource Sharing,” July 2010.) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint.

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,” January 2013.) [OpenID.Messages] either in HTTP GET or 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 method for all requests using GET.

The following is a non-normative example:

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

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

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,” January 2013.) [OpenID.Messages].

The HTTP 400 (Bad Request) status code SHOULD be returned for the OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] response when the invalid_schema error occurs.

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"

5.  Self-Issued OpenID Provider

There is a special issuer "https://self-issued.me" that indicates a user is using a personal OP that issues self-signed ID Tokens.

5.1.  Self-Issued OpenID Provider Discovery

If the input identifier contains the domain self-issued.me, dynamic discovery is not performed. The following static configuration values are used.

  {
   "authorization_endpoint":
     "openid:",
   "issuer":
     "https://self-issued.me",
   "scopes_supported":
     ["openid", "profile", "email", "address", "phone"],
   "response_types_supported":
     ["id_token"],
   "subject_types_supported":
     ["pairwise"],
   "id_token_signing_alg_values_supported":
     ["RS256"],
   "request_object_signing_alg_values_supported":
     ["none", "RS256"]
  }

Note: The OpenID Foundation may consider hosting a site https://self-issued.me/ that returns the above static configuration file so that the client would not need any special treatment for discovery of the self-issued OP.

5.2.  Client Registration to Self-Issued OpenID Provider

When using a self-issued OP, the Client is deemed to have registered with the OP and obtained following Client Registration Response.

client_id

redirect_uri of the Client.

expires_at

0.

Note: The OpenID Foundation may consider hosting the (stateless) endpoint https://self-issued.me/registration/1.0/ that returns the response above so that the Client would not need to perform any special processing for registration of a self-issued OP.

5.3.  Self-Issued OpenID Provider Request

The Client sends the Authorization Request to the Authorization Endpoint with the following REQUIRED parameters.

response_type

REQUIRED. Constant string value id_token.

client_id

REQUIRED. redirect_uri of the client. Note that since it is same as the redirect_uri, redirect_uri is not required to be sent in the request.

scope

REQUIRED. scope parameter value, as defined in Section 2.1 (OpenID Connect Scope Values).

policy_url

REQUIRED. URL of a page that the Client provides to the End-User to read describing the how the attributes received will be used. The OP SHOULD display this URL to the End-User. Unlike the standard OP case, a self-issued OP cannot receive this value at the registration time, so it has to be provided as a part of the authorization request.

request

OPTIONAL. OpenID Request Object value, as defined in Section 2.1.1.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,” January 2013.) [OpenID.Messages]. The OpenID Request Object may be encrypted in a JWE by the client. The sub (subject) of the ID Token MUST be sent as the kid (Key ID) of the JWE.

id_token_hint

OPTIONAL. ID Token passed to the Authorization Server as a hint about the user's current or past authenticated session with the Client. This SHOULD be present if prompt=none is sent. The value is a JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012.) [JWS] encoded ID Token as signed by the Issuer, the JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012.) [JWS] may be JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2012.) [JWE] encrypted by the public key of the Issuer for additional confidentiality. If the ID Token received by the RP was encrypted, the Client MUST decrypt the signed ID Token. The Client MAY re-encrypt using the key that the server is capable of decrypting. For a self-issued ID Token, the sub (subject) of the ID Token MUST be sent as the kid (Key ID) of the JWE.

Other parameters MAY be sent. Note that all claims are returned in the ID Token.

The entire URL MUST NOT exceed 2048 bytes.

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

  HTTP/1.1 302 Found
  Location: openid://
    ?response_type=id_token
    &client_id=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &policy_url=https%3A%2F%2Fclient.example.org%2Fusage%2F
    &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

5.4.  Self-Issued OpenID Provider Response

The self-issued OpenID Provider response is the same as the normal implicit flow response with the following refinements. Since it is an implicit flow response, the response parameters will be returned in a fragment.

1. The iss (issuer) Claim value is https://self-issued.me.
2. A sub_jwk Claim is present, with its value being the public key value used to check the signature of the ID Token.
3. The sub (subject) Claim value is the base64url encoded SHA-256 hash of the concatenation of the bytes of the UTF-8 representations of the base64url encoded key values in the sub_jwk claim. When the kty value is RSA, the key values n and e are concatenated in that order. When the kty value is EC, the key values crv, x and y are concatenated in that order.
4. No Access Token is returned for accessing a UserInfo endpoint, so all claims returned must be in the ID Token.

5.5.  Self-Issued ID Token Validation

To validate the ID Token in the Authorization or Token Endpoint Response, the Client MUST do the following:

1. The Client MUST validate that the value of the iss (issuer) Claim is https://self-isued.me. If iss contains a different value, the ID Token is not self-issued, and instead it MUST be validated according to Section 5.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,” January 2013.) [OpenID.Messages].
2. The Client MUST validate that the aud (audience) Claim contains the value of the redirect_uri that the client sent in the authentication request as an audience.
3. The Client MUST validate the signature of the ID Token according to JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012.) [JWS] using the algorithm specified in the alg parameter of the JWT header [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.), using the key in the sub_jwk claim; the key is in JWK format.
4. The alg value SHOULD be the default of RS256. It may also be ES256.
5. The Client MUST validate that the sub (subject) Claim value is the base64url encoded SHA-256 hash of the concatenation of the bytes of the UTF-8 representations of the base64url encoded key values in the sub_jwk claim. When the kty value is RSA, the key values n and e are concatenated in that order. When the kty value is EC, the key values crv, x and y are concatenated in that order.
6. The current time MUST be less than the value of the exp Claim (possibly allowing for some small leeway to account for clock skew).
7. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces must be stored to prevent attacks. The acceptable range is Client specific.
8. If a nonce value was sent in the Authorization Request, a nonce Claim MUST be present and its value of the checked to verify that it is the same value as the one that was sent in the Authorization Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.

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

  {
   "iss": "https://self-issued.me",
   "sub": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k",
   "aud": "https://client.example.org/cb",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "sub_jwk": {
     "kty":"RSA",
     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "e":"AQAB"
    }
  }

6.  Initiating Login at Client from Third Party

In some cases the login flow may start at the Authorization Server or other party via a stored link. The target resource at the Client may also 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,” January 2013.) [OpenID.Registration] an initiate_login_uri that can be used by the Authorization Server or other party to initiate login for a user at the Client.

The Authorization Server or Third Party sends the Initiation Request to the Client Initiation Endpoint with the following parameters:

login_hint

REQUIRED. Hint to the authorization service about the login identifier the user may use to authenticate at the authorization service.

iss

REQUIRED. Issuer Identifier for the Issuer that the client is to send the authentication request to. The value MUST be a URI 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. Parameters 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.

7.  Serializations

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

1. Query String Serialization
2. Form Serialization

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

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

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,” January 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,” January 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,” January 2013.) [OpenID.Messages] specification, all the implementation considerations described in that specification also apply here.

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,” January 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,” January 2013.) [OpenID.Registration] specifications.

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,” January 2013.) [OpenID.Messages].

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

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.

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.

11.  IANA Considerations

11.1.  OAuth Parameters Registry

This specification registers the following parameters in the IANA OAuth Parameters registry defined in RFC 6749 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749].

11.1.1.  Registry Contents

• Parameter name: display
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 2.3.1 (Client Prepares Authorization Request) of this document
• Related information: None

• Parameter name: prompt
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 2.3.1 (Client Prepares Authorization Request) of this document
• Related information: None

• Parameter name: nonce
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 2.3.1 (Client Prepares Authorization Request) of this document
• Related information: None

• Parameter name: request
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 2.3.1 (Client Prepares Authorization Request) of this document
• Related information: None

• Parameter name: request_uri
• Parameter usage location: Authorization Request
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 2.3.1 (Client Prepares Authorization Request) of this document
• Related information: None

• Parameter name: id_token
• Parameter usage location: Authorization Response, Access Token Response
• Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
• Specification document(s): Section 2.3.1 (Client Prepares Authorization Request) of this document
• Related information: None

12.  References

12.1. Normative References

12.2. Informative References

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), Deutsche Telekom

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

George Fletcher (gffletch@aol.com), AOL

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

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

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

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

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

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.

Appendix C.  Document History

[[ To be removed from the final specification ]]

-16

• Added Implementation Considerations section.
• Fixed #698 - Inconsistent use of articles.
• Fixed #655 - Specify UTF-8 as encoding scheme whenever necessary.
• To remove ambiguity in the self-issued sub computation, changed the text "the concatenation of the key values" to "the concatenation of the bytes of the UTF-8 representations of the base64url encoded key values".
• Renamed the user_jwk Claim to sub_jwk, paralleling the change from user_id to sub.
• Tracked JWK parameter name changes alg -> kty, mod -> n, exp -> e.

-15

• Fixed #687 - Inconsistency between user_id and prn claims. The fix changed these names: user_id -> sub, user_id_types_supported -> subject_types_supported, user_id_type -> subject_type, and prn -> sub.
• Fixed #689 - Track JWT change that allows JWTs to have multiple audiences.
• Fixed #539 - Add scope for offline access.
• Re #601 add Initiating login at a client from a third party
• Made the OpenID Foundation Artifact Binding Working Group the change controller for the values registered with IANA.
• Moved OAuth error registrations from Standard to Messages since the errors are defined in Messages and not in Standard.
• Re #657 Changed id_token to id_token_hint in Sec 2.3.1

-14

• Fixed #614 - Discovery - 3.2 Distinguishing between signature and integrity parameters for HMAC algorithms. This fix tracks the parameter changes made to the JWE spec in draft-ietf-jose-json-web-encryption-06. It deletes the parameters {userinfo,id_token}_encrypted_response_int. It replaces the parameters {userinfo,id_token,request_object,token_endpoint}_algs_supported with {userinfo,id_token,request_object,token_endpoint}_signing_alg_values_supported and {userinfo,id_token,request_object,token_endpoint}_encryption_{alg,enc}_values_supported.
• Fixed #666 - JWS signature validation vs. verification.
• Fixed #681 - Change remaining uses of "birthday" to "birthdate".
• Fixed #669 - Inconsistent treatment of redirect_uri parameter.
• Referenced OAuth 2.0 RFCs -- RFC 6749 and RFC 6750.

-13

• Defined means of using a self-issued OP

-12

• Updated matching of redirect URI to include query parameters to match Google's implementation

-11

• Removed claims_in_id_token scope value, per decision on June 15, 2012 special working group call

-10

• Changed verified to email_verified, per issue #564
• Added scope value claims_in_id_token as a switch to indicate that the UserInfo claims should be returned in the id_token, per issue #561
• Changed optional claim request parameter to essential, per issue #577
• Removed Check ID Endpoint, per issue #570
• Specified that parameters present in both the OpenID Request Object and the OAuth 2.0 Authorization Request MUST exactly match, per issue #575
• Changed OpenID Request Object from being specified as a JWT to being specified as a JWS signed base64url encoded JSON object, per issue #592
• Made use of the nonce REQUIRED when using the implicit flow and OPTIONAL when using the code flow, per issue #569
• Changed client.example.com to client.example.org, per issue #251
• Removed example text for generating a nonce via a signed session cookie, per issue #562
• Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token)

-09

• Added error interaction_required and removed user_mismatched, per issue #523
• Changed invalid_request_request_uri to invalid_request_uri and invalid_request_redirect_uri to invalid_redirect_uri, per issue #553
• Added optional id_token to authorization request parameters, per issue #535
• Removed use of non-existent scope parameters registry, per issue #558
• Updated Notices
• Updated References

-08

• Updated version number and date
• Fix #543 Section 2.3.1.3 Request file requiring all request params to be included is false
• Fix Section 5.1 to reference Messages 2.4.1 rather than 3.3
• Added reference to CORS for JS clients to userinfo and check_id endpoints

-07

• Removed definition and usage for assertion and claim object
• Removed Request File Registration Service
• Consistent use of End-User
• email scope allows access to the 'verified' claim
• Removed language pertaining to custom userinfo schemas
• Updated error section for refreshing access token
• Remove 'audience' parameter from Authorization Request
• Moved display=none to prompt=none
• Moved IANA considerations from Messages
• Check ID Endpoint returns only JSON
• Removed PPID scope value
• Reference Messages for validation of request object encryption and signature
• Redefined 'nonce' in Authorization Request. Changed to REQUIRED parameter.
• Changed usage of "approval" to "consent"
• Use RFC 6125 to verify TLS endpoints
• Added Privacy considerations
• Changed 'request_uri' to require HTTPS unless the referenced content is signed and only needs to be reachable by AS
• Added hash and entropy considerations to 'request_uri'
• Added requirement to compare user_id from userinfo endpoint to id_token
• Check ID Endpoint SHOULD use POST
• Changed UserInfo Error Response to augment and return OAuth 2.0 Bearer Token Error Response
• Added section about string comparison rules needed
• Added Response Encoding according to Multiple Response Types spec
• Allows only 'id_token' for 'response_type' parameter in Authorization Request
• Clarified redirect_uris matching
• Added explanation of select_account
• Changed Security Considerations to refer to corresponding section in Messages
• Check ID Endpoint uses ID Token as Access Token according to Bearer Token spec
• Update John Bradley email and affiliation for Implementer's Draft
• Removed invalid_authorization_code, invalid_id_token error codes

-06

• Reworked return type wording in section 4.4.1 per ticket #174.
• Added reference to registered return types.
• Bumped Version number and date.
• Make clear the server passes the value of nonce through untouched. Ticket #97.
• Prevent caching of request_uri. Ticket #148.
• Add nonce to request examples. Ticket #147.
• Fixed 4.3.1.3 per ticket #150.
• Fixed 4.3.2 to remove display scopes per ticket #172.
• Make scope optional for refresh in 5.2.
• Reference messages 3.2.2 for field definitions in section 5.2.1 per ticket #159.
• Removed scopes from display value in 4.3.1 per ticket #172.
• Make "code" and "id_token token" response types mandatory for Authorization Servers to support.

-05

• Changed check_session to check_id.
• schema=openid now required when requesting UserInfo.
• Removed display values popup, touch, and mobile, since not well defined.
• Resolve issue #135, clarifying that the access_token MAY be sent in the message body.

-04

• Changes associated with renaming "Lite" to "Basic Client" and replacing "Core" and "Framework" with "Messages" and "Standard".
• Numerous cleanups, including updating references.

-03

• Added secret_type to the Token Endpoint.
• Minor edits to the samples.

-02

• Incorporates feedback from Nat Sakimura.

-01

• First Draft that incorporates the merge of the Core and Framework specs.

Authors' Addresses