Hi *,
I was wondering what you thing about the second "issue" described (the "Lassie come home"). I have encountered lately in one enterprise installation and I think is fairly easy to make it wrong as well. Regards Antonio On May 17, 2013, at 5:46 PM, John Bradley wrote: > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
