OAuth

If you use social media (e.g. facebook, twitter) it's likely that you've used OAuth. OAuth works also for devices, e.g. my TV uses OAuth to let me access my Youtube account.

Usages:

• Delegated authorization e.g. a (web) application (the client / resource consumer) want to access a user data  in a resource provider (e.g. google calendar or facebook photos/friends), the application rely on user permission (authorisation) using an authorization server (e.g. facebook, google)  to get access to user's data.
• OpenID, which is build on top of OAuth protocol, provides single sign on / (federated) delegated authentication.

Advantages:

• To avoid too many password accounts for different applications that will increase the phishing risk, ear drop risk and revocation problem (you need to cancel/change all the password accounts in all applications)
• To avoid sharing password to resource providers, only the security provider (e.g. google) registers your password
• To standardize different (delegated) authorization methods from different vendors. At this moment in practice there are still minor differences between different vendor implementations, but the distances between them are getting smaller and generic APIs (e.g. Scribe) that adapt to different vendors are available.

Best practice

• the auth token is sent with http header instead of URL GET parameters: less obvious, to avoid the token being cached/logged as url entries
• use SSL to avoid the attackers steal the token
• limit the token lifespan (if you revoke the token it will not last too long)
• use random salt to prevent CSRF attack.
• manage user experience: tell user what happens "e.g. This application needs your approval to use this resource. We will redirect you to an authorisation server (e.g. google) so that you can give permission."

Protocol:  the web server application flow (a.k.a. the 3 legged flow)

This is the strongest OAuth protocol, to avoid the client browser (e.g. malicious javascript) to catch the access token by using intermediately autho code (which later is being exchanged for an access token via server to server call that safer than browser to server call).

First the client application has to register to the autho server / oauth security provider (e.g. google) to establish clientID & password.

The flow:

1. The application makes oauth request to the the authorisation server with parameters: clientid (from the client application registration), resorce scope (e.g. google calendar), redirect url (where the user will be returned after they approve the access) and other parameters such as state (random salt against CSRF) and access_type ('offline' for the 3 legged flow). The user has to login and then gives permission/authorisation to the application via authorisation server web interface. The authorisation server then return the user (& send the intermediate code) to the redirect url.

2. The client application then can exchange the intermediate code for an access token.

3. The application then can access the user data in the resource provider using access token. The resource provider will validate the access token. The validation process is not defined in the standard, but for example some OAuth implementation provide API in the OAuth server where the resource provider can exchange the token with user's id & scope information and then compare this result with the resource provider's own ACL.

4. Optional: in some scenarios the access token will be expired, the application need to obtain a new access token using refresh token.

Other protocols:         

• client flow (a.k.a. the 2 legged flow) : the client received the access token directly (instead of have to exchange the intermediate code.) This approach is less secure (since the access token is exposed to  the client browser, so for example a malicious javascript can steal it) but good enough for many non critical applications (e.g. invitations for photos viewer).
• password flow: use password to be exchanged with an token. This approach is less secure (the application/resource provider will know your password) but can be used for login to trusted applications inside a company (e.g. webmail, CRM).
•  client credential flow: use the client credential from the client registration. This typically is used for internal applications or trusted cloud integration e.g. salesforce CRM to your company.
•  devices flow: for mobile devices, smartphones, TV.

Links to tools/libraries:

• Google playground to try/understand OAuth protocol and its http messages: https://developers.google.com/oauthplayground/
• Google API lib:  https://developers.google.com/accounts/docs/OAuth2
• Scribe (a single oauth client framework for different APIs such as google, twitter, linkedin, facebook)   https://github.com/fernandezpablo85/scribe-java
• OpenConext: a complete OAuth API (authorization server, resource provider, consumer client) https://github.com/OpenConextApps/apis#apis-
• Oauth provider & consumer using Spring http://spring-security-oauth.codehaus.org/tutorial.html
• List of OAuth libs: http://oauth.net/code/
• OAuth consumer example to connect to the Dutch Surfnet https://wiki.surfnetlabs.nl/display/surfconextdev/OAuth+example+in+Java+%281%29
• Demo OAuth for devices (e.g. TV) http://oauth-device-demo.appspot.com/

OSB

Oracle OSB has functionality to access http header, so it's possible to use OAuth/OpenID with OSB web services for delegated authorization/SSO.

Recommended reading:

How to Secure Your OAuth Implementation
http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation

Source: Steve's blogs http://soa-java.blogspot.com/

Any comments are welcome :)

---

References:

Getting Started with OAuth 2.0

Programming Social Applications: