Draft N. Sakimura NRI J. Bradley Ping Identity M. Jones Microsoft B. de Medeiros Google E. Jay Illumila August 16, 2012 OpenID Connect Standard 1.0 - draft 13 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. Sakimura, et al. [Page 1] OpenID Connect Standard 1.0 August 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation and Conventions . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Authorization Endpoint . . . . . . . . . . . . . . . . . . . . 5 2.1. OpenID Connect Scopes . . . . . . . . . . . . . . . . . . 5 2.2. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. How to Get an Authorization Code, Access Token, and ID Token . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Authorization Code Flow . . . . . . . . . . . . . . . 6 2.2.3. Implicit Flow . . . . . . . . . . . . . . . . . . . . 7 2.3. Authorization Request . . . . . . . . . . . . . . . . . . 7 2.3.1. Client Prepares an Authorization Request . . . . . . . 8 2.3.1.1. Simple Request Method . . . . . . . . . . . . . . 10 2.3.1.2. Request Parameter Method . . . . . . . . . . . . . 11 2.3.1.3. Request File Method . . . . . . . . . . . . . . . 14 2.3.2. Authorization Server Validates Request Object . . . . 16 2.3.3. Authorization Server Authenticates the End-User . . . 16 2.3.4. Authorization Server Obtains the End-User Consent/Authorization . . . . . . . . . . . . . . . . 17 2.3.5. Authorization Server Sends the End-User Back to the Client . . . . . . . . . . . . . . . . . . . . . . 17 2.3.5.1. End-User Grants Authorization . . . . . . . . . . 18 2.3.5.2. End-User Denies Authorization or Invalid Request . . . . . . . . . . . . . . . . . . . . . 22 3. Token Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1. Requesting an Access Token . . . . . . . . . . . . . . . . 24 3.1.1. Access Token Request . . . . . . . . . . . . . . . . . 24 3.1.2. Access Token Response . . . . . . . . . . . . . . . . 25 3.1.3. Access Token Error Response . . . . . . . . . . . . . 26 3.2. Refreshing an Access Token . . . . . . . . . . . . . . . . 26 3.2.1. Refresh Token Response . . . . . . . . . . . . . . . . 27 3.2.2. Refresh Token Error Response . . . . . . . . . . . . . 27 4. UserInfo Endpoint . . . . . . . . . . . . . . . . . . . . . . 28 4.1. UserInfo Request . . . . . . . . . . . . . . . . . . . . . 28 4.2. UserInfo Response . . . . . . . . . . . . . . . . . . . . 28 4.3. UserInfo Error Response . . . . . . . . . . . . . . . . . 29 5. Self-Issued Identity Provider . . . . . . . . . . . . . . . . 30 5.1. Self-Issued Identity Provider Discovery . . . . . . . . . 30 5.2. Client Registration to Self-Issued Identity Provider . . . 30 5.3. Self-Issued Identity Provider Request . . . . . . . . . . 31 5.4. Self-Issued Identity Provider Response . . . . . . . . . . 31 5.5. Self-Issued Identity ID Token Verification . . . . . . . . 31 6. Discovery and Registration . . . . . . . . . . . . . . . . . . 34 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 35 7.1. Query String Serialization . . . . . . . . . . . . . . . . 35 7.2. Form Serialization . . . . . . . . . . . . . . . . . . . . 35 Sakimura, et al. [Page 2] OpenID Connect Standard 1.0 August 2012 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8.1. Implicit Grant Flow Threats . . . . . . . . . . . . . . . 36 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 10.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 38 10.1.1. Authorization Request Parameter (display) . . . . . . 38 10.1.2. Authorization Request Parameter (prompt) . . . . . . . 38 10.1.3. Authorization Request Parameter (nonce) . . . . . . . 38 10.1.4. Authorization Request Parameter (request) . . . . . . 39 10.1.5. Authorization Request Parameter (request_uri) . . . . 39 10.1.6. ID Token Response Parameters . . . . . . . . . . . . . 39 10.2. OAuth Extensions Error Registry . . . . . . . . . . . . . 40 10.2.1. Authorization Endpoint Error (invalid_redirect_uri) . 40 10.2.2. Authorization Endpoint Error (interaction_required) . 40 10.2.3. Authorization Endpoint Error (login_required) . . . . 40 10.2.4. Authorization Endpoint Error (session_selection_required) . . . . . . . . . . . . . 41 10.2.5. Authorization Endpoint Error (consent_required) . . . 41 10.2.6. Authorization Endpoint Error (invalid_request_uri) . . 41 10.2.7. Authorization Endpoint Error (invalid_openid_request_object) . . . . . . . . . . . 42 10.2.8. UserInfo Endpoint Error (invalid_schema) . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.1. Normative References . . . . . . . . . . . . . . . . . . . 43 11.2. Informative References . . . . . . . . . . . . . . . . . . 44 Appendix A. Footnotes . . . . . . . . . . . . . . . . . . . . . . 45 A.1. Example JWT Values . . . . . . . . . . . . . . . . . . . . 45 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 46 Appendix C. Notices . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix D. Document History . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Sakimura, et al. [Page 3] OpenID Connect Standard 1.0 August 2012 1. Introduction This specification describes the binding of the HTTP protocol with the endpoints described in OpenID Connect Messages 1.0 [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] . 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 [OAuth2.0], and the terms defined by OpenID Connect Messages [OpenID.Messages]. This specification also defines the following terms: Request File A document whose contents is an OpenID Request Object representing a set of Authorization Request parameters. Request File URI A URL that references a Request File. The Request File contents MUST be retrievable by the Authorization Server. Sakimura, et al. [Page 4] OpenID Connect Standard 1.0 August 2012 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 Scopes 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 [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 [OAuth2.0]. Access Tokens represent a Resource Owner's authorization and MUST NOT be exposed to unauthorized parties. The Implicit Flow is mainly used by Clients implemented in a browser using a scripting language. The Access Token and ID Token are returned directly to the Client, which MAY expose them to the Resource Owner and other applications that have access to the Sakimura, et al. [Page 5] OpenID Connect Standard 1.0 August 2012 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 an Authorization Code, Access Token, and ID Token In OpenID Connect Standard, 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 (Section 2.2.2) and the former is called Implicit Flow (Section 2.2.3). 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 (Section 3). 7. Client receives a response that contains an Access Token and ID Token in the response body. 8. Client validates ID Token to get the End-User's identifier. Sakimura, et al. [Page 6] OpenID Connect Standard 1.0 August 2012 9. (OPTIONAL) Client accesses the UserInfo Endpoint (Section 4) with the Access Token. 10. (OPTIONAL) Client receives UserInfo Response. Note that in each step, the party that receives a message MUST verify it according to the verification rule set in OpenID Connect Messages [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 ID Token to get the End-User's identifier. 7. (OPTIONAL) Client accesses the UserInfo Endpoint (Section 4) with the Access Token. 8. (OPTIONAL) Client receives UserInfo Response. Note that in each step, the party that receives a message MUST verify it according to the verification rule set in OpenID Connect Messages [OpenID.Messages]. 2.3. Authorization Request When the End-User wishes to access a Protected Resource and the End- User Authorization has not yet been obtained, the Client prepares an Authorization Request to the Authorization Endpoint. Authorization Servers MUST require the use of a transport-layer security mechanism at the Authorization Endpoint. The Authorization Server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support other transport-layer mechanisms with equivalent security. Sakimura, et al. [Page 7] OpenID Connect Standard 1.0 August 2012 Authorization Servers MUST support the use of the HTTP "GET" and "POST" methods defined in RFC 2616 [RFC2616] at the Authorization Endpoint. Clients MAY use the HTTP "GET" or "POST" method to send the Authorization Request to the Authorization Server. If using the HTTP "GET" method, the request parameters are serialized using URI query string serialization (Section 7.1). If using the HTTP "POST" method, the request parameters are serialized using form serialization (Section 7.2). 2.3.1. Client Prepares an Authorization Request The Client prepares an Authorization Request to the Authorization Endpoint with the request parameters using the HTTP "GET" or "POST" method. The scheme used in the Authorization URL MUST be HTTPS. The Client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. The required Authorization Request parameters are as follows: response_type An OAuth 2.0 registered response type that determines how the Authorization Response is returned to the Client. As described in OAuth 2.0 Multiple Response Type Encoding Practices [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 The Client identifier. scope It MUST include "openid" as one of the space delimited ASCII strings. Other values that MAY be included are "profile", "email", "address", and "phone". The values specify an additive list of Claims that are returned by the UserInfo Endpoint. Sakimura, et al. [Page 8] OpenID Connect Standard 1.0 August 2012 redirect_uri A redirection URI where 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 [OpenID.Registration] specification. The request MAY contain the following OPTIONAL and sometimes REQUIRED parameters: nonce A 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 An opaque value used to maintain state between the request and the callback. request An OpenID Request Object value. request_uri A URL that points to an OpenID Request Object. display An ASCII string value that specifies how the Authorization Server displays the authentication page to the End-User. Refer to Section 2.1.2 of OpenID Connect Messages [OpenID.Messages] for more information. prompt A space delimited list of ASCII strings that can contain the values "login", "consent", "select_account", and "none". Refer to OpenID Connect Messages [OpenID.Messages] for more information. id_token An ID Token passed to the Authorization server as a hint. Refer to OpenID Connect Messages [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 Sakimura, et al. [Page 9] OpenID Connect Standard 1.0 August 2012 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 (Section 7.1). If using the HTTP "POST" method, the request parameters are serialized using form serialization (Section 7.2). 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 a request to the 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 Sakimura, et al. [Page 10] OpenID Connect Standard 1.0 August 2012 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. 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 [JWS] and JWE [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:{"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): Sakimura, et al. [Page 11] OpenID Connect Standard 1.0 August 2012 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":{ "acr":{"values":["2"]} } } } OpenID Request Object = eyJhbGciOiJSUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIs ImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczpcL 1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbG UiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyTWoiLCJ 1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6eyJlc3NlbnRpYWwiOnRydWV9LCJu aWNrbmFtZSI6bnVsbCwiZW1haWwiOnsiZXNzZW50aWFsIjp0cnVlfSwiZW1haWxfd mVyaWZpZWQiOnsiZXNzZW50aWFsIjp0cnVlfSwicGljdHVyZSI6bnVsbH19LCJpZF 90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiY2xhaW1zIjp7ImFjciI6eyJ2YWx1ZXM iOlsiMiJdfX19fQ.krAJHvc-vo5ntIc5suj2u3gU75nZ1ICcidLEw8OCNyOlTR4Gk 6etZDr5lozMFzhDSXAJ5TxhfUJLsp8VSum8spnmbGaqKr4bEWTirUDGE3TsJCHRQZ LzwuAYlLcS-ZaHVk9ue0oB7q_GeGTAIDHBncJP1x1j-MPvNxWbYXQ4wo9O6Y8Qnby OrrLl5LHRMrvlLFnc0uqt5QKHqcQa6l9wYQjjWJXoZirsWdJ_wmSsfbQCWMRtA6JN bV0q0gImbOGno75GxFKNkguW5JBU4Vj5gEafz2EPSxVsRNWf6MtFvXqOLSZMqoKK4 0b2akbj0kGdZ8aPPSMoywaGclKlIHh0PQ The following is the RSA public key information that can be used to verify the OpenID Request Object signature in the above example. The values are an array of hexadecimal digits in big endian format. modulus: [ Sakimura, et al. [Page 12] OpenID Connect Standard 1.0 August 2012 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] 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.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF 90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3Blbm lkIHByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl 9XekEyTWoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6eyJlc3NlbnRpYW wiOnRydWV9LCJuaWNrbmFtZSI6bnVsbCwiZW1haWwiOnsiZXNzZW50aWFsIjp0cn VlfSwiZW1haWxfdmVyaWZpZWQiOnsiZXNzZW50aWFsIjp0cnVlfSwicGljdHVyZS I6bnVsbH19LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiY2xhaW1zIjp7Im FjciI6eyJ2YWx1ZXMiOlsiMiJdfX19fQ.krAJHvc-vo5ntIc5suj2u3gU75nZ1IC cidLEw8OCNyOlTR4Gk6etZDr5lozMFzhDSXAJ5TxhfUJLsp8VSum8spnmbGaqKr4 bEWTirUDGE3TsJCHRQZLzwuAYlLcS-ZaHVk9ue0oB7q_GeGTAIDHBncJP1x1j-MP vNxWbYXQ4wo9O6Y8QnbyOrrLl5LHRMrvlLFnc0uqt5QKHqcQa6l9wYQjjWJXoZir sWdJ_wmSsfbQCWMRtA6JNbV0q0gImbOGno75GxFKNkguW5JBU4Vj5gEafz2EPSxV sRNWf6MtFvXqOLSZMqoKK40b2akbj0kGdZ8aPPSMoywaGclKlIHh0PQ Sakimura, et al. [Page 13] OpenID Connect Standard 1.0 August 2012 2.3.1.2.1. Client Sends a Request to the Authorization Server Having constructed the Authorization Request, the Client sends it to the HTTPS Authorization Endpoint. This MAY happen via HTTPS redirect, hyperlinking, or any other means of directing the User- Agent to the Authorization Endpoint. Following is a non-normative example using HTTP redirect (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.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF 90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3Blbm lkIHByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl 9XekEyTWoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6eyJlc3NlbnRpYW wiOnRydWV9LCJuaWNrbmFtZSI6bnVsbCwiZW1haWwiOnsiZXNzZW50aWFsIjp0cn VlfSwiZW1haWxfdmVyaWZpZWQiOnsiZXNzZW50aWFsIjp0cnVlfSwicGljdHVyZS I6bnVsbH19LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiY2xhaW1zIjp7Im FjciI6eyJ2YWx1ZXMiOlsiMiJdfX19fQ.krAJHvc-vo5ntIc5suj2u3gU75nZ1IC cidLEw8OCNyOlTR4Gk6etZDr5lozMFzhDSXAJ5TxhfUJLsp8VSum8spnmbGaqKr4 bEWTirUDGE3TsJCHRQZLzwuAYlLcS-ZaHVk9ue0oB7q_GeGTAIDHBncJP1x1j-MP vNxWbYXQ4wo9O6Y8QnbyOrrLl5LHRMrvlLFnc0uqt5QKHqcQa6l9wYQjjWJXoZir sWdJ_wmSsfbQCWMRtA6JNbV0q0gImbOGno75GxFKNkguW5JBU4Vj5gEafz2EPSxV sRNWf6MtFvXqOLSZMqoKK40b2akbj0kGdZ8aPPSMoywaGclKlIHh0PQ 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 [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, Sakimura, et al. [Page 14] OpenID Connect Standard 1.0 August 2012 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.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiI sImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczp cL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2Z pbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyTWo iLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6eyJlc3NlbnRpYWwiOnRydWV 9LCJuaWNrbmFtZSI6bnVsbCwiZW1haWwiOnsiZXNzZW50aWFsIjp0cnVlfSwiZW1 haWxfdmVyaWZpZWQiOnsiZXNzZW50aWFsIjp0cnVlfSwicGljdHVyZSI6bnVsbH1 9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiY2xhaW1zIjp7ImFjciI6eyJ 2YWx1ZXMiOlsiMiJdfX19fQ.krAJHvc-vo5ntIc5suj2u3gU75nZ1ICcidLEw8OC NyOlTR4Gk6etZDr5lozMFzhDSXAJ5TxhfUJLsp8VSum8spnmbGaqKr4bEWTirUDG E3TsJCHRQZLzwuAYlLcS-ZaHVk9ue0oB7q_GeGTAIDHBncJP1x1j-MPvNxWbYXQ4 wo9O6Y8QnbyOrrLl5LHRMrvlLFnc0uqt5QKHqcQa6l9wYQjjWJXoZirsWdJ_wmSs fbQCWMRtA6JNbV0q0gImbOGno75GxFKNkguW5JBU4Vj5gEafz2EPSxVsRNWf6MtF vXqOLSZMqoKK40b2akbj0kGdZ8aPPSMoywaGclKlIHh0PQ 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 [FIPS180-2] 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 #yhjJGgQ3UwE2Lm2i_wZNb5QxQ6XRnfzqYOretJMFTQI 2.3.1.3.2. Client Sends a Request to Authorization Server via HTTPS Redirect The Client sends the Authorization Request to the Authorization Sakimura, et al. [Page 15] OpenID Connect Standard 1.0 August 2012 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 %23959w6lFunlMyjSaxmW0FtqvkRsmCaAIWuwl6QKeY89g &state=af0ifjsldkj&nonce=n-0S6_WzA2Mj&scope=openid 2.3.1.3.3. Authorization Server Fetches the Request File Upon receipt of the Request, the Authorization Server MUST send a GET request to the "request_uri" to retrieve the content unless it is already cached and parse it to recreate the Authorization Request parameters. 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 [OpenID.Messages]. 2.3.3. Authorization Server Authenticates the End-User The Authorization Server validates the request to ensure all required parameters are present and valid. If the request is valid, the Authorization Server MUST authenticate the End-User. The way in which the Authorization Server authenticates the End-User (e.g. username and password login, session cookies) is beyond the scope of this specification. An authentication user interface MAY be displayed by the Authorization Server depending on the authentication method used. The Authorization Server MUST attempt to authenticate the End-User in the following cases: Sakimura, et al. [Page 16] OpenID Connect Standard 1.0 August 2012 o The End-User is not already authenticated by the Authorization Server. o 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: o 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 the 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: o The End-User has not pre-authorized the Client for the authorization request. o 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: o 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 the End-User Back to the Client Once the authorization is determined, the Authorization Server returns a successful or error response. Sakimura, et al. [Page 17] OpenID Connect Standard 1.0 August 2012 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 [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 Sakimura, et al. [Page 18] OpenID Connect Standard 1.0 August 2012 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.eyJpc3MiOiJodHRwOlwvXC9zZXJ2ZXIuZ XhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCa GRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwL CJpYXQiOjEzMTEyODA5NzB9.RgXxzppVvn1EjUiV3LIZ19SyhdyREe_2jJjW5EC8 XjNuJfe7Dte8YxRXxssJ67N8MT9mvOI3HOHm4whNx5FCyemyCGyTLHODCeAr_id0 29-4JP0KWySoan1jmT7vbGHhu89-l9MTdaEvu7pNZO7DHGwqnMWRe8hdG7jUES4w 4ReQTygKwXVVOaiGoeUrv6cZdbyOnpGlRlHaiOsv_xMunNVJtn5dLz-0zZwVftKV pFuc1pGaVsyZsOtkT32E4c6MDHeCvIDlR5ESC0ct8BLvGJDB5954MjCR4_X2GAEH onKw4NF8wTmUFvhslYXmjRNFs21Byjn3jNb7lSa3MBfVsw &state=af0ifjsldkj Sakimura, et al. [Page 19] OpenID Connect Standard 1.0 August 2012 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.eyJpc3MiOiJodHRwOlwvXC9zZXJ2ZXIuZ XhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCa GRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwL CJpYXQiOjEzMTEyODA5NzB9.RgXxzppVvn1EjUiV3LIZ19SyhdyREe_2jJjW5EC8 XjNuJfe7Dte8YxRXxssJ67N8MT9mvOI3HOHm4whNx5FCyemyCGyTLHODCeAr_id0 29-4JP0KWySoan1jmT7vbGHhu89-l9MTdaEvu7pNZO7DHGwqnMWRe8hdG7jUES4w 4ReQTygKwXVVOaiGoeUrv6cZdbyOnpGlRlHaiOsv_xMunNVJtn5dLz-0zZwVftKV pFuc1pGaVsyZsOtkT32E4c6MDHeCvIDlR5ESC0ct8BLvGJDB5954MjCR4_X2GAEH onKw4NF8wTmUFvhslYXmjRNFs21Byjn3jNb7lSa3MBfVsw &state=af0ifjsldkj 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 Sakimura, et al. [Page 20] OpenID Connect Standard 1.0 August 2012 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.eyJpc3MiOiJodHRwOlwvXC9zZXJ2ZXIuZ XhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCa GRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwL CJpYXQiOjEzMTEyODA5NzB9.RgXxzppVvn1EjUiV3LIZ19SyhdyREe_2jJjW5EC8 XjNuJfe7Dte8YxRXxssJ67N8MT9mvOI3HOHm4whNx5FCyemyCGyTLHODCeAr_id0 29-4JP0KWySoan1jmT7vbGHhu89-l9MTdaEvu7pNZO7DHGwqnMWRe8hdG7jUES4w 4ReQTygKwXVVOaiGoeUrv6cZdbyOnpGlRlHaiOsv_xMunNVJtn5dLz-0zZwVftKV pFuc1pGaVsyZsOtkT32E4c6MDHeCvIDlR5ESC0ct8BLvGJDB5954MjCR4_X2GAEH onKw4NF8wTmUFvhslYXmjRNFs21Byjn3jNb7lSa3MBfVsw &state=af0ifjsldkj Sakimura, et al. [Page 21] OpenID Connect Standard 1.0 August 2012 Public Key Information used to verify the ID Token The following is the RSA public key information that can be used to verify 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 [OpenID.Messages]. The Authorization Server returns the Client to the redirection URI specified in the Authorization Request with the appropriate error parameters. No other parameters SHOULD be returned. The error response parameters are the following: error REQUIRED. The error code. error_description OPTIONAL. A human-readable UTF-8 encoded text description of the error. error_uri OPTIONAL. A URI to a web page that includes additional information about the error. Sakimura, et al. [Page 22] OpenID Connect Standard 1.0 August 2012 state REQUIRED if the Authorization Request included the "state" parameter. Set to the exact value received from the Client. If the "response_type" parameter in the Authorization Request includes the string value "token" or "id_token", all error response parameters SHOULD be added to the fragment component of the redirection URI. Otherwise, the response parameters are added to the query component of the redirection URI. The following is a non-normative example (with line wraps after the second line 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 Sakimura, et al. [Page 23] OpenID Connect Standard 1.0 August 2012 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 (Section 7.2). Clients MAY provide authentication parameters in the request to the Token Endpoint as described in Section 2.2.1 of OpenID Connect Messages [OpenID.Messages]. Authorization Servers MUST support the use of the HTTP "POST" method defined in RFC 2616 [RFC2616] at the Token Endpoint. Authorization Servers MUST require the use of a transport-layer security mechanism. The Authorization Server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support other transport-layer mechanisms with equivalent security. All Token Endpoint responses that contain tokens, secrets, or other sensitive information MUST include the following HTTP response header fields and values: +---------------+--------------+ | Header Name | Header Value | +---------------+--------------+ | Cache-Control | no-store | | | | | Pragma | no-cache | +---------------+--------------+ HTTP Response Headers and Values 3.1. Requesting an Access Token To retrieve an Access Token, a Client MUST have an Authorization Code obtained via the method as described in Authorization Code Flow (Section 2.2.2). 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 [OpenID.Messages]. The Client sends the parameters via HTTPS POST to the Token Endpoint using form Sakimura, et al. [Page 24] OpenID Connect Standard 1.0 August 2012 serialization (Section 7.2) as specified in Section 4.1.3 of OAuth 2.0 [OAuth2.0]. 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: o Require client authentication for any Client issued client credentials (or with other authentication requirements), o Authenticate the Client if client authentication is included and ensure the Authorization Code was issued to the authenticated Client, o Verify that the Authorization Code is valid, and o Ensure that the "redirect_uri" parameter is present if the "redirect_uri" parameter was included in the initial Authorization Request and that their values are identical for the Scheme, Host, Path, and Query Parameter segments. 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 [OpenID.Messages]. Sakimura, et al. [Page 25] OpenID Connect Standard 1.0 August 2012 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.eyJpc3MiOiJodHRwOlwvXC9zZXJ2Z XIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoic zZCaGRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxO TcwLCJpYXQiOjEzMTEyODA5NzB9.RgXxzppVvn1EjUiV3LIZ19SyhdyREe_2jJjW 5EC8XjNuJfe7Dte8YxRXxssJ67N8MT9mvOI3HOHm4whNx5FCyemyCGyTLHODCeAr _id029-4JP0KWySoan1jmT7vbGHhu89-l9MTdaEvu7pNZO7DHGwqnMWRe8hdG7jU ES4w4ReQTygKwXVVOaiGoeUrv6cZdbyOnpGlRlHaiOsv_xMunNVJtn5dLz-0zZwV ftKVpFuc1pGaVsyZsOtkT32E4c6MDHeCvIDlR5ESC0ct8BLvGJDB5954MjCR4_X2 GAEHonKw4NF8wTmUFvhslYXmjRNFs21Byjn3jNb7lSa3MBfVsw" } 3.1.3. Access Token Error Response If the Token Request is invalid or unauthorized, the Authorization Server constructs the response by returning the Token Error Response defined in OpenID Connect Messages [OpenID.Messages] in the entity body of the HTTP response using the "application/json" media type with HTTP response code 400. Following is a non-normative example: HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "error": "invalid_request" } 3.2. Refreshing an Access Token To refresh an Access Token, the Client MUST authenticate to the Token Endpoint using the authentication method registered for its "client_id", as documented in Section 2.2.1 of OpenID Connect Messages [OpenID.Messages]. The Client sends the parameters via HTTPS POST to the Token Endpoint using form serialization (Section 7.2) as specified in Section 6 of OAuth 2.0 [OAuth2.0]: Sakimura, et al. [Page 26] OpenID Connect Standard 1.0 August 2012 The Authorization Server MUST verify the validity of 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 verification of the Refresh Token, a successful response returns the ""application/json"" media type and the response body is the Access Token Response of Section 2.2.3 of OpenID Connect Messages [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 [OAuth2.0]. Sakimura, et al. [Page 27] OpenID Connect Standard 1.0 August 2012 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 [OpenID.Messages]. Authorization Servers MUST require the use of a transport-layer security mechanism. The Authorization Server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support other transport-layer mechanisms with equivalent security. Authorization Servers MUST support the use of the HTTP "GET" and HTTP "POST" methods defined in RFC 2616 [RFC2616] at the UserInfo Endpoint. Authorization Servers MUST accept Access Tokens as OAuth 2.0 Bearer Tokens [OAuth.Bearer]. Authorization Servers SHOULD support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint. 4.1. UserInfo Request Client SHOULD send the UserInfo Request defined in Section 2.3.1 of OpenID Connect Messages [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 Tokens [OAuth.Bearer] specification documents the permissible methods of sending the Access Token. It is RECOMMENDED that the Client use the authorization header method for all requests using GET. The following is a non-normative example: GET /userinfo?schema=openid HTTP/1.1 Host: server.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X 4.2. UserInfo Response The "user_id" Claim in the UserInfo Endpoint response MUST exactly match the "user_id" Claim in the ID Token, before using additional UserInfo Endpoint Claims. Upon receipt of the UserInfo request, the UserInfo Endpoint MUST Sakimura, et al. [Page 28] OpenID Connect Standard 1.0 August 2012 return the JSON Serialization of the UserInfo response as in OpenID Messages [OpenID.Messages] in the HTTP response body. The content- type of the HTTP response MUST be set to "application/json" if the response body is a text JSON structure. If the JSON response is 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 Verification) of OpenID Connect Messages [OpenID.Messages]. Following is a non-normative example of such response: HTTP/1.1 200 OK Content-Type: application/json { "user_id": "248289761001", "name": "Jane Doe" "given_name": "Jane", "family_name": "Doe", "email": "janedoe@example.com", "picture": "http://example.com/janedoe/me.jpg" } 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 Tokens [OAuth.Bearer] specification utilizing an error code as specified in Section 2.3.3 of OpenID Connect Messages [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" Sakimura, et al. [Page 29] OpenID Connect Standard 1.0 August 2012 5. Self-Issued Identity 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 Identity 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"], "user_id_types_supported": ["pairwise"], "id_token_algs_supported": ["RS256"], "request_object_algs_supported": ["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 Identity 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 The "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. Sakimura, et al. [Page 30] OpenID Connect Standard 1.0 August 2012 5.3. Self-Issued Identity Provider Request The Client sends the Authorization Request to the Authorization Endpoint with the following REQUIRED parameters. response_type REQUIRED. The value "id_token". client_id REQUIRED. The "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. The "scope" parameter, as defined in Section 2.1. policy_url REQUIRED. A 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. 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 Identity Provider Response Self-Issued Identity Provider Response is the same as the normal implicit flow response apart from the fact that the "iss" claim value is "https://self-issued.me" and all claims are returned in "id_token". Since it is an implicit flow response, the response parameters will be returned in a fragment. 5.5. Self-Issued Identity ID Token Verification To verify the validity of ID Token in the Authorization or Token Endpoint Response, the Client MUST do the following: Sakimura, et al. [Page 31] OpenID Connect Standard 1.0 August 2012 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 [OpenID.Messages]. 2. The Client MUST validate that the value of the "aud" (audience) Claim is the value of the "redirect_uri" that the client sent in the authentication request. 3. The Client MUST verify the signature of the ID Token according to JWS [JWS] using the algorithm specified in the "alg" parameter of the JWT header, using the key in the "user_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 "user_id" value is the base64url encoded SHA-256 hash of the concatenation of the key values in the "user_jwk" claim. When the "alg" value is "RS256", the key values "mod" and "exp" are concatenated in that order. When the "alg" value is "ES256", 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. Sakimura, et al. [Page 32] OpenID Connect Standard 1.0 August 2012 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", "user_id": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k", "aud": "https://client.example.org/cb", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "user_jwk": {"alg":"RSA", "mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", "exp":"AQAB" } } Sakimura, et al. [Page 33] OpenID Connect Standard 1.0 August 2012 6. Discovery and Registration Some OpenID Connect installations can use a pre-configured set of OpenID Providers and/or Relying Parties. In those cases, it may not be necessary to support dynamic discovery of information about identities or services or dynamic registration of Clients. However, if installations choose to support unanticipated interactions between Relying Parties and OpenID Providers that do not have pre-configured relationships, they SHOULD accomplish this by implementing the facilities defined in the OpenID Connect Discovery 1.0 [OpenID.Discovery] and OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specifications. Sakimura, et al. [Page 34] OpenID Connect Standard 1.0 August 2012 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]. 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]. 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 Sakimura, et al. [Page 35] OpenID Connect Standard 1.0 August 2012 8. Security Considerations This specification references the security considerations defined in OpenID Connect Messages [OpenID.Messages]. In addition, the following list of attack vectors and remedies are also considered. 8.1. Implicit Grant Flow Threats In the implicit grant flow, the Access Token is returned in the fragment part of the Client's "redirect_uri" through HTTPS, thus it is protected between the OP and the User-Agent, and User-Agent and the RP. The only the place it can be captured is the User-Agent where the TLS session is terminated, and is possible if the User- Agent is infested by malware. Sakimura, et al. [Page 36] OpenID Connect Standard 1.0 August 2012 9. Privacy Considerations The UserInfo response typically contains Personally Identifiable Information. As such, End-User consent for the release of the information for the specified purpose SHOULD be obtained at or prior to the authorization time in accordance with relevant regulations. The purpose of use is typically registered in association with the "redirect_uri". Only necessary UserInfo data should be stored at the Client and the Client SHOULD associate the received data with the purpose of use statement. The Resource Server SHOULD make the UserInfo access log available to the End-User so that the End-User can monitor who accessed his data. To protect the End-User from a possible correlation among Clients, the use of a Pairwise Pseudonymous Identifier (PPID) as the "user_id" SHOULD be considered. Sakimura, et al. [Page 37] OpenID Connect Standard 1.0 August 2012 10. IANA Considerations 10.1. OAuth Parameters Registry 10.1.1. Authorization Request Parameter (display) The following is a parameter registration request for the Authorization Request in this specification: o Parameter name: display o Parameter usage location: Authorization Request o Change controller: IETF o Specification document(s): [[ this document ]] o Related information: None 10.1.2. Authorization Request Parameter (prompt) The following is a parameter registration request for the Authorization Request in this specification: o Parameter name: prompt o Parameter usage location: Authorization Request o Change controller: IETF o Specification document(s): [[ this document ]] o Related information: None 10.1.3. Authorization Request Parameter (nonce) The following is a parameter registration request for the Authorization Request in this specification: o Parameter name: nonce o Parameter usage location: Authorization Request o Change controller: IETF o Specification document(s): [[ this document ]] Sakimura, et al. [Page 38] OpenID Connect Standard 1.0 August 2012 o Related information: None 10.1.4. Authorization Request Parameter (request) The following is a parameter registration request for the Authorization Request in this specification: o Parameter name: request o Parameter usage location: Authorization Request o Change controller: IETF o Specification document(s): [[ this document ]] o Related information: None 10.1.5. Authorization Request Parameter (request_uri) The following is a parameter registration request for the Authorization Request in this specification: o Parameter name: request_uri o Parameter usage location: Authorization Request o Change controller: IETF o Specification document(s): [[ this document ]] o Related information: None 10.1.6. ID Token Response Parameters The following is a parameter registration request for the ID Token Response in this specification: o Parameter name: id_token o Parameter usage location: Authorization Response, Access Token Response o Change controller: IETF o Specification document(s): [[ this document ]] o Related information: None Sakimura, et al. [Page 39] OpenID Connect Standard 1.0 August 2012 10.2. OAuth Extensions Error Registry 10.2.1. Authorization Endpoint Error (invalid_redirect_uri) The following is an error registration request for the Authorization Error Response in this specification: o Error name: invalid_redirect_uri o Error usage location: Authorization Endpoint o Related protocol extension: o Change controller: IETF o Specification document(s): [[this document ]] 10.2.2. Authorization Endpoint Error (interaction_required) The following is an error registration request for the Authorization Error Response in this specification: o Error name: interaction_required o Error usage location: Authorization Endpoint o Related protocol extension: o Change controller: IETF o Specification document(s): [[this document ]] 10.2.3. Authorization Endpoint Error (login_required) The following is an error registration request for the Authorization Error Response in this specification: o Error name: login_required o Error usage location: Authorization Endpoint o Related protocol extension: o Change controller: IETF o Specification document(s): [[this document ]] Sakimura, et al. [Page 40] OpenID Connect Standard 1.0 August 2012 10.2.4. Authorization Endpoint Error (session_selection_required) The following is an error registration request for the Authorization Error Response in this specification: o Error name: session_selection_required o Error usage location: Authorization Endpoint o Related protocol extension: o Change controller: IETF o Specification document(s): [[this document ]] 10.2.5. Authorization Endpoint Error (consent_required) The following is an error registration request for the Authorization Error Response in this specification: o Error name: consent_required o Error usage location: Authorization Endpoint o Related protocol extension: o Change controller: IETF o Specification document(s): [[this document ]] 10.2.6. Authorization Endpoint Error (invalid_request_uri) The following is an error registration request for the Authorization Error Response in this specification: o Error name: invalid_request_uri o Error usage location: Authorization Endpoint o Related protocol extension: o Change controller: IETF o Specification document(s): [[this document ]] Sakimura, et al. [Page 41] OpenID Connect Standard 1.0 August 2012 10.2.7. Authorization Endpoint Error (invalid_openid_request_object) The following is an error registration request for the Authorization Error Response in this specification: o Error name: invalid_openid_request_object o Error usage location: Authorization Endpoint o Related protocol extension: o Change controller: IETF o Specification document(s): [[this document ]] 10.2.8. UserInfo Endpoint Error (invalid_schema) The following is an error registration request for the Authorization Error Response in this specification: o Error name: invalid_schema o Error usage location: UserInfo Endpoint o Related protocol extension: o Change controller: IETF o Specification document(s): [[this document ]] Sakimura, et al. [Page 42] OpenID Connect Standard 1.0 August 2012 11. References 11.1. Normative References [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web Encryption (JWE)", May 2012. [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature", May 2012. [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token", May 2012. [OAuth.Bearer] Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", June 2012. [OAuth.Responses] de Medeiros, B., Scurtescu, M., and P. Tarjan, "OAuth 2.0 Multiple Response Type Encoding Practices", May 2012. [OAuth2.0] Hammer, E., Ed., Recordon, D., and D. Hardt, "The OAuth 2.0 Authorization Framework", June 2012. [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", May 2012. [OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", June 2012. [OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0", May 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [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. Sakimura, et al. [Page 43] OpenID Connect Standard 1.0 August 2012 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [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. [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, . 11.2. Informative References [CORS] van Kestern, "Cross-Origin Resource Sharing", July 2010. Sakimura, et al. [Page 44] OpenID Connect Standard 1.0 August 2012 Appendix A. Footnotes A.1. Example JWT Values The JWT values used in the non-normative examples of this specification are only place holders for actual JWT values. The examples use "jwt_header.jwt_part2.jwt_part3" as the place holder value. For an example of an actual JWT, refer to the JWT [JWT] specification. Sakimura, et al. [Page 45] OpenID Connect Standard 1.0 August 2012 Appendix B. 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. Sakimura, et al. [Page 46] OpenID Connect Standard 1.0 August 2012 Appendix C. Notices Copyright (c) 2012 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. Sakimura, et al. [Page 47] OpenID Connect Standard 1.0 August 2012 Appendix D. Document History [[ To be removed from the final specification ]] -13 o Defined means of using a self-issued OP -12 o Updated matching of redirect URI to include query parameters to match Google's implementation -11 o Removed "claims_in_id_token" scope value, per decision on June 15, 2012 special working group call -10 o Changed "verified" to "email_verified", per issue #564 o 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 o Changed "optional" claim request parameter to "essential", per issue #577 o Removed Check ID Endpoint, per issue #570 o Specified that parameters present in both the OpenID Request Object and the OAuth 2.0 Authorization Request MUST exactly match, per issue #575 o Changed OpenID Request Object from being specified as a JWT to being specified as a JWS signed base64url encoded JSON object, per issue #592 o Made use of the nonce REQUIRED when using the implicit flow and OPTIONAL when using the code flow, per issue #569 o Changed client.example.com to client.example.org, per issue #251 o Removed example text for generating a nonce via a signed session cookie, per issue #562 Sakimura, et al. [Page 48] OpenID Connect Standard 1.0 August 2012 o Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token) -09 o Added error interaction_required and removed user_mismatched, per issue #523 o Changed invalid_request_request_uri to invalid_request_uri and invalid_request_redirect_uri to invalid_redirect_uri, per issue #553 o Added optional id_token to authorization request parameters, per issue #535 o Removed use of non-existent scope parameters registry, per issue #558 o Updated Notices o Updated References -08 o Updated version number and date o Fix #543 Section 2.3.1.3 Request file requiring all request params to be included is false o Fix Section 5.1 to reference Messages 2.4.1 rather than 3.3 o Added reference to CORS for JS clients to user_info and check_id endpoints -07 o Removed definition and usage for assertion and claim object o Removed Request File Registration Service o Consistent use of End-User o email scope allows access to the 'verified' claim o Removed language pertaining to custom userinfo schemas o Updated error section for refreshing access token Sakimura, et al. [Page 49] OpenID Connect Standard 1.0 August 2012 o Remove 'audience' parameter from Authorization Request o Moved display=none to prompt=none o Moved IANA considerations from Messages o Check ID Endpoint returns only JSON o Removed PPID scope value o Reference Messages for validation of request object encryption and signature o Redefined 'nonce' in Authorization Request. Changed to REQUIRED parameter. o Changed usage of "approval" to "consent" o Use RFC 6125 to verify TLS endpoints o Added Privacy considerations o Changed 'request_uri' to require HTTPS unless the referenced content is signed and only needs to be reachable by AS o Added hash and entropy considerations to 'request_uri' o Added requirement to compare user_id from userinfo endpoint to id_token o Check ID Endpoint SHOULD use POST o Changed UserInfo Error Response to augment and return OAuth 2.0 Bearer Token Error Response o Added section about string comparison rules needed o Added Response Encoding according to Multiple Response Types spec o Allows only 'id_token' for 'response_type' parameter in Authorization Request o Clarified redirect_uris matching o Added explanation of select_account o Changed Security Considerations to refer to corresponding section in Messages Sakimura, et al. [Page 50] OpenID Connect Standard 1.0 August 2012 o Check ID Endpoint uses ID Token as Access Token according to Bearer Token spec o Update John Bradley email and affiliation for Implementer's Draft o Removed invalid_authorization_code, invalid_id_token error codes -06 o Reworked return type wording in section 4.4.1 per ticket #174. o Added reference to registered return types. o Bumped Version number and date. o Make clear the server passes the value of nonce through untouched. Ticket #97. o Prevent caching of request_uri. Ticket #148. o Add nonce to request examples. Ticket #147. o Fixed 4.3.1.3 per ticket #150. o Fixed 4.3.2 to remove display scopes per ticket #172. o Make scope optional for refresh in 5.2. o Reference messages 3.2.2 for field definitions in section 5.2.1 per ticket #159. o Removed scopes from display value in 4.3.1 per ticket #172. o Make "code" and "id_token token" response types mandatory for Authorization Servers to support. -05 o Changed check_session to check_id. o schema=openid now required when requesting UserInfo. o Removed display values popup, touch, and mobile, since not well defined. o Resolve issue #135, clarifying that the access_token MAY be sent in the message body. Sakimura, et al. [Page 51] OpenID Connect Standard 1.0 August 2012 -04 o Changes associated with renaming "Lite" to "Basic Client" and replacing "Core" and "Framework" with "Messages" and "Standard". o Numerous cleanups, including updating references. -03 o Added secret_type to the Token Endpoint. o Minor edits to the samples. -02 o Incorporates feedback from Nat Sakimura. -01 o First Draft that incorporates the merge of the Core and Framework specs. Sakimura, et al. [Page 52] OpenID Connect Standard 1.0 August 2012 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 Sakimura, et al. [Page 53]