Into the symmetry

As the OAuth 2 framework is becoming more and more used I thought it would be useful to share some of the most common attacks. It is important to highlight that the attacks I am going to introduce today are not issues in the specification per se but rather possible implementation issues. The first document to look at when you try to secure one OAuth 2 implementation is the OAuth 2.0 Threat Model but this is way not enough. In order to have a safe implementation it is important to understand what is OAuth about and to be involved in the "OAuthsphere" (OAuth mailing list, blogs, etc), In this blog post I will try to show two of the most common attacks that I have renamed  ' The Devil Wears Prada' and 'Lassie Come Home'. Let's see. Firstly the actors: The Actors The Devil Wears Prada The first time I read about this potential issue was in one of John Bradley's blog post . This issue is also known as " confused deputy problem ...

Getting some inspiration from this dialog about OAuth 1.0 I thought it would be nice to have something similar for OAuth 2.0 The Actors   The R.O. shows intent Alice (R.O.): hey, Bob , I would like you to be able to access the profile pictures from my Facebook account so you can print for me a nice photo album. Bob (client): no problem, I know how we can do it. All I need is you getting me an Authorization Code from Facebook. The R.O. obtain an authorization code Alice (R.O.): hey Mark, www.printondemand.biz wants an Authorization Code Mark (server): are you sure you want to give this code to www.printondemand.biz ? this will allow it to get all profile pictures from your profile. Alice (R.O.): yes it is ok. Mark (server): ok I am sending you over to www.printondemand.biz The R.O. is redirected to the client Alice (R.O.): hey Bob here we go, this is the Authorization Code Bob (client): thanks The client exchange the Authorization Code for an Acce...

Lately I have been more and more involved with OAuth (at work and in my spare time with Apache Amber ) so before I forget some lessons learned I decided to put them here. First reminder to self:  OAuth is NOT an authentication protocol. It is an access delegation protocol. I hope this is clear to all the OAuth developers/implementators. Should you use OAuth for authenticate in your application/website you'd better be careful (specially if you use the client side flow aka implicit grant). If you wonder why give a look here and here . Risk: "access_token phishing" attack Mitigation : Use Open ID Connect or API like https://graph.facebook.com/app?access_token=YOUR_TOKEN To be continued... P.S. little off topic Apache Amber is now linked also from http://oauth.net/2/

Short story   Apache Amber 0.22-incubating released! http://markmail.org/message/2ywodi74vlv4d2qe See also: http://incubator.apache.org/amber/download.html and http://oauth.net/2/ Little more Despite the earthquake that hit "OAuth 2 world" the Amber team is proud to announce the first release of Apache Amber ( Apache Amber 0.22-incubating ).  The people that followed the project since the beginning know that has been a kind long journey due some legal issue that slowed down the release.  I am really keen to see Amber used and improved in the near future. I can see at the horizon some Open Id Connect and UMA integration and obviously to be fully compliant with the last version of the spec (version 31?). From the other hand I am kind of sad to see the lead editor leaving the specification. Specially the first post is definitely an interesting rant to read with a lot of valid points and considering who is the author cannot be ignored. I think only time wi...

Some time ago I was looking for a Java OAuth library in order to help me to develop an OAuth aware server application. The natural place where to look for those information was the OAuth website that lists about 4 different Java libraries. The only one I am familiar with is Scribe . Indeed it is a really light, well documented and universally used library to build OAuth clients. It also contains out of the box integration for many well known websites that use OAuth (e.g. Facebook, Twitter, and many more). Unlikely though Scribe did/does not have any support for OAuth server side (that was my original problem). After a while a colleague of mine point me out an Apache project called Apache Amber and it turned out it was what I needed :) (Still wonder why Apache Amber is not listed in the OAuth website though). So the lesson learned is that if you are looking for a simple way to build your OAuth server do not hesitate to use Apache Amber. Here you can see how easy is to build the...

According to http://developers.facebook.com/docs/authentication/ in order to programmatically log the user out of Facebook from an OAuth 2 client (single sign-off) is enough to redirect the user to https://www.facebook.com/logout.php?     next=YOUR_REDIRECT_URL    &access_token=USER_ACCESS_TOKEN This would require a valid access token and a valid redirect url. Alternatively this can be achieved client side by calling FB.logout() . In practice though there is a third (obviously not documented) unofficial way to achieve the same. It is the case indeed that the standard log out form of Facebook suffer from CSRF. Indeed while posting to http://www. facebook .com/ logout .php the related form uses a field,  fb_dtsg , that is supposed to be an anti-CSRF token, however it is not verified properly/at all. Removing this field still resulted in successful logout ! According to Facebook (I have been in touch with them about this) this is not a sec...

It means nothing to a lot of people. It does means a lot to me! My first commit to an Apache project: http://svn.apache.org/viewvc?view=revision&revision=1236276