Information technology - OpenID connect - OAuth 2.0 form post response mode

This document defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format.

Titre manque

General Information

Status
Published
Publication Date
30-Sep-2024
Current Stage
6060 - International Standard published
Start Date
01-Oct-2024
Due Date
14-Feb-2027
Completion Date
01-Oct-2024

Overview

ISO/IEC 26139:2024 specifies the OpenID Connect - OAuth 2.0 Form Post Response Mode (response_mode = "form_post"). The standard defines how an Authorization Response is encoded as HTML form values that are auto-submitted by the User Agent and transmitted to the Client via the HTTP POST method. Result parameters are placed in the request body using the application/x-www-form-urlencoded format. The document standardizes the form_post response mode behavior, usage constraints, and security guidance for implementers.

Key topics and requirements

  • Definition of the form_post response mode: Authorization Response parameters are encoded as HTML form values auto-submitted in the User Agent and POSTed to the Client.
  • Mandatory form attributes:
    • The form action attribute MUST be the Client’s Redirection URI.
    • The form method attribute MUST be POST.
  • Single-use response handling: the Authorization Server MUST instruct the User Agent and intermediaries not to store or reuse response content.
  • Client processing requirements: any UA-supported technique may be used to submit the form (auto-submit, scripting, submit controls), but the Client MUST be able to process the message regardless of how submission was initiated.
  • Encoding and media type: response parameters are encoded in the body with application/x-www-form-urlencoded.
  • Administrative notes: the specification makes no IANA requests and cites normative references such as OAuth 2.0 and relevant RFCs.

Applications and practical value

  • Secure transmission of OpenID Connect / OAuth 2.0 Authorization Response parameters from Authorization Server to Client.
  • Alternative to query-string or fragment encodings when minimizing exposure in browser history, logs, or intermediaries is a concern. The standard explicitly notes that form_post can address some security implications of query or fragment encodings.
  • Implementation scenarios include identity providers (authorization servers), relying party (Client) web applications, and libraries handling OpenID Connect/OAuth 2.0 flows where a POST-based redirect is preferred.
  • The Appendix provides a non-normative auto-submitted HTML form example showing hidden inputs for parameters (e.g., id_token, state) and resulting application/x-www-form-urlencoded POST to the Client.

Who should use this standard

  • OAuth 2.0 / OpenID Connect implementers (Authorization Server and Client developers)
  • Identity and access management architects and engineers
  • Web application and security engineers seeking standardized response modes for token delivery

Related standards

  • OAuth 2.0 Authorization Framework (RFC 6749)
  • OAuth 2.0 Multiple Response Type Encoding Practices
  • HTTP/1.1 message syntax and routing (RFC 7230)
  • RFC 2119 requirement keywords

Keywords: ISO/IEC 26139:2024, OpenID Connect, OAuth 2.0, form_post, response mode, application/x-www-form-urlencoded, HTTP POST, User Agent, Authorization Response.

Standard

ISO/IEC 26139:2024 - Information technology — OpenID connect — OAuth 2.0 form post response mode Released:1. 10. 2024

English language
5 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ISO/IEC 26139:2024 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - OpenID connect - OAuth 2.0 form post response mode". This standard covers: This document defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format.

This document defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format.

ISO/IEC 26139:2024 is classified under the following ICS (International Classification for Standards) categories: 35.030 - IT Security. The ICS classification helps identify the subject area and facilitates finding related standards.

ISO/IEC 26139:2024 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.

Standards Content (Sample)


International
Standard
ISO/IEC 26139
First edition
Information technology — OpenID
2024-10
connect — OAuth 2.0 form post
response mode
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: +41 22 749 01 11
Email: copyright@iso.org
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 Form Post Response Mode)
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 defines the Form Post Response Mode. In this mode,
Authorization Response parameters are encoded as HTML form values
that are auto-submitted in the User Agent, and thus are transmitted via
the HTTP POST method to the Client, with the result parameters being
encoded in the body using the application/x-www-form-urlencoded
format.
© ISO/IEC 2024 – All rights reserved
iv
Table of Contents
1. Introduction
1.1. Requirements Notation and Conventions
1.2. Terminology
2. Form Post Response Mode
3. IANA Considerations
4. Security Considerations
5. Normative References
Appendix A. "form_post" Response Mode Example
© ISO/IEC 2024 – All rights reserved
v
Information technology — OpenID Connect — OAuth 2.0
Form Post Response Mode
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] the term "User Agent" defined by RFC 7230 [RFC7230], and
the term "Response Mode" defined by OAuth 2.0 Multiple Response
Type Encoding Practices [OAuth.R
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...