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

Pedro Felix pmhsfelix at gmail.com
Tue Jun 24 21:31:39 UTC 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140624/8c027903/attachment.html>


More information about the Openid-specs-ab mailing list