Skip to content

Commit 2818927

Browse files
cicnavicicnavi
committed
Update specs
1 parent e771149 commit 2818927

3 files changed

Lines changed: 2525 additions & 0 deletions

File tree

‎specifications/oauth-v2-form-post-response-mode-1_0.md‎

Lines changed: 270 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,270 @@
1+
---
2+
description: OAuth 2.0 Form Post Response Mode
3+
generator: "xml2rfc v1.37pre1 (http://xml.resource.org/)"
4+
lang: en
5+
title: "Final: OAuth 2.0 Form Post Response Mode"
6+
---
7+
8+
---------------
9+
[ TOC ](#toc)
10+
---------------
11+
12+
+-----------------------------------------------------------------------+
13+
| ------- ---------------- |
14+
| Final M. Jones |
15+
|   Microsoft |
16+
|   B. Campbell |
17+
|   Ping Identity |
18+
|   April 27, 2015 |
19+
| ------- ---------------- |
20+
+-----------------------------------------------------------------------+
21+
22+
# OAuth 2.0 Form Post Response Mode
23+
24+
### Abstract
25+
26+
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.
27+
28+
\
29+
30+
------------------------------------------------------------------------
31+
32+
### Table of Contents
33+
34+
[1.](#Introduction)  Introduction\
35+
    [1.1.](#rnc)  Requirements Notation and Conventions\
36+
    [1.2.](#Terminology)  Terminology\
37+
[2.](#FormPostResponseMode)  Form Post Response Mode\
38+
[3.](#IANA)  IANA Considerations\
39+
[4.](#Security)  Security Considerations\
40+
[5.](#rfc.references1)  Normative References\
41+
[Appendix A.](#FormPostResponseExample)  \"form_post\" Response Mode Example\
42+
[Appendix B.](#Acknowledgements)  Acknowledgements\
43+
[Appendix C.](#Notices)  Notices\
44+
[§](#rfc.authors)  Authors\' Addresses\
45+
46+
\
47+
\
48+
49+
------------------------------------------------------------------------
50+
51+
---------------
52+
[ TOC ](#toc)
53+
---------------
54+
55+
### 1.  Introduction
56+
57+
\
58+
59+
------------------------------------------------------------------------
60+
61+
---------------
62+
[ TOC ](#toc)
63+
---------------
64+
65+
### 1.1.  Requirements Notation and Conventions
66+
67+
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 (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," March 1997.)](#RFC2119) \[RFC2119\].
68+
69+
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`.
70+
71+
\
72+
73+
------------------------------------------------------------------------
74+
75+
---------------
76+
[ TOC ](#toc)
77+
---------------
78+
79+
### 1.2.  Terminology
80+
81+
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 (Hardt, D., "The OAuth 2.0 Authorization Framework," October 2012.)](#RFC6749) \[RFC6749\] the term \"User Agent\" defined by [RFC 7230 (Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing," June 2014.)](#RFC7230) \[RFC7230\], and the term \"Response Mode\" defined by [OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, "OAuth 2.0 Multiple Response Type Encoding Practices," February 2014.)](#OAuth.Responses) \[OAuth.Responses\].
82+
83+
\
84+
85+
------------------------------------------------------------------------
86+
87+
---------------
88+
[ TOC ](#toc)
89+
---------------
90+
91+
### 2.  Form Post Response Mode
92+
93+
This specification defines the Form Post Response Mode, which is described with its `response_mode` parameter value:
94+
95+
> form_post
96+
> : 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. The action attribute of the form MUST be the Client\'s Redirection URI. The method of the form attribute MUST be `POST`. Because the Authorization Response is intended to be used only once, the Authorization Server MUST instruct the User Agent (and any intermediaries) not to store or reuse the content of the response.
97+
>
98+
> : \
99+
> Any technique supported by the User Agent MAY be used to cause the submission of the form, and any form content necessary to support this MAY be included, such as submit controls and client-side scripting commands. However, the Client MUST be able to process the message without regard for the mechanism by which the form submission was initiated.
100+
101+
\
102+
103+
------------------------------------------------------------------------
104+
105+
---------------
106+
[ TOC ](#toc)
107+
---------------
108+
109+
### 3.  IANA Considerations
110+
111+
This specification makes no requests of IANA.
112+
113+
\
114+
115+
------------------------------------------------------------------------
116+
117+
---------------
118+
[ TOC ](#toc)
119+
---------------
120+
121+
### 4.  Security Considerations
122+
123+
As described in [OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, "OAuth 2.0 Multiple Response Type Encoding Practices," February 2014.)](#OAuth.Responses) \[OAuth.Responses\], there are security implications to encoding response values in the query string and in the fragment value. Some of these concerns can be addressed by using the Form Post Response Mode. In particular, it is safe to return Authorization Response parameters whose default Response Modes are the query encoding or the fragment encoding using the `form_post` Response Mode.
124+
125+
\
126+
127+
------------------------------------------------------------------------
128+
129+
---------------
130+
[ TOC ](#toc)
131+
---------------
132+
133+
### 5. Normative References
134+
135+
--------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
136+
\[OAuth.Responses\] de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, "[OAuth 2.0 Multiple Response Type Encoding Practices](http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html)," February 2014.
137+
\[RFC2119\] [Bradner, S.](mailto:sob@harvard.edu), "[Key words for use in RFCs to Indicate Requirement Levels](http://tools.ietf.org/html/rfc2119)," BCP 14, RFC 2119, March 1997 ([TXT](http://www.rfc-editor.org/rfc/rfc2119.txt), [HTML](http://xml.resource.org/public/rfc/html/rfc2119.html), [XML](http://xml.resource.org/public/rfc/xml/rfc2119.xml)).
138+
\[RFC6749\] Hardt, D., "[The OAuth 2.0 Authorization Framework](http://tools.ietf.org/html/rfc6749)," RFC 6749, October 2012 ([TXT](http://www.rfc-editor.org/rfc/rfc6749.txt)).
139+
\[RFC7230\] Fielding, R. and J. Reschke, "[Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](http://tools.ietf.org/html/rfc7230)," RFC 7230, June 2014 ([TXT](http://www.rfc-editor.org/rfc/rfc7230.txt)).
140+
--------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
141+
142+
\
143+
144+
------------------------------------------------------------------------
145+
146+
---------------
147+
[ TOC ](#toc)
148+
---------------
149+
150+
### Appendix A.  \"form_post\" Response Mode Example
151+
152+
Below is a non-normative request/response/request example as issued/received/issued by the User Agent (with extra line breaks for display purposes only) demonstrating an auto-submitted `form_post` encoded response.
153+
154+
Authorization Request to the Authorization Endpoint:
155+
156+
GET /authorize?
157+
response_type=id_token
158+
&response_mode=form_post
159+
&client_id=some_client
160+
&scope=openid
161+
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcallback
162+
&state=DcP7csa3hMlvybERqcieLHrRzKBra
163+
&nonce=2T1AgaeRTGTMAJyeDMN9IJbgiUG HTTP/1.1
164+
Host: server.example.com
165+
166+
After authentication and approval by the End-User, the Authorization Server issues the Authorization Response:
167+
168+
HTTP/1.1 200 OK
169+
Content-Type: text/html;charset=UTF-8
170+
Cache-Control: no-cache, no-store
171+
Pragma: no-cache
172+
173+
<html>
174+
<head><title>Submit This Form</title></head>
175+
<body onload="javascript:document.forms[0].submit()">
176+
<form method="post" action="https://client.example.org/callback">
177+
<input type="hidden" name="state"
178+
value="DcP7csa3hMlvybERqcieLHrRzKBra"/>
179+
<input type="hidden" name="id_token"
180+
value="eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiw
181+
iYXVkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLC
182+
Jpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0OjkwMzEiLCJpYXQiOjEzNjM5M
183+
DMxMTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2FlUlRHVE1B
184+
SnllRE1OOUlKYmdpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0F
185+
NTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZCIsImF1dGhfdGltZSI6MTM2Mz
186+
kwMDg5NH0.c9emvFayy-YJnO0kxUNQqeAoYu7sjlyulRSNrru1ySZs2qwqq
187+
wwq-Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfrpAuiNuEHII-_fk
188+
IufbGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcq
189+
XVEKhtPadj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_h
190+
nrQ5IKXuNsQ1g9ccT5DMtZSwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc
191+
0uVAwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNRe0iKb47XRXaoz5acA"/>
192+
</form>
193+
</body>
194+
</html>
195+
196+
which results in an HTTP POST to the Client:
197+
198+
POST /callback HTTP/1.1
199+
Host: client.example.org
200+
Content-Type: application/x-www-form-urlencoded
201+
202+
id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiwiYX
203+
VkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLCJpc
204+
3MiOiJodHRwczpcL1wvbG9jYWxob3N0OjkwMzEiLCJpYXQiOjEzNjM5MDMx
205+
MTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2FlUlRHVE1BSnl
206+
lRE1OOUlKYmdpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTD
207+
oyLjA6YWM6Y2xhc3NlczpQYXNzd29yZCIsImF1dGhfdGltZSI6MTM2MzkwM
208+
Dg5NH0.c9emvFayy-YJnO0kxUNQqeAoYu7sjlyulRSNrru1ySZs2qwqqwwq
209+
-Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfrpAuiNuEHII-_fkIuf
210+
bGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcqXVE
211+
KhtPadj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_hnrQ
212+
5IKXuNsQ1g9ccT5DMtZSwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc0uV
213+
AwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNRe0iKb47XRXaoz5acA&
214+
state=DcP7csa3hMlvybERqcieLHrRzKBra
215+
216+
\
217+
218+
------------------------------------------------------------------------
219+
220+
---------------
221+
[ TOC ](#toc)
222+
---------------
223+
224+
### Appendix B.  Acknowledgements
225+
226+
The OpenID Community would like to thank the following people for their contributions to this specification:
227+
228+
> Brian Campbell (bcampbell@pingidentity.com), Ping Identity
229+
>
230+
> Michael B. Jones (mbj@microsoft.com), Microsoft
231+
>
232+
> Breno de Medeiros (breno@google.com), Google
233+
234+
\
235+
236+
------------------------------------------------------------------------
237+
238+
---------------
239+
[ TOC ](#toc)
240+
---------------
241+
242+
### Appendix C.  Notices
243+
244+
Copyright (c) 2015 The OpenID Foundation.
245+
246+
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.
247+
248+
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
249+
250+
\
251+
252+
------------------------------------------------------------------------
253+
254+
---------------
255+
[ TOC ](#toc)
256+
---------------
257+
258+
### Authors\' Addresses
259+
260+
--------- ------------------------------
261+
  Michael B. Jones
262+
  Microsoft
263+
Email:  <mbj@microsoft.com>
264+
URI:  <http://self-issued.info/>
265+
   
266+
  Brian Campbell
267+
  Ping Identity
268+
Email:  <brian.d.campbell@gmail.com>
269+
URI:  <https://twitter.com/__b_c>
270+
--------- ------------------------------

0 commit comments

Comments
 (0)