In my previous post, I talked about how OAuth allows users to grant third-parties access to their web services without sharing their passwords.
In that previous example, our user (Bob) accessed his Twitter account through the bit.ly web site.
This time, let's look at what happens when Bob is using a mobile app instead of a web app.
It’s pretty much the same for a mobile app as a web app. When you fire up your mobile app and want to access Twitter, you don’t want to have to give the mobile app your Twitter password and store it on your phone.
In the same way as happens for the web app, the phone app opens a browser window and directs Bob to login to Twitter (and authorize bit.ly to use his Twitter account) - using OAuth.
The phone app never sees Bob’s Twitter password.
The phone app uses its OAuth credentials to retrieve credentials for Bob. It stores these locally. In this way,
OAuth allows this one phone app access to the Twitter service on behalf of one user (Bob).
This all happens through your browser. There are both advantages and disadvantages to this:
- The advantage of this is that the app never sees your password.
You don’t have to trust the person that built the app or worry about losing your phone (as much).
If Bob loses his phone, he can log into Twitter and revoke the credentials that Twitter gave the phone app. (A thief cannot uncover the password, only the token.)
- The disadvantage is that the app has to open up a browser window. This possibly breaks the flow of a nicely designed UI for a mobile app.
There are ways in OAuth around this but you eliminate many of the security reasons for OAuth in doing so. Twitter and Facebook for example, have made the choice to have everybody log in through the browser.
Next time: Why OAuth is good for API providers.