Slides available on http://asfws12.files.wordpress.com/2012/11/asfws2012-maxime_feroul-oauth_un_protocole_qui_authentifie.pdf

Maxime Feroul started his presentation with the fact that we all currently have many different identities on the Internet. Federating a common solution is far from being easy, as it must be secure and easy for all stakeholders. Ideally, you would want to use your LinkedIn, Xing or SalesForce profile to identify yourself on other business related sites, while login to private related websites may rely on Facebook.

There are already different identity federation protocols and providers available. On one side we find more business / SOAP / XML (WS-* or SAML) solutions, while on the other solutions are more “web” / REST / JSON (OpenID connect, Oauth 2.0, UMA) oriented.

But let’s come back to OAuth and compare it to OpenID Connect. While OpenID Connect authenticate users, OAuth is used to authorize them. Initially the goal was to allow applications or services to use resources from a user in his name, but without having to store his credentials. OAuth therefore does not specify how to authenticate the user, the identity provider (IDP) is solely responsible for this and is free to perform this duty as he intends.

OAuth 2.0 features many ways to authorize users, but the two most common are the authorization code and the implicit method. Relying on the “implicit” method can be dangerous, as a rogue application may impersonate its victim by reusing the token issued by the IDP. This vulnerable “implicit” method is often in use, according to the referent, in the mobile world.

A look in the norm for the OAuth 2.0 “implicit” method shows that the authors noticed there was a security loophole, and signaled it in the RFC. Facebook’s OAuth implementation is not 100% conform to the protocol, but mitigates the security issue introduced by the “implicit” method by adding additional checks on the server side.

As a practical take-away for your next “social” application, ensure your application does not allow passing around just tokens, but add extra checks to delimit for which services these identifiers were issued. Double-check as well that the whole authentication/authorization process occurs over a secure channel and protect your application against Cross-Site Request Forgery ([C|X]SRF) attacks.