Wednesday, 6 November 2013

Single Sign On and OAuth2.0 Protocol


Recently I worked on implementaton of single sign on, popularly knows as SSO, in Android applications. I came across some interesting aspects which I thought of sharing with you.

OAuth2.0 (Open Standard for Authorization Protocol Version 2.0) 


It is good to have a clear understanding of OAuth2.0 before getting into the details of SSO. When you develop a web application, a major share of time has to be spent in authentication of users and authorization of services. There are no specific rules followed to authorize users. Each web application implements its own authentication and authorization flows and it is prone to flaws as well. Nowadays every web application closely interact with many social networking sites. For proper authorization of service API calls, for example TWITTER tweet API, FB like and comments, there has to be a certain rules followed. There should also be separate flows for Web Applications, Desktop Applications, Mobile Phones or living room devices. All these factors make the life of a developer harder. In order to simplify the tasks of a developer, OAuth protocol came into action. OpenId was another protocol from which OAuth inherits many of its features.

Any service provider can implement OAuth2.0 protocol in their system. A third party application which needs user authentication can follow OAuth2.0 protocol to get their users authenticated and start consume their services very easily by following steps as given below.
  1. Register application with the service provider
  2. Redirect the user to service provider website for login or make the webservice request to service provider for login
  3. Requests for the Access Token from auth server and extracts the token from the response
  4. (Optional) Use this token to make any service call (of service provider)
  5. If you need access to service APIs beyond the life time of access token, use refresh token to get new access token as and when it is expired 



 The concept of SSO revolves around the same context. Inside an enterprise, there can be several web applications each one requires a username/password. Since the credentials are same across all these apps, a single application can handle authentication and others can communicate with SSO app for authorization.

SSO on web application is very straightforward and as per standards. But when it comes to mobile devices, there are no specific rules set for enabling apps with SSO. Lets have a look at the SSO implementation in iOS and Android devices.



Lets assume that there are 2 apps, APP1 and APP2 for which SSO has to be implemented. The best way for implementation will be to create an Cocoa Touch static library and use KeyChain mechanism to store the access token received from auth server. In fact the library should have following APIs implemented.
  1. GetAccessToken
  2. Login
  3. Logout
GetAccessToken API will check for access token in the keychain. If it finds one, validate it against TTL (time to live or lifetime). If its expired, request for a new one using refresh token.

Login API has to accept the user credentials along with app client id and secret and invoke auth server login webservice request.

Logout API will simply clears the data stored in KeyChain.



Apps in Android can't depend on libraries because of some data storage limitations in Android OS. The best way is to use a separate application; an SSO application. Other apps can communicate with SSO through a service messenger. I shall describe about the implementation in Android in my next blog.

Happy coding!


No comments:

Post a Comment