Most mobile apps ask users to create an account. There are various reasons behind it, like loading user preferences, access data storage etc. Once account has been created a user is asked to authenticate and authorize a mobile app (if applicable). The question of securing mobile API is quite popular at stackoverflow.com which means developers do think about it and it is very important since exposing users credencials and personal details can be a big deal. The challenge here is to make authentication dead simple for users but at the same time make it secure. That’s quite a challenge.
Authentication vs Authorization
First, let’s make sure we differentiate the terms. Authentication is proving that you are the owner of an account. In other words, a user has to prove he’s the one he claims to be. It is something like a driver’s license or a travel pass. Authorization is letting some other app and service prove it. This is what happens when you log in with Facebook or Google - you are asked if you let a particular app or service access your Google or Facebook accounts to get authentication tokens. Google and Facebook oAuth are very popular and your mobile app should definitely have it.
Basic HTTPS Authentication vs oAuth2
Basic https authentication is so great because it is so simple. To be able to access your mobile app API, you need an authentication key. You request this key, obtain it in a response and now have to store it on the server. Then, when making any API call you have to include this key into the authorization header which will then be transformed into a special token.
This approach works just fine, but there are a few buts. First off, you have to make sure the key (normally, it’s an ID:secret pair) is securely stored on the server. Secondly, authorization header is passed with the API call each time you make a request. Hackers love such API calls since it does not take long to steal it, transform into a token and abuse the system. Thus, storing this information and exposing it in every API call are the two big risks.
oAuth2 is a smarter solution. Instead of storing the key on the server, it is stored on a mobile device (or as a cookie is it is a web app). But first things first. Let’s take a look at the entire flow:
- mobile app is launched and a user is asked to log in
- username and password are sent in a body of a POST request to your server (of course, over SSL, i.e. encrypted)
- you then need to validate credentials. Most probably, they are stored in a database, so you have pull them up and compare.
- if credentials are OK, you issue an access token
- this token is saved in a mobile device
- there’s an expiration period for a token (it is you who decide when this token expires. It is not recommended for a token to live too long, as well as token per session is also not the best solution).
- when this token expires, an app asks a user to authenticate again
Using 3rd Party Services to Authenticate
Over 50% of users will walk away if they have to create an account by entering desired username, email, password, personal info like name and last name. Sad but true. Users are lazy. This is where oAuth comes into play. Perhaps, you have seen that many apps and services have those Google and Facebook buttons on their login pages. Isn’t it cool just to click it and get yourself an account with a new app or service?
In this use case, a user clicks this social login button, an authorization request is made. This request should have an application client ID. This is a developer application registered with the service that is used as a social login provider. The app will produce an authorization code (received in a callback URL). This code is then converted into an access token. Such a conversion is only possible if you have the application secret. Both secret, ID and callback URL are provided when you register a developer application with Google, Facebook, Quora, Uber, Snapchat etc. Simple and powerful!
Market Leaders
If you wonder how big boys handle authentication, you will discover that it’s oAuth1a or oAuth2. Uber relies on oAuth2 and provides API that let developers integrate with Uber from their applications, for instance providing an opportunity to login with Uber credentials.
Yelp uses oAuth1a requiring oAuth signature and signature methods, as well as timestamps. Snapchat also uses oAuth2, and when a token is generated its validity is set for a particular period of time.
It needs saying that using one common standard (oAuth2) greatly simplifies integration of services and application adoption among users and developers. In fact, devs love it when they see that it’s oAuth2 which means they do not need to read any specs - just API docs of mobile app API.
Risks
To sum it up, a mobile app authentication model should solve the following problems:
1. Data storage. Any data on the server should be accessible to admins only. No 3rd party access should be allowed. If data is stored as cookies, they should be access this the current domain only, otherwise scripts from other side may easily steal them.
2. Harmful code injection. Yes, client side may remain unprotected, and injecting a simple script may cause problems. Make sure, no one can inject anything into your client side code.
3. Reasonable token expiration time. It is up to you, but it is better to ask users to re-login once in awhile.
4. Proper data encryption. Yes, SSL solves a lot of problems, but the world is moving faster than you can think. Always check for data leakage.
5. Inputs from outside channels. Without proper checks the app will accept input from any channel - this is what hackers always hope for!