[Openid-specs-ab] Safe response_type for use with form_post response mode

n-sakimura 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 
want :-)

Perhaps we can discuss it in the next call.

Nat

(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.
>>
>> Thanks
>> Pedro
>>
>>
>> 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:
>>
>>> Hi,
>>>
>>> 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?
>>>
>>>
>>> Thanks
>>> Pedro
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>


-- 
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 
することを意図しております。意図された受取人以外の方によるこれらの情報の 
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール 
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 
信されたメールを削除していただきますようお願い致します。
PLEASE READ:
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 
your system.


More information about the Openid-specs-ab mailing list