ISO/IEC 26136:2024

Information technology — OpenID connect — OpenID connect front-channel logout 1.0

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 document 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 document does the same thing.

Titre manque

General Information

• Status: Published
• Publication Date: 30-Sep-2024
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6060 - International Standard published
• Start Date: 01-Oct-2024
• Due Date: 14-Feb-2027
• Completion Date: 01-Oct-2024

Standards Content (Sample)

International
Standard
ISO/IEC 26136
First edition
Information technology — OpenID
2024-10
connect — OpenID connect front-
channel logout 1.0
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed
for the different types of document should be noted (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had
not received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall
not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the OpenID Foundation (OIDF) (as OpenID Connect Front-Channel
Logout 1.0) and drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS
procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2024 – All rights reserved
iii
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.

© ISO/IEC 2024 – All rights reserved
iv
Table of Contents
1. Introduction
1.1. Requirements Notation and Conventions
1.2. Terminology
2. Relying Party Logout Functionality
3. OpenID Provider Logout Functionality
3.1. Example Front-Channel Logout URL Usage
4. Implementation Considerations
4.1. User Agents Blocking Access to Third-Party
Content
5. Security Considerations
6. IANA Considerations
6.1. JSON Web Token Claims Registration
6.1.1. Registry Contents
6.2. OAuth Dynamic Client Registration Metadata
Registration
6.2.1. Registry Contents
6.3. OAuth Authorization Server Metadata Registry
6.3.1. Registry Contents
7. References
7.1. Normative References
7.2. Informative References
© ISO/IEC 2024 – All rights reserved
v
Information technology — OpenID Connect — OpenID
Connect Front-Channel Logout 1.0

TOC
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.
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. The OpenID Connect
RP-Initiated Logout 1.0 [OpenID.RPInitiated] specification complements
these specifications by defining a mechanism for a Relying Party to
request that an OpenID Provider log out the End-User.
This specification can be used separately from or in combination with
OpenID Connect RP-Initiated Logout 1.0, OpenID Connect Session
Management 1.0, and/or OpenID Connect Back-Channel Logout 1.0.

TOC
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
© ISO/IEC 2024 – All rights reserved
HTML version of this specification, values to be taken literally are
indicated by the use of this fixed-width font.

TOC
1.2. Terminology
This specification uses the terms "Authorization Server", "Client", "Client
Identifier", and "Redirection URI" 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.
TOC
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 in a page</br> with the registered logout URI as the source to trigger the logout</br> actions by the RP. Upon receiving a request to render the logout URI in</br> an iframe, the RP clears state associated with the logged-in session,</br> including any cookies and HTML5 local storage. If the End-User is</br> already logged out at the RP when the logout request is received, the</br> logout is considered to have succeeded.</br> © ISO/IEC 2024 – All rights reserved</br> The OP MAY add these query parameters when rendering the logout</br> URI, and if either is included, both MUST be:</br> iss</br> Issuer Identifier for the OP issuing the front-channel logout</br> request.</br> sid</br> Identifier for the Session.</br> The RP MAY verify that any iss and sid parameters match the iss and</br> sid Claims in an ID Token issued for the current session or a recent</br> session of this RP with the OP and ignore the logout request if they do</br> not.</br> The RP's response SHOULD include the Cache-Control HTTP response</br> header field with a no-store value, keeping the response from being</br> cached to prevent cached responses from interfering with future logout</br> requests. An example of this is:</br> </br> Cache-Control: no-store</br> In the case that the RP is also an OP serving as an identity provider to</br> downstream logged-in sessions, it is desirable for the logout request to</br> the RP to likewise trigger downstream logout requests. This is achieved</br> by having the RP serve content in the iframe that contains logout</br> requests to the downstream sessions, which themselves are nested</br> iframes rendering the downstream logout URIs.</br> If the RP supports OpenID Connect Dynamic Client Registration 1.0</br> [OpenID.Registration], it uses this metadata value to register the logout</br> URI:</br> frontchannel_logout_uri</br> OPTIONAL. RP URL that will cause the RP</br> <b>...</b>