Draft M. Jones Microsoft February 19, 2016 OpenID Connect Front-Channel Logout 1.0 - draft 00 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 specification defines a logout mechanism that uses front-channel communication via the User Agent between the OP and RPs being logged out that does not need an OpenID Provider iframe on Relying Party pages. Other protocols have used HTTP GETs to RP URLs that clear login state to achieve this. This specification does the same thing. It also reuses the RP-initiated logout functionality specified in Section 5 of OpenID Connect Session Management 1.0 (RP-Initiated Logout). Jones [Page 1] OpenID Connect Front-Channel Logout 1.0 February 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Relying Party Logout Functionality . . . . . . . . . . . . . . 5 3. OpenID Provider Logout Functionality . . . . . . . . . . . . . 7 4. RP-Initiated Logout Functionality . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.1. JSON Web Token Claims Registration . . . . . . . . . . . . 10 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 10 6.2. OAuth Dynamic Client Registration Metadata Registration . 10 6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix B. Notices . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix C. Document History . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Jones [Page 2] OpenID Connect Front-Channel Logout 1.0 February 2016 1. Introduction OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] 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 logout mechanism that uses front-channel communication via the User Agent between the OP and RPs being logged out that does not need an OpenID Provider iframe on Relying Party pages, as OpenID Connect Session Management 1.0 [OpenID.Session] does. Other protocols have used HTTP GETs to RP URLs that clear login state to achieve this. This specification does the same thing. It also reuses the RP-initiated logout functionality specified in Section 5 of OpenID Connect Session Management 1.0 (RP-Initiated Logout). In contrast, the OpenID Connect Back-Channel Logout 1.0 [OpenID.BackChannel] specification uses direct back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent. This specification can be used separately from or in combination with OpenID Connect Session Management 1.0 and/or OpenID Connect Back- Channel Logout 1.0. 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 RFC 2119 [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". 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 Owner", "Resource Server", "Response Type", and "Token Jones [Page 3] OpenID Connect Front-Channel Logout 1.0 February 2016 Endpoint" defined by OAuth 2.0 [RFC6749], the term "User Agent" defined by RFC 7230 [RFC7230], and the terms defined by OpenID Connect Core 1.0 [OpenID.Core]. This specification also defines the following terms: Session Continuous period of time during which an End-User accesses a Relying Party relying on the Authentication of the End-User performed by the OpenID Provider. Session ID Identifier for a Session. Jones [Page 4] OpenID Connect Front-Channel Logout 1.0 February 2016 2. Relying Party Logout Functionality RPs supporting HTTP-based logout register a logout URI with the OP as part of their client registration. The domain, port, and scheme of this URL MUST be the same as that of a registered Redirection URI value. The logout URI MUST be an absolute URI as defined by Section 4.3 of [RFC3986]. The logout URI MAY include an "application/x-www-form-urlencoded" formatted query component, per Section 3.4 of [RFC3986], which MUST be retained when adding additional query parameters. The logout URI MUST NOT include a fragment component. The OP renders "