ISO/IEC 26137:2024

Information technology - OpenID connect - OpenID connect back-channel logout 1.0 incorporating errata set 1

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 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.

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

Overview - ISO/IEC 26137:2024 (OpenID Connect Back-Channel Logout 1.0)

ISO/IEC 26137:2024 standardizes an OpenID Connect back-channel logout mechanism (incorporating errata set 1). Built on OpenID Connect 1.0 and OAuth 2.0, it defines how an OpenID Provider (OP) can reliably notify Relying Parties (RPs) to terminate user sessions via direct server-to-server calls rather than via the end-user’s browser (front-channel). The standard specifies the format, delivery, and validation of a signed JSON Web Token (JWT) - the Logout Token - used to request logout, plus related discovery and registration metadata.

Key technical topics and requirements

• Logout Token (JWT):
  • Must be signed; may be encrypted.
  • Required claims: iss, aud, iat, exp, jti, events (containing http://schemas.openid.net/event/backchannel-logout).
  • Session identification: must include either sub (subject) or sid (session id) - can include both.
  • Prohibited: nonce claim MUST NOT be present.
  • Recommended to include JWT header typ of logout+jwt; default signing alg is RS256 and alg "none" is disallowed.
• Back-channel delivery:
  • OP triggers logout via HTTP POST to a registered backchannel_logout_uri using application/x-www-form-urlencoded with a logout_token parameter.
  • OPs SHOULD avoid unnecessary retransmission and should retry only on recoverable errors with appropriate delays.
• Discovery & registration metadata:
  • OP advertises support with backchannel_logout_supported and optional backchannel_logout_session_supported in OpenID Provider metadata.
  • RPs register backchannel_logout_uri and may set backchannel_logout_session_required via dynamic client registration.
• Validation and processing:
  • RPs MUST validate signature/encryption and standard claims (iss, aud, iat, exp, jti, events, sub/sid).
  • RPs must implement application-specific session termination logic because browser state (cookies/local storage) is not available on the back-channel.

Practical applications and who should use this standard

• Identity providers (OPs) and SSO platform vendors implementing robust logout semantics across federated services.
• Relying parties (RPs) and web application architects that require reliable server-to-server logout notifications (e.g., enterprise SSO, banking, regulated sectors).
• Security architects, IAM teams, and developers integrating OpenID Connect with centralized session management across distributed systems.
• Use cases where browser-based front-channel logout is unreliable (background sessions, closed tabs) or where direct server-to-server confirmation is required.

Related standards

• OpenID Connect Core 1.0 (ID Tokens, claims)
• OpenID Connect Discovery and Dynamic Client Registration
• OpenID Connect Front-Channel Logout 1.0 and Session Management 1.0
• OAuth 2.0 (RFC 6749), JSON Web Token (JWT)
• Security Event Token (SET) and relevant IANA/RFCs referenced in the standard

By adopting ISO/IEC 26137:2024, implementers can add a standardized, interoperable back-channel logout flow to improve reliability and control of federated session termination.

Standards Content (Sample)

International
Standard
ISO/IEC 26137
First edition
Information technology — OpenID
2024-10
connect — OpenID connect back-
channel logout 1.0 incorporating
errata set 1
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 Back-Channel Logout
1.0 incorporating errata set 1) 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 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.

© ISO/IEC 2024 – All rights reserved
iv
Table of Contents
1. Introduction
1.1. Requirements Notation and Conventions
1.2. Terminology
2. Back-Channel Logout
2.1. Indicating OP Support for Back-Channel Logout
2.2. Indicating RP Support for Back-Channel Logout
2.3. Remembering Logged-In RPs
2.4. Logout Token
2.5. Back-Channel Logout Request
2.6. Logout Token Validation
2.7. Back-Channel Logout Actions
2.8. Back-Channel Logout Response
3. Implementation Considerations
4. Security Considerations
4.1. Cross-JWT Confusion
5. IANA Considerations
5.1. OAuth Dynamic Client Registration Metadata
Registration
5.1.1. Registry Contents
5.2. OAuth Authorization Server Metadata Registry
5.2.1. Registry Contents
5.3. Media Type Registration
5.3.1. Registry Contents
6. References
6.1. Normative References
6.2. Informative References
© ISO/IEC 2024 – All rights reserved
v
Information technology — OpenID Connect — OpenID
Connect Back-Channel Logout 1.0 incorporating errata set 1

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 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.
An upside of back-channel communication is that it can be more reliable
than communication through the User Agent, since in the front-channel,
the RP's browser session must be active for the communication to
succeed. (If the RP's browser tab was subsequently used to navigate to
an unrelated page, the RP session will be active unless the user uses
the back button to return to it.) Both the OpenID Connect Session
Management 1.0 [OpenID.Session] and OpenID Connect Front-Channel
Logout 1.0 [OpenID.FrontChannel] specifications use front-channel
communication, which communicate logout requests from the OP to RPs
via the User Agent.
A downside of back-channel communication is that the session state
maintained between the OP and RP over the front-channel, such as
cookies and HTML5 local storage, are not available when using back-
channel communication. As a result, all needed state must be explicitly
communicated between the parties. Furthermore, RPs must implement
an application-specific method of terminating RP sessions with the OP
upon receiving back-channel logout requests; this can be more
complicated than simply clearing cookies and HTML5 local storage state,
which is often all that has to happen to implement logout in response to
front-channel logout requests.
Another significant limitation of back-channel logout is that the RP's
back-channel logout URI must be reachable from all the OPs used. This
means, for instance, that the RP cannot be behind a firewall or NAT
when used with public OPs.
© ISO/IEC 2024 – All rights reserved
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 Front-Channel Logout 1.0.
The previous version of this specification is:
• OpenID Connect Back-Channel Logout 1.0 (final)
[OpenID.BackChannel.Final]
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
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", and
"Client Identifier" defined by OAuth 2.0 [RFC6749], the term "User
Agent" defined by RFC 7230 [RFC7230], the terms "Session" and
"Session ID" defined by OpenID Connect Front-Channel Logout 1.0
[OpenID.FrontChannel] and the terms defined by OpenID Connect Core
1.0 [OpenID.Core] and JSON Web Token (JWT) [JWT].
This specification also defines the following term:
Logout Token
JSON Web Token (JWT) [JWT] similar to an ID Token that
contains Claims about the logout action being requested.
© ISO/IEC 2024 – All rights reserved
TOC
2. Back-Channel Logout
TOC
2.1. Indicating OP Support for Back-Channel Logout
If the OpenID Provider supports OpenID Connect Discovery 1.0
[OpenID.Discovery], it uses this metadata value to advertise its support
for back-channel logout:
backchannel_logout_supported
OPTIONAL. Boolean value specifying whether the OP
supports back-channel logout, with true indicating support.
If omitted, the default value is false.
It SHOULD also register this related metadata value:
backchannel_logout_session_supported
OPTIONAL. Boolean value specifying whether the OP can
pass a sid (session ID) Claim in the Logout Token to identify
the RP session with the OP. If supported, the sid Claim is
also included in ID Tokens issued by the OP. If omitted, the
default value is false.
The sid (session ID) Claim used in ID Tokens and as a Logout Token
parameter has the following definition (which is identical to the
corresponding definition in OpenID Connect Front-Channel Logout 1.0
[OpenID.FrontChannel]):
sid
OPTIONAL. Session ID - String identifier for a Session. This
represents a Session of a User Agent or device for a logged-
in End-User at an RP. Different sid values are used to
identify distinct sessions at an OP. The sid value need only
be unique in the context of a particular issuer. Its contents
are opaque to the RP. Its syntax is the same as an OAuth
2.0 Client Identifier.
© ISO/IEC 2024 – All rights reserved
TOC
2.2. Indicating RP Support for Back-Channel Logout
Relying Parties supporting back-channel-based logout register a back-
channel logout URI with the OP as part of their client registration.
The back-channel logout URI MUST be an absolute URI as defined by
Section 4.3 of [RFC3986]. The back-channel 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 back-channel logout URI MUST NOT
include a fragment component.
If the RP supports OpenID Connect Dynamic Client Registration 1.0
[OpenID.Registration], it uses this metadata value to register the back-
channel logout URI:
backchannel_logout_uri
OPTIONAL. RP URL that will cause the RP to log itself out
when sent a Logout Token by the OP. This URL 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 [RFC6749], and provided
the OP allows the use of http RP URIs.
It SHOULD also register this related metadata value:
backchannel_logout_session_required
OPTIONAL. Boolean value specifying whether the RP
requires that a sid (session ID) Claim be included in the
Logout Token to identify the RP session with the OP when
the backchannel_logout_uri is used. If omitted, the
default value is false.
TOC
2.3. Remembering Logged-In RPs
OPs supporting back-channel logout need to keep track of the set of
logged-in RPs so that they know what RPs to contact at their back-
channel logout URIs to cause them to log out. Some OPs track this state
© ISO/IEC 2024 – All rights reserved
using a "visited sites" cookie. OPs are encouraged to send logout
requests to them in parallel.
TOC
2.4. Logout Token
OPs send a JWT similar to an ID Token to RPs called a Logout Token to
request that they log out. ID Tokens are defined in Section 2 of
[OpenID.Core].
The following Claims are used within the Logout Token:
iss
REQUIRED. Issuer Identifier, as specified in Section 2 of
[OpenID.Core].
sub
OPTIONAL. Subject Identifier, as specified in Section 2 of
[OpenID.Core].
aud
REQUIRED. Audience(s), as specified in Section 2 of
[OpenID.Core].
iat
REQUIRED. Issued at time, as specified in Section 2 of
[OpenID.Core].
exp
REQUIRED. Expiration time, as specified in Section 2 of
[OpenID.Core].
jti
REQUIRED. Unique identifier for the token, as specified in
Section 9 of [OpenID.Core].
events
REQUIRED. Claim whose value is a JSON object containing
the member name
http://schemas.openid.net/event/backchannel-
logout. This declares that the JWT is a Logout Token. The
© ISO/IEC 2024 – All rights reserved
corresponding member value MUST be a JSON object and
SHOULD be the empty JSON object {}.
sid
OPTIONAL. Session ID - String identifier for a Session. This
represents a Session of a User Agent or device for a logged-
in End-User at an RP. Different sid values are used to
identify distinct sessions at an OP. The sid value need only
be unique in the context of a particular issuer. Its contents
are opaque to the RP. Its syntax is the same as an OAuth
2.0 Client Identifier.
A Logout Token MUST contain either a sub or a sid Claim, and MAY
contain both. If a sid Claim is not present, the intent is that all sessions
at the RP for the End-User identified by the iss and sub Claims be
logged out.
The following Claim MUST NOT be used within the Logout Token:
nonce
PROHIBITED. A nonce Claim MUST NOT be present. Its use
is prohibited to make a Logout Token syntactically invalid if
used in a forged Authentication Response in place of an ID
Token.
Logout Tokens MAY contain other Claims. Any Claims used that are not
understood MUST be ignored.
A Logout Token MUST be signed and MAY also be encrypted. The same
keys are used to sign and encrypt Logout Tokens as are used for ID
Tokens. If the Logout Token is encrypted, it SHOULD replicate the iss
(issuer) claim in the JWT Header Parameters, as specified in Section 5.3
of [JWT].
It is RECOMMENDED that Logout Tokens be explicitly typed. This is
accomplished by including a typ (type) Header Parameter with a value
of logout+jwt in the Logout Token. See Section 4.1 for a discussion of
the security and interoperability considerations of using explicit typing.
NOTE: The Logout Token is compatible with the Security Event Token
(SET) [RFC8417] specification, but uses a more specific typ (type)
value.
A non-normative example JWT Claims Set for a Logout Token follows:

{
"iss": "https://server.example.com",
"sub": "248289761001",
© ISO/IEC 2024 – All rights reserved
"aud": "s6BhdRkqt3",
"iat": 1471566154,
"exp": 1471569754,
"jti": "bWJq",
"sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
"events": {
"http://schemas.openid.net/event/backchannel-
logout": {}
}
}
TOC
2.5. Back-Channel Logout Request
The OP uses an HTTP POST
...