Ping Identity Corp.

bcampbell@pingidentity.com

Ping Identity Research and Development This document defines a form auto-submit POST encoding of responses to OAuth 2.0 Authorization Requests (including OpenID Connect requests) as well as several new response types to indicate when the POST encoding is to be used.

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 . It would be really surprising if anyone reads this far in the section after all of the words such as "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", etc., I know I never do.

Section 3.1.1 of OAuth 2.0 defines the code and token response types and section 8.4 defines an extension mechanism that allows for new response types to be defined and used. The OAuth 2.0 Multiple Response Type Encoding Practices document utilizes that extension mechanism and defines a number of new OAuth response types in support of a variety of use-cases including OpenID Connect SSO. This document builds on the aforementioned specifications to defines new response types and a new response type encoding using HTTP POST.

This section defines the following new response type response-name in accordance with the ABNF in Section 8.4 of OAuth 2.0. The x_post response-name effectively adorns other response types or multiple-valued response type combinations and indicates that the client wants the response POSTed to it. The x_post response-name part SHOULD NOT be used alone but rather in conjunction with other established response-name parts to indicate that the response should be POSTed to the client. These response types work by encoding the Access Token Response parameters into HTML form controls that are auto-submitted in the user-agent and thus are transmitted via the HTTP POST method to the client. The action attribute of the form MUST be the client's redirect URI. The method of the form attribute MUST be POST. 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 is initiated.

This section defines and registers combinations of the x_post response-name with other previously registered response types. Conceptually x_post only qualifies the response type to indicate that HTTP POST form encoding should be used but the nature of the response type extension mechanism mandates that each individual response type be explicitly defined. The following defines the subset of all potential combinations, which provide the most utility (in the ever humble opinion of the author anyway). When supplied as the value for the response_type parameter, a successful response MUST include an ID Token as defined in OpenID Connect. Both successful and error responses SHOULD be form-encoded as described in this document. When supplied as the value for the response_type parameter, a successful response MUST include an Access Token as defined in the OAuth 2.0 specification. Both successful and error responses SHOULD be form-encoded as described in this document. When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code and an ID Token. Both successful and error responses SHOULD be form-encoded as described in this document. When supplied as the value for the response_type parameter, a successful response MUST include an ID Token and an Access Token. Both successful and error responses SHOULD be form-encoded as described in this document. 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-submit POST encoded response: Authorization Request to the token endpoint at the AS:

After authentication and approval by the end-user, the AS issues the Authorization Response:

]]>

Which results in an HTTP POST to the client:

This section would register the response_type values defined by this specification in the IANA OAuth Authorization Endpoint Response Types registry , if this document is ever considered for standardization.

Response Type Name: x_post id_token Change Controller: [[ me ]] Specification Document(s): [[ this one ]] Response Type Name: x_post token Change Controller: [[ me ]] Specification Document(s): [[ this one ]] Response Type Name: x_post code id_token Change Controller: [[ me ]] Specification Document(s): [[ this one ]] Response Type Name: x_post id_token token Change Controller: [[ me ]] Specification Document(s): [[ this one ]]

Google Google Facebook Nomura Research Institute, Ltd. Ping Identity Microsoft Google Salesforce Illumila

Folks. Lots of folks. But definitely not Paul Madsen.

[[ To be removed from the final specification ]] -00 Initial draft