The implicit flow is secure in Connect, but we added a number of things to make it so.
The reason to have it in OAuth 2 is for clients in the browser there are use cases for that and it allows the browser to receive and extract the token without passing it to a web server backend. Used as intended it is fine as the browser based JS App is receiving the the token directly over TLS so there is no substitution attack possible. The problem is when the client is not in the browser the browser itself is an attack surface, that an attacker can use to confuse a client. If people want to do SSO based on OAuth they need to follow the example of Google, PayPal and others who are implementing Connect rather than rolling there own protocol on top of OAuth 2. John B. On 2013-05-17, at 5:22 PM, Lewis Adam-CAL022 <adam.le...@motorolasolutions.com> wrote: > One wonders that - if in hindsight - the implicit flow was a mistake to > include in the framework. Yes it saves a single round trip for use cases > where the tokens are exposed to the UA, but it's not clear that optimization > is worth the security headaches that are going to be caused down the road (or > are already going on for that matter) by people using it in scenarios where > it should not be (because as stated, it is easier). Probably would have been > better to let the subset of cases that didn't need the extra step of the code > just go ahead and implement it anyway, and ensure that the majority of native > apps use cases would have been implemented with better security. > > adam > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Richer, Justin P. > Sent: Wednesday, May 15, 2013 3:22 PM > To: Antonio Sanso > Cc: "WG <oauth@ietf.org>"@il06exr01.mot.com > Subject: Re: [OAUTH-WG] Recap of two well known OAuth related attacks > > The biggest problem with this attack is the passing of the access token to a > backend server (and its subsequent passing of that token to someone else) and > the assumption that the presentation of the access token means that the user > is authenticated and present. It simply doesn't mean that, and this is a bad > assumption that unfortunately many people make thanks to providers like > Facebook using OAuth (or, mostly-OAuth since they're not actually RFC > compliant) in the authentication protocol. > > It's also a problem that so many people are using the implicit flow "because > it's easy", missing the point of why it's there in the first place. The > implicit flow is really only intended for cases where you can't hide secrets > from the user agent, cases like an in-browser application. The flow diagrams > that you have don't fit the implicit flow very well at all, since the access > token is getting passed back to some other service. > > -- Justin > > On May 13, 2013, at 11:14 AM, Antonio Sanso <asa...@adobe.com> > wrote: > >> Hi *, >> >> I wrote a blog post showing two well known OAuth related attacks. I paste >> here the link for your consideration: >> >> http://intothesymmetry.blogspot.ch/2013/05/oauth-2-attacks-introducing-devil-wears.html >> >> Any comment is more than appreciated. >> >> Regards >> >> Antonio >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
