Microsoft

mbj@microsoft.com https://self-issued.info/

Google

breno@google.com https://stackoverflow.com/users/311376/breno

Microsoft

Naveen.Agarwal@microsoft.com https://www.linkedin.com/in/nvnagr

NAT.Consulting

nat@nat.consulting https://nat.sakimura.org/

Yubico

ve7jtb@ve7jtb.com http://www.thread-safe.com/

OpenID Connect Working Group 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 specification defines a mechanism for a Relying Party to request that an OpenID Provider log out the End-User.

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 specification complements the OpenID Connect Core 1.0 specification by enabling the Relying Party to request that an End-User be logged out by the OpenID Provider. This specification can be used separately from or in combination with OpenID Connect Session Management 1.0, OpenID Connect Front-Channel Logout 1.0, and/or OpenID Connect Back-Channel Logout 1.0.

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 RFC 2119. In the .txt version of 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. In the HTML version of this document, values to be taken literally are indicated by the use of this fixed-width font.

This specification uses the terms "Authorization Endpoint", "Authorization Server", "Client", and "Client Identifier" defined by OAuth 2.0, the term "User Agent" defined by RFC 7230, and the terms defined by OpenID Connect Core 1.0. 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 "Relying Party", reference these defined terms. Whenever the reader encounters them, their definitions found in this section must be followed. This specification also defines the following term: The endpoint at the OpenID Provider that is the target of RP-Initiated Logout requests.

An RP requests that the OP log out the End-User by redirecting the End-User's User Agent to the OP's Logout Endpoint. This URL is normally obtained via the end_session_endpoint element of the OP's Discovery response or may be learned via other mechanisms. This specification defines the following parameters that are used in the logout request at the Logout Endpoint: RECOMMENDED. ID Token previously issued by the OP to the RP passed to the Logout Endpoint as a hint about the End-User's current authenticated session with the Client. This is used as an indication of the identity of the End-User that the RP is requesting be logged out by the OP. OPTIONAL. Hint to the Authorization Server about the End-User that is logging out. The value and meaning of this parameter is left up to the OP's discretion. For instance, the value might contain an email address, phone number, username, or session identifier pertaining to the RP's session with the OP for the End-User. (This parameter is intended to be analogous to the login_hint parameter defined in Section 3.1.2.1 of OpenID Connect Core 1.0 that is used in Authentication Requests; whereas, logout_hint is used in RP-Initiated Logout Requests.) OPTIONAL. OAuth 2.0 Client Identifier valid at the Authorization Server. When both client_id and id_token_hint are present, the OP MUST verify that the Client Identifier matches the one used when issuing the ID Token. The most common use case for this parameter is to specify the Client Identifier when post_logout_redirect_uri is used but id_token_hint is not. Another use is for symmetrically encrypted ID Tokens used as id_token_hint values that require the Client Identifier to be specified by other means, so that the ID Tokens can be decrypted by the OP. OPTIONAL. URI to which the RP is requesting that the End-User's User Agent be redirected after a logout has been performed. This URI SHOULD use the https scheme and MAY contain port, path, and query parameter components; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http RP URIs. The URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application. The value MUST have been previously registered with the OP, either using the post_logout_redirect_uris Registration parameter or via another mechanism. An id_token_hint is also RECOMMENDED when this parameter is included. OPTIONAL. Opaque value used by the RP to maintain state between the logout request and the callback to the endpoint specified by the post_logout_redirect_uri parameter. If included in the logout request, the OP passes this value back to the RP using the state parameter when redirecting the User Agent back to the RP. OPTIONAL. End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 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. OpenID Providers MUST support the use of the HTTP GET and POST methods defined in RFC 7231 at the Logout Endpoint. RPs MAY use the HTTP GET or POST methods to send the logout request to the OP. If using the HTTP GET method, the request parameters are serialized using URI Query String Serialization. If using the HTTP POST method, the request parameters are serialized using Form Serialization. When an id_token_hint parameter is present, the OP MUST validate that it was the issuer of the ID Token. The OP SHOULD accept ID Tokens when the RP identified by the ID Token's aud claim and/or sid claim has a current session or had a recent session at the OP, even when the exp time has passed. If the ID Token's sid claim does not correspond to the RP's current session or a recent session at the OP, the OP SHOULD treat the logout request as suspect, and MAY decline to act upon it. At the Logout Endpoint, the OP SHOULD ask the End-User whether to log out of the OP as well. Furthermore, the OP MUST ask the End-User this question if an id_token_hint was not provided or if the supplied ID Token does not belong to the current OP session with the RP and/or currently logged in End-User. If the End-User says "yes", then the OP MUST log out the End-User. As part of the OP logging out the End-User, the OP uses the logout mechanism(s) registered by the RPs to notify any RPs logged in as that End-User that they are to likewise log out the End-User. RPs can use any of OpenID Connect Session Management 1.0, OpenID Connect Front-Channel Logout 1.0, and/or OpenID Connect Back-Channel Logout 1.0 to receive logout notifications from the OP, depending upon which of these mechanisms the OP and RPs mutually support. The RP initiating the logout is to be included in these notifications before the post-logout redirection defined in is performed. It is up to the RP whether to locally log out the End-User before redirecting the User Agent to the OP's Logout Endpoint. On one hand, if the End-User approves the logout at the OP, the RP initiating the logout should receive a logout message from the OP and can perform a local logout at that time. On the other hand, some logout notification methods from the OP to the RP are unreliable and therefore the notification might not be received. Also, the End-User might not approve the OP logging out, in which case the RP would not receive a logout notification.

To support OpenID Connect RP-Initiated Logout, the RP needs to obtain the RP-Initiated Logout related OP metadata. This OP metadata is normally obtained via the OP's Discovery response, as described in OpenID Connect Discovery 1.0, or MAY be learned via other mechanisms. This OpenID Provider Metadata parameter MUST be included in the Server's discovery responses when RP-Initiated Logout and Discovery are supported: REQUIRED. URL at the OP to which an RP can perform a redirect to request that the End-User be logged out at the OP. This URL MUST use the https scheme and MAY contain port, path, and query parameter components.

In some cases, the RP will request that the End-User's User Agent to be redirected back to the RP after a logout has been performed. Post-logout redirection is only done when the logout is RP-initiated, in which case the redirection target is the post_logout_redirect_uri parameter value sent by the initiating RP. An id_token_hint carring an ID Token for the RP is also RECOMMENDED when requesting post-logout redirection; if it is not supplied with post_logout_redirect_uri, the OP MUST NOT perform post-logout redirection unless the OP has other means of confirming the legitimacy of the post-logout redirection target. The OP also MUST NOT perform post-logout redirection if the post_logout_redirect_uri value supplied does not exactly match one of the previously registered post_logout_redirect_uris values. The post-logout redirection is performed after the OP has finished notifying the RPs that logged in with the OP for that End-User that they are to log out the End-User. This specification defines this Dynamic Registration parameter for this purpose, per Section 2.1 of OpenID Connect Dynamic Client Registration 1.0.

This Client Metadata parameter MAY be included in the Client's Registration information when RP-Initiated Logout and Dynamic Registration are supported: OPTIONAL. Array of URLs supplied by the RP to which it MAY request that the End-User's User Agent be redirected using the post_logout_redirect_uri parameter after a logout has been performed. These URLs SHOULD use the https scheme and MAY contain port, path, and query parameter components; however, they MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http RP URIs.

If any of the validation procedures defined in this specification fail, any operations requiring the information that failed to correctly validate MUST be aborted and the information that failed to validate MUST NOT be used. Note that because RP-Initiated Logout Requests are intended to be idempotent, it is explicitly not an error for an RP to request that a logout be performed when the OP does not consider that the End-User is logged in with the OP at the requesting RP. As described in , when the OP detects errors in the RP-Initiated Logout request, the OP MUST not perform post-logout redirection to an RP. Beyond that, the OP has discretion on what information to display to the End-User in the resulting page at the OP and what actions to enable the End-User to perform next. It MAY display an error message. It MAY ask the End-User whether to log out of the OP. Note that giving the End-User the opportunity to log out may have security benefits, especially in kiosk scenarios. The End-User initiating a logout action at the RP may expect to be completely logged out, including from the OP. Not giving the End-User the opportunity to log out at the OP and leaving the End-User logged in would likely violate the End-User's security expectations about being completely logged out.

This specification defines features used by both Relying Parties and OpenID Providers that choose to implement RP-Initiated Logout. All of these Relying Parties and OpenID Providers MUST implement the features that are listed in this specification as being "REQUIRED" or are described with a "MUST". No other implementation considerations for implementations of RP-Initiated Logout are defined by this specification.

Logout requests without a valid id_token_hint value are a potential means of denial of service; therefore, OPs should obtain explicit confirmation from the End-User before acting upon them.

This specification registers the following metadata name in the IANA "OAuth Authorization Server Metadata" registry established by .

Metadata Name: end_session_endpoint Metadata Description: URL at the OP to which an RP can perform a redirect to request that the End-User be logged out at the OP Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document

This specification registers the following client metadata definition in the IANA "OAuth Dynamic Client Registration Metadata" registry established by :

Client Metadata Name: post_logout_redirect_uris Client Metadata Description: Array of URLs supplied by the RP to which it MAY request that the End-User's User Agent be redirected using the post_logout_redirect_uri parameter after a logout has been performed Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. Nomura Research Institute, Ltd. Ping Identity Microsoft Google Salesforce Nomura Research Institute, Ltd. Ping Identity Microsoft Illumila Nomura Research Institute, Ltd. Ping Identity Microsoft Google Microsoft NAT.Consulting Yubico Microsoft Microsoft Microsoft Yubico IANA This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

The OpenID Community would like to thank the following people for their contributions to this specification: Naveen Agarwal (Naveen.Agarwal@microsoft.com), Microsoft Amanda Anganes (aanganes@mitre.org), MITRE John Bradley (ve7jtb@ve7jtb.com), Yubico Breno de Medeiros (breno@google.com), Google Vladimir Dzhuvinov (vladimir@connect2id.com), Connect2id George Fletcher (gffletch@aol.com), Capital One Roland Hedberg (roland@catalogix.se), Independent Edmund Jay (ejay@mgi1.com), Illumila Michael B. Jones (mbj@microsoft.com), Microsoft Todd Lainhart (lainhart@us.ibm.com), IBM Torsten Lodderstedt (torsten@lodderstedt.net), yes.com Anthony Nadalin (nadalin@prodigy.net), Independent Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom Justin Richer (justin@bspk.io), Bespoke Engineering Nat Sakimura (nat@nat.consulting), NAT.Consulting Filip Skokan (panva.ip@gmail.com), Auth0 Hans Zandbelt (hans.zandbelt@zmartzone.eu), ZmartZone

Copyright (c) 2022 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.