Draft N. Sakimura NAT.Consulting J. Bradley Yubico M. Jones Self-Issued Consulting B. de Medeiros Google C. Mortimore Disney December 15, 2023 OpenID Connect Implicit Client Implementer's Guide 1.0 - draft 30 Abstract OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. This OpenID Connect Implicit Client Implementer's Guide 1.0 contains a subset of the OpenID Connect Core 1.0 specification that is designed to be easy to read and implement for basic Web-based Relying Parties using the OAuth 2.0 Implicit Flow. This specification intentionally duplicates content from the Core specification to provide a self-contained implementer's guide for basic Web-based Relying Parties using the OAuth Implicit Flow. OpenID Providers and non-Web-based applications should instead consult the Core specification. Sakimura, et al. [Page 1] OpenID Connect Implicit Client Guide 1.0 December 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation and Conventions . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Implicit Flow . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1. Client Prepares Authentication Request . . . . . . . . 9 2.1.1.1. Request Parameters . . . . . . . . . . . . . . . . 10 2.1.2. Client Sends Request to Authorization Server . . . . . 14 2.1.3. Authorization Server Authenticates End-User . . . . . 15 2.1.4. Authorization Server Obtains End-User Consent/Authorization . . . . . . . . . . . . . . . . 15 2.1.5. Authorization Server Sends End-User Back to Client . . 15 2.1.5.1. End-User Grants Authorization . . . . . . . . . . 15 2.1.5.2. End-User Denies Authorization or Invalid Request . . . . . . . . . . . . . . . . . . . . . 16 2.1.5.3. Redirect URI Fragment Handling . . . . . . . . . . 17 2.2. ID Token . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.1. ID Token Validation . . . . . . . . . . . . . . . . . 21 2.2.2. Access Token Validation . . . . . . . . . . . . . . . 22 2.3. UserInfo Endpoint . . . . . . . . . . . . . . . . . . . . 23 2.3.1. UserInfo Request . . . . . . . . . . . . . . . . . . . 23 2.3.2. Successful UserInfo Response . . . . . . . . . . . . . 23 2.3.3. UserInfo Error Response . . . . . . . . . . . . . . . 24 2.4. Scope Values . . . . . . . . . . . . . . . . . . . . . . . 24 2.5. Standard Claims . . . . . . . . . . . . . . . . . . . . . 25 2.5.1. Address Claim . . . . . . . . . . . . . . . . . . . . 31 2.5.2. Claims Languages and Scripts . . . . . . . . . . . . . 32 2.5.3. Claim Stability and Uniqueness . . . . . . . . . . . . 33 3. Self-Issued OpenID Provider . . . . . . . . . . . . . . . . . 34 3.1. Self-Issued OpenID Provider Discovery . . . . . . . . . . 34 3.2. Self-Issued OpenID Provider Registration . . . . . . . . . 34 3.2.1. Providing Information with the "registration" Request Parameter . . . . . . . . . . . . . . . . . . 35 3.3. Self-Issued OpenID Provider Request . . . . . . . . . . . 35 3.4. Self-Issued OpenID Provider Response . . . . . . . . . . . 36 3.5. Self-Issued ID Token Validation . . . . . . . . . . . . . 37 4. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1. Query String Serialization . . . . . . . . . . . . . . . . 39 4.2. Form Serialization . . . . . . . . . . . . . . . . . . . . 39 5. String Operations . . . . . . . . . . . . . . . . . . . . . . 40 6. Implementation Considerations . . . . . . . . . . . . . . . . 41 6.1. Discovery and Registration . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 42 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 43 Sakimura, et al. [Page 2] OpenID Connect Implicit Client Guide 1.0 December 2023 8.1. Personally Identifiable Information . . . . . . . . . . . 43 8.2. Data Access Monitoring . . . . . . . . . . . . . . . . . . 43 8.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . . 45 10.2. Informative References . . . . . . . . . . . . . . . . . . 48 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 49 Appendix B. Notices . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix C. Document History . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 Sakimura, et al. [Page 3] OpenID Connect Implicit Client Guide 1.0 December 2023 1. Introduction This OpenID Connect Implicit Client Implementer's Guide 1.0 contains a subset of the OpenID Connect Core 1.0 [OpenID.Core] specification that is designed to be easy to read and implement for basic Web-based Relying Parties using the OAuth [RFC6749] Implicit Flow. This specification intentionally duplicates content from the Core specification to provide a self-contained implementer's guide for basic Web-based Relying Parties using the OAuth Implicit Flow. Should there be any conflicts between the contents of this implementer's guide and the OpenID Connect Core specification, the latter takes precedence. See the OpenID Connect Basic Client Implementer's Guide 1.0 [OpenID.Basic] for a related guide for basic Web-based Relying Parties using the OAuth "authorization_code" grant type. OpenID Providers and non-Web-based applications should instead consult the Core specification. This guide omits implementation and security considerations for OpenID Providers and non-Web-based applications. As background, the OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Token Usage [RFC6750] specifications provide a general framework for third-party applications to obtain and use limited access to HTTP resources. They define mechanisms to obtain and use Access Tokens to access resources but do not define standard methods to provide identity information. Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. Readers are expected to be familiar with these specifications. OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. Use of this extension is requested by Clients by including the "openid" scope value in the Authorization Request. An Authorization Request using these extensions is called an Authentication Request. Information about the authentication performed is returned in a JSON Web Token (JWT) [JWT] called an ID Token (see Section 2.2). OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs). OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs). This specification assumes that the Relying Party has already obtained configuration information about the OpenID Provider, including its Authorization Endpoint location. This information is normally obtained via Discovery, as described in OpenID Connect Discovery 1.0 [OpenID.Discovery], or may be obtained via other mechanisms. Sakimura, et al. [Page 4] OpenID Connect Implicit Client Guide 1.0 December 2023 Likewise, this specification assumes that the Relying Party has already obtained sufficient credentials and provided information needed to use the OpenID Provider. This is normally done via Dynamic Registration, as described in OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration], or may be obtained via other mechanisms. 1.1. Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In the .txt version of this specification, 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. In the HTML version of this specification, values to be taken literally are indicated by the use of "this fixed-width font". All uses of JSON Web Signature (JWS) [JWS] data structures in this specification utilize the JWS Compact Serialization; the JWS JSON Serialization is not used. When the RFC 2119 language applies to the behavior of OpenID Providers, it is in this specification for explanatory value to help Client implementers understand the expected behavior of OpenID Providers. 1.2. Terminology This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Identifier", "Client Secret", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749], the terms "Claim Name", "Claim Value", "JSON Web Token (JWT)", and "JWT Claims Set" defined by JSON Web Token (JWT) [JWT], the terms "Header Parameter" and "JOSE Header" defined by JSON Web Signature (JWS) [JWS], and the term "User Agent" defined by RFC 7230 [RFC7230]. This specification also defines the following terms: Authentication Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity. Sakimura, et al. [Page 5] OpenID Connect Implicit Client Guide 1.0 December 2023 Authentication Request OAuth 2.0 Authorization Request using extension parameters and scopes defined by OpenID Connect to request that the End-User be authenticated by the Authorization Server, which is an OpenID Connect Provider, to the Client, which is an OpenID Connect Relying Party. Claim Piece of information asserted about an Entity. Claims Provider Server that can return Claims about an Entity. End-User Human participant. Entity Something that has a separate and distinct existence and that can be identified in a context. An End-User is one example of an Entity. ID Token JSON Web Token (JWT) [JWT] that contains Claims about the Authentication event. It MAY contain other Claims. Identifier Value that uniquely characterizes an Entity in a specific context. Issuer Entity that issues a set of Claims. Issuer Identifier Verifiable Identifier for an Issuer. An Issuer Identifier is a case-sensitive URL using the "https" scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components. OpenID Provider (OP) OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User. Pairwise Pseudonymous Identifier (PPID) Identifier that identifies the Entity to a Relying Party that cannot be correlated with the Entity's PPID at another Relying Party. Sakimura, et al. [Page 6] OpenID Connect Implicit Client Guide 1.0 December 2023 Personally Identifiable Information (PII) Information that (a) can be used to identify the natural person to whom such information relates, or (b) is or might be directly or indirectly linked to a natural person to whom such information relates. Relying Party (RP) OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider. Self-Issued OpenID Provider Personal, self-hosted OpenID Provider that issues self-signed ID Tokens. Subject Identifier Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client. UserInfo Endpoint Protected Resource that, when presented with an Access Token by the Client, returns authorized information about the End-User represented by the corresponding Authorization Grant. Validation Process intended to establish the soundness or correctness of a construct. Verification Process intended to test or prove the truth or accuracy of a fact or value. Voluntary Claim Claim specified by the Client as being useful but not Essential for the specific task requested by the End-User. IMPORTANT NOTE TO READERS: The terminology definitions in this section are a normative portion of this specification, imposing requirements upon implementations. All the capitalized words in the text of this specification, such as "Issuer Identifier", reference these defined terms. Whenever the reader encounters them, their definitions found in this section must be followed. 1.3. Overview The OpenID Connect protocol, in abstract, follows the following steps. Sakimura, et al. [Page 7] OpenID Connect Implicit Client Guide 1.0 December 2023 1. The RP (Client) sends a request to the OpenID Provider (OP). 2. The OP authenticates the End-User and obtains authorization. 3. The OP responds with an ID Token and usually an Access Token. 4. The RP can send a request with the Access Token to the UserInfo Endpoint. 5. The UserInfo Endpoint returns Claims about the End-User. These steps are illustrated in the following diagram: +--------+ +--------+ | | | | | |---------(1) AuthN Request-------->| | | | | | | | +--------+ | | | | | | | | | | | End- |<--(2) AuthN & AuthZ-->| | | | | User | | | | RP | | | | OP | | | +--------+ | | | | | | | |<--------(3) AuthN Response--------| | | | | | | |---------(4) UserInfo Request----->| | | | | | | |<--------(5) UserInfo Response-----| | | | | | +--------+ +--------+ Sakimura, et al. [Page 8] OpenID Connect Implicit Client Guide 1.0 December 2023 2. Protocol Elements Authentication Requests can follow one of three paths: the Authorization Code Flow, the Implicit Flow, or the Hybrid Flow. The Authorization Code Flow is intended for Clients that can securely maintain a Client Secret between themselves and the Authorization Server, whereas the Implicit Flow is intended for Clients that cannot. However, the Authorization Code flow is sometimes also used by Native applications and other Clients in order to be able to obtain a Refresh Token, even when they cannot ensure the secrecy of the Client Secret value. The Hybrid Flow combines aspects of the Authorization Code Flow and the Implicit Flow. It enables Clients to obtain an ID Token optionally an Access Token with only one round trip to the Authorization Server, possibly minimizing latency, while still enabling Clients to later get tokens from the Token Endpoint -- especially a Refresh Token. This specification only provides information that is sufficient for basic Clients using the Implicit Flow. 2.1. Implicit Flow The Implicit Flow consists of the following steps: 1. Client prepares an Authentication Request containing the desired request parameters. 2. Client sends the request to the Authorization Server. 3. Authorization Server authenticates the End-User. 4. Authorization Server obtains End-User Consent/Authorization. 5. Authorization Server sends the End-User back to the Client with an ID Token and, if requested, an Access Token. 6. Client validates the tokens and retrieves the End-User's Subject Identifier. 2.1.1. Client Prepares Authentication Request When the RP wishes to Authenticate the End-User or determine whether the End-User is already Authenticated, the Client prepares an Authentication Request to be sent to the Authorization Endpoint. Communication with the Authorization Endpoint MUST utilize TLS. See Section 7.1 for more information on using TLS. Sakimura, et al. [Page 9] OpenID Connect Implicit Client Guide 1.0 December 2023 Clients MAY construct the request using the HTTP "GET" or the HTTP "POST" method as defined in RFC 7231 [RFC7231]. If using the HTTP "GET" method, the parameters are serialized using the Query String Serialization, per Section 4.1. If using the HTTP "POST" method, the request parameters are added to the HTTP request entity-body using the "application/x-www-form-urlencoded" format as defined by [W3C.SPSD-html401-20180327]. The following is a non-normative example of an Authentication Request URL (with line wraps within values for display purposes only): https://server.example.com/authorize? response_type=id_token%20token &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=openid%20profile &state=af0ifjsldkj &nonce=n-0S6_WzA2Mj 2.1.1.1. Request Parameters This subset of OpenID Connect uses the following OAuth 2.0 request parameters: response_type REQUIRED. This value consists of "id_token" and "token", as a space-delimited list. This requests that both an Access Token and an ID Token be returned from the Authorization Endpoint, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. client_id REQUIRED. OAuth 2.0 Client Identifier valid at the Authorization Server. scope REQUIRED. OpenID Connect requests MUST contain the "openid" scope value. OPTIONAL scope values of "profile", "email", "address", "phone", and "offline_access" are also defined. See Section 2.4 for more about the scope values defined by this specification. redirect_uri REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The Redirection URI MUST NOT use the Sakimura, et al. [Page 10] OpenID Connect Implicit Client Guide 1.0 December 2023 "http" scheme unless the Client is a native application, in which case it MAY use the "http" scheme with "localhost" or the IP loopback literals "127.0.0.1" or "[::1]" as the hostname. state RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie. This specification also defines the following request parameters: nonce REQUIRED. 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 Authentication Request to the ID Token. Sufficient entropy MUST be present in the "nonce" values used to prevent attackers from guessing values. One method to achieve this is to store a cryptographically random value in HTML5 local storage and use a cryptographic hash of the value as the "nonce" parameter. In that case, the "nonce" in the returned ID Token is compared to the hash of the value in local storage to detect ID Token replay by third parties. display OPTIONAL. ASCII [RFC20] string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User. The defined values are: page The Authorization Server SHOULD display the authentication and consent UI consistent with a full User Agent page view. If the display parameter is not specified, this is the default display mode. popup The Authorization Server SHOULD display the authentication and consent UI consistent with a popup User Agent window. The popup User Agent window should be of an appropriate size for a login-focused dialog and should not obscure the entire window that it is popping up over. touch The Authorization Server SHOULD display the authentication and consent UI consistent with a device that leverages a touch interface. Sakimura, et al. [Page 11] OpenID Connect Implicit Client Guide 1.0 December 2023 wap The Authorization Server SHOULD display the authentication and consent UI consistent with a "feature phone" type display. The Authorization Server MAY also attempt to detect the capabilities of the User Agent and present an appropriate display. If an OP receives a "display" value outside the set defined above that it does not understand, it MAY return an error or it MAY ignore it; in practice, not returning errors for not-understood values will help facilitate phasing in extensions using new "display" values. prompt OPTIONAL. Space-delimited, case-sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent. The defined values are: none The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if an End- User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request. The error code will typically be "login_required", "interaction_required". This can be used as a method to check for existing authentication and/or consent. login The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot reauthenticate the End-User, it MUST return an error, typically "login_required". consent The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client. If it cannot obtain consent, it MUST return an error, typically "consent_required". select_account The Authorization Server SHOULD prompt the End-User to select a user account. This enables an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for. If it cannot obtain an account selection choice made by the End-User, it MUST return an error, typically "account_selection_required". Sakimura, et al. [Page 12] OpenID Connect Implicit Client Guide 1.0 December 2023 The "prompt" parameter can be used by the Client to make sure that the End-User is still present for the current session or to bring attention to the request. If this parameter contains "none" with any other value, an error is returned. If an OP receives a "prompt" value outside the set defined above that it does not understand, it MAY return an error or it MAY ignore it; in practice, not returning errors for not-understood values will help facilitate phasing in extensions using new "prompt" values. max_age OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User. When "max_age" is used, the ID Token returned MUST include an "auth_time" Claim Value. Note that "max_age=0" is equivalent to "prompt=login". ui_locales OPTIONAL. End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference. For instance, the value "fr-CA fr en" represents a preference for French as spoken in Canada, then French (without a region designation), followed by English (without a region designation). An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider. claims_locales OPTIONAL. End-User's preferred languages and scripts for Claims being returned, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference. An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider. id_token_hint OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error. When possible, an "id_token_hint" SHOULD be present when "prompt=none" is used and an "invalid_request" error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an Sakimura, et al. [Page 13] OpenID Connect Implicit Client Guide 1.0 December 2023 audience of the ID Token when it is used as an "id_token_hint" value. login_hint OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the "phone_number" Claim. The use of this parameter is left to the OP's discretion. acr_values OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the "acr" values that the Authorization Server is being requested to use for processing this authentication request, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the "acr" Claim Value, as specified in Section 2.2. The "acr" Claim is requested as a Voluntary Claim by this parameter. registration OPTIONAL. This parameter is used by the Client to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration, as specified in Section 3.2.1. 2.1.2. Client Sends Request to Authorization Server Having constructed the Authentication Request, the Client sends it to the Authorization Endpoint using HTTPS. The following is a non-normative example HTTP 302 redirect response by the Client, which triggers the User Agent to make an Authentication Request to the Authorization Endpoint (with line wraps within values for display purposes only): HTTP/1.1 302 Found Location: https://server.example.com/authorize? response_type=id_token%20token &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=openid%20profile &state=af0ifjsldkj &nonce=n-0S6_WzA2Mj Sakimura, et al. [Page 14] OpenID Connect Implicit Client Guide 1.0 December 2023 The following is the non-normative example request that would be sent by the User Agent to the Authorization Server in response to the HTTP 302 redirect response by the Client above (with line wraps within values for display purposes only): GET /authorize? response_type=id_token%20token &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=openid%20profile &state=af0ifjsldkj &nonce=n-0S6_WzA2Mj HTTP/1.1 Host: server.example.com 2.1.3. Authorization Server Authenticates End-User The Authorization Server logs in the End-User or verifies whether the End-User is logged in, depending upon the request parameter values used. If interaction with the End-User occurs over an HTTP channel, it MUST use TLS, as per Section 7.1. The exact authentication methods used are out of scope for this specification. 2.1.4. Authorization Server Obtains End-User Consent/Authorization The Authorization Server obtains an authorization decision for the requested Claims. This can be done by presenting the End-User with a dialogue that enables the End-User to recognize what is being consenting to and grant consent or by establishing consent via other means (for example, via previous administrative consent). The "openid" scope value declares that this OAuth 2.0 request is an OpenID Connect request. Use of all other scope values is OPTIONAL. 2.1.5. Authorization Server Sends End-User Back to Client Once the authorization is determined, the Authorization Server returns a successful response or an error response. 2.1.5.1. End-User Grants Authorization If the End-User grants the access request, the Authorization Server issues an Access Token and delivers it to the Client by adding the following parameters to the fragment component of the Redirection URI using the "application/x-www-form-urlencoded" format as defined in Section 4.2.2 of OAuth 2.0 [RFC6749] and OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. In the Implicit Flow, the entire response is returned in the fragment Sakimura, et al. [Page 15] OpenID Connect Implicit Client Guide 1.0 December 2023 component of the Redirection URI, as defined in Section 4.2.2 of OAuth 2.0 [RFC6749]. access_token REQUIRED. Access Token for the UserInfo Endpoint. token_type REQUIRED. OAuth 2.0 Token Type value. The value MUST be "Bearer", as specified in OAuth 2.0 Bearer Token Usage [RFC6750], for Clients using this subset. Note that the "token_type" value is case insensitive. id_token REQUIRED. ID Token. state OAuth 2.0 state value. REQUIRED if the "state" parameter is present in the Authorization Request. Clients MUST verify that the "state" value is equal to the value of "state" parameter in the Authorization Request. expires_in OPTIONAL. Expiration time of the Access Token in seconds since the response was generated. The Client can then use the Access Token to access protected resources at Resource Servers. 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# access_token=SlAV32hkKG &token_type=bearer &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso &expires_in=3600 &state=af0ifjsldkj 2.1.5.2. End-User Denies Authorization or Invalid Request Whenever Error Response parameters are returned, such as when End- User denies the authorization or the End-User authentication fails, the Authorization Server MUST return the error Authorization Response in the fragment component of the Redirection URI, as defined in Section 4.2.2.1 of OAuth 2.0 [RFC6749]. (HTTP errors unrelated to RFC 6749 are returned to the User Agent using the appropriate HTTP status code.) Sakimura, et al. [Page 16] OpenID Connect Implicit Client Guide 1.0 December 2023 2.1.5.3. Redirect URI Fragment Handling Since response parameters are returned in the Redirection URI fragment value, the Client needs to have the User Agent parse the fragment encoded values and pass them to on to the Client's processing logic for consumption. User Agents that have direct access to cryptographic APIs may be able to be self-contained, for instance, with all Client code being written in JavaScript. However, if the Client does not run entirely in the User Agent, one way to achieve this is to post them to a Web Server Client for validation. The following is an example of a JavaScript file that a Client might host at its "redirect_uri". This is loaded by the redirect from the Authorization Server. The fragment component is parsed and then sent by "POST" to a URI that will validate and use the information received. Sakimura, et al. [Page 17] OpenID Connect Implicit Client Guide 1.0 December 2023 Following is a non-normative example of a Redirect URI response: GET /cb HTTP/1.1 Host: client.example.org HTTP/1.1 200 OK Content-Type: text/html