In this post I will take a look at what purpose OAuth authorisation protocol serves, how it is being used in mobile application world and how is it relevant to a mobile commerce applications. The first part of the post describes most common OAuth scenarios in mobile commerce apps, the second part is about the actual technical usage scenarios.
OAuth enables your mobile application to gain the permissions from account owners (who as well happen to be your mobile application users) to perform certain tasks on their behalf. Be it requesting the list of their Google contacts, requesting the information to access their Twitter and Facebook posts or do the actual update on their social walls.
OAuth is the standardised approach to such authorisations and is supported by many leading technology companies like Google, Facebook, Twitter and others. This means your mobile application will not need to use multiple and different protocols to request permissions for acting on the user behalf on most popular cloud platforms. Most of popular social and cloud platforms do support OAuth or have actually participated in designing process of this protocol. If you are interested to read more about it’s history, I recommend to check out this post.
The use of OAuth?
How useful OAuth can be for your mobile commerce app?
In the most cases mobile commerce apps do integrate with many external services and other applications. For example:
price comparison services,
payments and many social platforms for product marketing. Most of them do allow mobile app to consume personalised, user specific data, given that user authorises mobile app to consume it. OAuth protocol enables such authorization.
OAuth and OAuth 2.0
OAuth protocol was accepted well by application architects and developers as unified approach to authorisation. But the big downside of it was very complex encryption process for token requests. Cryptographic signature used to protect the request had to be generated by client application and this added great layer of complexity.
Another downside which was not so relevant in 2007 (the year OAuth was initially created) but is most relevant now days is that OAuth was built for traditional server side web environments. In today’s digital commerce world we have more complex cases mostly involving mobile based applications needing authorisation from their users for interacting with multiple cloud platforms.
OAuth 2.0 is addressing these and other downsides.
Typical OAuth 2.0 flow in the mobile commerce application
If we divide mobile applications for smart platforms like Android, iOS, Windows Phone into 2 categories we get: native applications which are build with native platform SDK’s and run as integrated apps and the HTML5 based mobile applications which are run by involving web browser engine on the smartphone.
OAuth 2.0 authorization flows are defined by grant types which are used for obtaining authorization token. There are 4 primary types.
Authorization code, which is most suitable for standard server side web apps as it involves user redirection to external hosted authorization page and later the server to server communication.
Implicit grant is the flow in which access token is provided back as url fragment and is most suitable for web browser based applications. If you are designing mobile commerce app to be built using HTML5 this OAuth flow could be good fit for your app. It doesn’t allow for refresh tokens though.
Password based grant is the scenario where users username and password are exchanged for OAuth token. Such flow is only recommended for trusted apps as user credentials will be visible to mobile application.
Client credentials flow is used for pre-aranged authorization and is used while applications are requesting authorization on behalf of themselves and not the user.
What flows in mobile commerce apps?
If your mobile application is native, the implicit grant or authorization code flows. Many cloud platforms do provide OAuth native mobile SDK’s you can integrate into native mobile commerce apps.
For HTML5 based apps first choice is usually implicit grant flow but it doesn’t provide refresh token option. In case if you want to store refresh tokens for auto refresh later authorization code flow might need to be implemented.
In second part of this post I’m going to go through the actual implementation examples for the OAuth 2.0 flow scenarios in mobile commerce applications we discussed above. For both native and HTML5 based mobile apps.