[Openid-specs-ab] Safe response_type for use with form_post response mode
n-sakimura at nri.co.jp
Wed Jun 25 03:23:25 UTC 2014
The form post draft still is just a draft so we can rev as much as we
Perhaps we can discuss it in the next call.
(2014/06/25 6:55), John Bradley wrote:
> All are allowed for POST and fragment, get is code only.
> The form post response mode was the last thing added to the spec so it may not have been reviewed as extensively.
> We will add it to the to do list.
> On Jun 24, 2014, at 5:31 PM, Pedro Felix <pmhsfelix at gmail.com> wrote:
>> Hi John,
>> First of all, thanks for your very instructive response.
>> I'm aware of almost all of these issues (the fragment preservation after redirect is also new to me). However, from reading the OIDC specs, it wasn't clear to me what were the *allowed* response types for form_post.
>> My current understanding is that *all current* response types are allowed for form_post. Perhaps that could be more clearly stated at http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html.
>> On Tue, Jun 24, 2014 at 6:28 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> The query response mode should only be used with the "code" oe "none" response_type. It will leak the code in the referrer for any content loaded on the landing page, eg to Google for traffic monitoring, and that can be bad for any client that is not confidential. It would also directly leak tokens if used for any other response_type.
>> The fragment encoding method was chosen as a default to prevent leakage of access tokens in the referrer and can be used for all the other response types.
>> It however has been discovered that browser behaviour has changed and the browsers now preserve the fragment across 302 redirects. This was not the case when OAuth chose that as the default.
>> Now a client using fragment encoding needs to be careful of having any 302 redirects that are valid as redirect_uri in it's registration.
>> The post method is safe for all the response_types and has the advantage of not preserving the parameters across a redirect unless the RP is doing something particularly stupid.
>> With exact redirect_uri matching as required in Connect fragment and POST have the same security properties.
>> For OAuth where looser redirect matching is permitted POST may be more secure.
>> If the client is JS in the browser then fragment encoding is the best (but use exact redirect_uri matching even if you are not using Connect.
>> John B.
>> On Jun 24, 2014, at 11:38 AM, Pedro Felix <pmhsfelix at gmail.com> wrote:
>>> It is not clear to me what are the safe response_type values (e.g. "code id_token", "id_token token") that can be used with the form_post response mode.
>>> The "oauth-v2-multiple-response-types-1_0" defines the safe response modes for each combination, but only considers query and fragment modes (as it should)
>>> On the other hand, the "oauth-v2-form-post-response-mode-1_0" is not clear about this issue, except for this sentence
>>> "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"
>>> Does this mean that form_post response mode is safe for *any* response type, since the defaults are always either query or fragment?
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
The information contained in this e-mail is confidential and intended
for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby
notified that any review, dissemination, distribution or duplication of
this message is strictly prohibited. If you have received this message
in error, please notify the sender immediately and delete your copy from
More information about the Openid-specs-ab