ISO/IEC 26138:2024

Information technology — OpenID connect — OAuth 2.0 multiple response type encoding practices

This document provides guidance on the proper encoding of responses to OAuth 2.0 Authorization Requests in which the request uses a Response Type value that includes space characters. Furthermore, this document registers several new Response Type values in the OAuth Authorization Endpoint Response Types registry. This document also defines a Response Mode Authorization Request parameter that informs the Authorization Server of the mechanism to be used for returning Authorization Response parameters from the Authorization Endpoint.

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 26138
First edition
Information technology — OpenID
2024-10
connect — OAuth 2.0 multiple
response type encoding practices
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 OAuth 2.0 Multiple Response Type
Encoding Practices) 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
This specification provides guidance on the proper encoding of
responses to OAuth 2.0 Authorization Requests in which the request
uses a Response Type value that includes space characters.
Furthermore, this specification registers several new Response Type
values in the OAuth Authorization Endpoint Response Types registry.
This specification also defines a Response Mode Authorization Request
parameter that informs the Authorization Server of the mechanism to
be used for returning Authorization Response parameters from the
Authorization Endpoint.
© ISO/IEC 2024 – All rights reserved
iv
Table of Contents
1. Introduction
1.1. Requirements Notation and Conventions
1.2. Terminology
2. Response Types and Response Modes
2.1. Response Modes
2.2. Multiple-Valued Response Types
3. ID Token Response Type
4. None Response Type
5. Definitions of Multiple-Valued Response Type
Combinations
6. IANA Considerations
6.1. OAuth Authorization Endpoint Response Types
Registration
6.1.1. Registry Contents
6.2. OAuth Parameters Registration
6.2.1. Registry Contents
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Example using Multiple-Valued Response Type

© ISO/IEC 2024 – All rights reserved
v
Information technology — OpenID Connect — OAuth 2.0
Multiple Response Type Encoding Practices

TOC
1. Introduction
TOC
1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
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.

TOC
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 Endpoint" defined by OAuth 2.0
[RFC6749] and the term "User Agent" defined by RFC 2616 [RFC2616].
This specification also defines the following terms:
Multiple-Valued Response Types
The OAuth 2.0 specification allows for registration of space-
separated response_type parameter values. If a Response
Type contains one of more space characters (%20), it is
compared as a space-delimited list of values in which the
order of values does not matter.
© ISO/IEC 2024 – All rights reserved
Response Mode
The Response Mode determines how the Authorization
Server returns result parameters from the Authorization
Endpoint. Non-default modes are specified using the
response_mode request parameter. If response_mode is
not present in a request, the default Response Mode
mechanism specified by the Response Type is used.

TOC
2. Response Types and Response Modes
The Response Type request parameter response_type informs the
Authorization Server of the desired authorization processing flow,
including what parameters are returned from the endpoints used. The
Response Mode request parameter response_mode informs the
Authorization Server of the mechanism to be used for returning
Authorization Response parameters from the Authorization Endpoint.
Each Response Type value also defines a default Response Mode
mechanism to be used, if no Response Mode is specified using the
request parameter.
TOC
2.1. Response Modes
This specification defines the following OAuth Authorization Request
parameter:
response_mode
OPTIONAL. Informs the Authorization Server of the
mechanism to be used for returning Authorization Response
parameters from the Authorization Endpoint. This use of this
parameter is NOT RECOMMENDED with a value that specifies
the same Response Mode as the default Response Mode for
the Response Type used.
© ISO/IEC 2024 – All rights reserved
This specification defines the following Response Modes, which are
described with their response_mode parameter values:
query
In this mode, Authorization Response parameters are
encoded in the query string added to the redirect_uri
when redirecting back to the Client.
fragment
In this mode, Authorization Response parameters are
encoded in the fragment added to the redirect_uri when
redirecting back to the Client.
For purposes of this specification, the default Response Mode for the
OAuth 2.0 code Response Type is the query encoding. For purposes of
this specification, the default Response Mode for the OAuth 2.0 token
Response Type is the fragment encoding.
See OAuth 2.0 Form Post Response Mode [OAuth.Post] for an example
of a specification that defines an additional Response Mode. Note that it
is expected that additional Response Modes may be defined by other
specifications in the future, including possibly ones utilizing the HTML5
postMessage API and Cross Origin Resource Sharing (CORS).

TOC
2.2. Multiple-Valued Response Types
When a multiple-valued Response Type is defined, it is RECOMMENDED
that the following encoding rules be applied for the issued response
from the Authorization Endpoint.
All parameters returned from the Authorization Endpoint SHOULD use
the same Response Mode. This recommendation applies to both success
and error responses.
Rationale: This significantly simplifies Client parameter processing. It
also can have positive performance benefits, as described below.
For instance, if a response includes fragment encoded parts, a User
Agent Client component must be involved to complete processing of the
response. If a new query parameter is added to the Client URI, it will
cause the User Agent to re-fetch the Client URI, causing discontinuity of
operation of the User Agent based Client components. If only fragment
encoding is used, the User Agent will simply reactivate the Client
component, which can then process the fragment and also convey any
© ISO/IEC 2024 – All rights reserved
parameters to a Client host as necessary, e.g., via XmlHttpRequest.
Therefore, full fragment encoding always results in lower latency for
response processing.
TOC
3. ID Token Response Type
This section registers a new Response Type, the id_token, in
accordance with the stipulations in the OAuth 2.0 specification, Section
8.4. The intended purpose of the id_token is that it MUST provide an
assertion of the identity of the Resource Owner as understood by the
Authorization Server. The assertion MUST specify a targeted audience,
e.g. the reque
...