oauth-v2-form-post-response-mode-1_0.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd">
<rfc category="std" docName="oauth-v2-form-post-response-mode-1_0" ipr="trust200902">

  <?rfc toc="yes" ?>
  <?rfc tocdepth="4" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc strict="yes" ?>
  <?rfc iprnotified="no" ?>
  <?rfc private="Final" ?>

  <front>
    <title abbrev="OAuth 2.0 Form Post Response Mode">
      OAuth 2.0 Form Post Response Mode
    </title>

    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization abbrev="Microsoft">Microsoft</organization>
      <address>
        <email>mbj@microsoft.com</email>
	<uri>http://self-issued.info/</uri>
      </address>
    </author>

    <author fullname="Brian Campbell" initials="B." surname="Campbell">
      <organization abbrev="Ping Identity">Ping Identity</organization>
      <address>
        <email>brian.d.campbell@gmail.com</email>
	<uri>https://twitter.com/__b_c</uri>
      </address>
    </author>

    <date day="27" month="April" year="2015" />

    <workgroup>OpenID Connect Working Group</workgroup>

    <abstract>
      <t>
	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 <spanx style="verb">POST</spanx> method to the Client,
	with the result parameters being encoded in the body
	using the <spanx style="verb">application/x-www-form-urlencoded</spanx> format.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor='Introduction' title='Introduction'>
      <section anchor="rnc" title="Requirements Notation and Conventions">
	<t>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 <xref
	target="RFC2119">RFC 2119</xref>.</t>

	<t>
	  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 <spanx style="verb">this fixed-width font</spanx>.
	</t>
      </section>

      <section anchor="Terminology" title="Terminology">
	<t>
	  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 <xref target="RFC6749">OAuth 2.0</xref>
	  the term "User Agent" defined by <xref target="RFC7230">RFC 7230</xref>,
	  and the term "Response Mode" defined by
	  <xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>.
	</t>
      </section>
    </section>

    <section anchor="FormPostResponseMode" title="Form Post Response Mode">

      <t>
	This specification defines the Form Post Response Mode, which is described
	with its <spanx style="verb">response_mode</spanx> parameter value:
      </t>

      <t>
	<list style="hanging">
	  <t hangText="form_post">
	    <vspace/>
	    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 <spanx style="verb">POST</spanx> method to the Client,
	    with the result parameters being encoded in the body
	    using the <spanx style="verb">application/x-www-form-urlencoded</spanx> format.
	    The action attribute of the form MUST be the Client's Redirection URI.
	    The method of the form attribute MUST be <spanx style="verb">POST</spanx>.
	    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.
	  </t>
	  <t>
	    <vspace blankLines="1"/>
	    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.
	  </t>
	</list>
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">

      <t>
	This specification makes no requests of IANA.
      </t>

    </section>

    <section anchor="Security" title="Security Considerations">

      <t>
	As described in
	<xref target="OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</xref>,
	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 <spanx style="verb">form_post</spanx> Response Mode.
      </t>

    </section>

  </middle>  

  <back>
    <references title="Normative References">
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749"?>

      <reference anchor="OAuth.Responses">
        <front>
	  <title>OAuth 2.0 Multiple Response Type Encoding Practices</title>

	  <author fullname="Breno de Medeiros" initials="B." role="editor" surname="de Medeiros">
	    <organization abbrev="Google">Google</organization>
	  </author>

	  <author fullname="Marius Scurtescu" initials="M." surname="Scurtescu">
	    <organization abbrev="Google">Google</organization>
	  </author>

	  <author fullname="Paul Tarjan" initials="P." surname="Tarjan">
	    <organization abbrev="Facebook"> Facebook</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Microsoft">Microsoft</organization>
	  </author>

	  <date day="25" month="February" year="2014" />
        </front>

	<format target="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html"
		type="HTML" />
      </reference>
    </references>

    <section anchor="FormPostResponseExample" title='"form_post" Response Mode Example'>

      <t>
	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 <spanx style="verb">form_post</spanx> encoded response.
      </t>

      <figure>
	<preamble>
	  Authorization Request to the Authorization Endpoint:
	</preamble>
	<artwork><![CDATA[
  GET /authorize?
   response_type=id_token
   &response_mode=form_post
   &client_id=some_client
   &scope=openid
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcallback
   &state=DcP7csa3hMlvybERqcieLHrRzKBra
   &nonce=2T1AgaeRTGTMAJyeDMN9IJbgiUG HTTP/1.1
  Host: server.example.com
]]></artwork>
      </figure>

      <figure>
	<preamble>
	  After authentication and approval by the End-User, the Authorization Server
	  issues the Authorization Response:
	</preamble>
	<artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: text/html;charset=UTF-8
  Cache-Control: no-cache, no-store
  Pragma: no-cache

  <html>
   <head><title>Submit This Form</title></head>
   <body onload="javascript:document.forms[0].submit()">
    <form method="post" action="https://client.example.org/callback">
      <input type="hidden" name="state"
       value="DcP7csa3hMlvybERqcieLHrRzKBra"/>
      <input type="hidden" name="id_token"
       value="eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiw
         iYXVkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLC
         Jpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0OjkwMzEiLCJpYXQiOjEzNjM5M
         DMxMTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2FlUlRHVE1B
         SnllRE1OOUlKYmdpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0F
         NTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZCIsImF1dGhfdGltZSI6MTM2Mz
         kwMDg5NH0.c9emvFayy-YJnO0kxUNQqeAoYu7sjlyulRSNrru1ySZs2qwqq
         wwq-Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfrpAuiNuEHII-_fk
         IufbGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcq
         XVEKhtPadj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_h
         nrQ5IKXuNsQ1g9ccT5DMtZSwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc
         0uVAwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNRe0iKb47XRXaoz5acA"/>
    </form>
   </body>
  </html>
]]></artwork>
      </figure>

      <figure>
	<preamble>
	  which results in an HTTP POST to the Client:
	</preamble>
	<artwork><![CDATA[
  POST /callback HTTP/1.1
  Host: client.example.org
  Content-Type: application/x-www-form-urlencoded

  id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiwiYX
         VkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLCJpc
         3MiOiJodHRwczpcL1wvbG9jYWxob3N0OjkwMzEiLCJpYXQiOjEzNjM5MDMx
         MTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2FlUlRHVE1BSnl
         lRE1OOUlKYmdpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTD
         oyLjA6YWM6Y2xhc3NlczpQYXNzd29yZCIsImF1dGhfdGltZSI6MTM2MzkwM
         Dg5NH0.c9emvFayy-YJnO0kxUNQqeAoYu7sjlyulRSNrru1ySZs2qwqqwwq
         -Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfrpAuiNuEHII-_fkIuf
         bGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcqXVE
         KhtPadj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_hnrQ
         5IKXuNsQ1g9ccT5DMtZSwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc0uV
         AwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNRe0iKb47XRXaoz5acA&
  state=DcP7csa3hMlvybERqcieLHrRzKBra
]]></artwork>
      </figure>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
	The OpenID Community would like to thank the following people for
	their contributions to this specification:
      </t>

      <t>
	<list style="empty">
	  <t>Brian Campbell (bcampbell@pingidentity.com), Ping Identity</t>
          <t>Michael B. Jones (mbj@microsoft.com), Microsoft</t>
          <t>Breno de Medeiros (breno@google.com), Google</t>
        </list>
      </t>
    </section>

    <section anchor="Notices" title="Notices">
      <t>Copyright (c) 2015 The OpenID Foundation.</t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
    </section>
  </back>
</rfc>