<div dir="ltr">Hi John,<div><br></div><div>First of all, thanks for your very instructive response.</div><div><br></div><div>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.</div>
<div>My current understanding is that *all current* response types are allowed for form_post. Perhaps that could be more clearly stated at <a href="http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html">http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html</a>.</div>
<div><br></div><div>Thanks</div><div>Pedro</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 6:28 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

<br>
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.<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
With exact redirect_uri matching as required in Connect fragment and POST have the same security properties.<br>
<br>
For OAuth where looser redirect matching is permitted POST may be more secure.<br>
<br>
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.<br>
<br>
John B.<br>
<div><div class="h5"><br>
<br>
On Jun 24, 2014, at 11:38 AM, Pedro Felix <<a href="mailto:pmhsfelix@gmail.com">pmhsfelix@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> 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.<br>
><br>
> 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)<br>
><br>
> On the other hand, the "oauth-v2-form-post-response-mode-1_0" is not clear about this issue, except for this sentence<br>
><br>
>    "In particular, it is safe to return Authorization Response parameters whose default Response<br>
>     Modes are the query encoding or the fragment encoding using the form_post Response Mode"<br>
><br>
> Does this mean that form_post response mode is safe for *any* response type, since the defaults are always either query or fragment?<br>
><br>
><br>
> Thanks<br>
> Pedro<br>
</div></div>> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</blockquote></div><br></div>