You have a lot of options to choose from when laying out an authorization structure for mobile applications that communicate with a web API. For basic scenarios with low to medium security requirements, here is a simple strategy.
With the NSA spying on everyone, information security has been a hot topic as of late. When it comes to providing account based access on a mobile device, you might have some questions on where to start. In this post I’d like to layout one strategy we commonly employ for applications which don’t transmit highly sensitive data. We call it “Mobile PIN” or “Secret Key” authentication.
This type of secret key authentication is similar to a light weight oAuth authentication but not as robust or secure. That said, it’s much easier and faster to get up and running with.
There are two major requirements for using this style of mobile authorization:
1) The endpoint is secured using 256-bit SSL and all traffic is over https:
2) The data being transmitted is NOT sensitive
Let me be clear and say that all data is at least a little sensitive. We are talking about user accounts here after all. In this case when I say sensitive data I mean things like financial information, SSN’s, health info and the like. For normal stuff like game data, comments, app interaction, it should serve just fine to secure the transmission and validate the user. The weak point (as I’ll discuss later) is the secret key storage on the server.
The strategy works like this. You’ve got user accounts and authentication in place on your server using the membership provider of your choice. You now want a way to authenticate a user coming from a mobile app and make sure every API request is associated with an authorized user.
The first step is to add a new property to your user account on the server to store the secret key. We typically make this column a GUID (aka uniqueidentifier). It can be left empty.
Next, you add your business logic into your API’s authentication method to accept the account login and password data to be validated. For a bit of added security, transmit these credentials in an encoded fashion. Since you’re using SSL, base64encoding should suffice but feel free to use something stronger. On the server side, base64decode the data to use in your logic.
Once you’ve validated the credentials, the next step is to generate the secret key. You can do this each time the user authenticates on mobile which will always regenerate the secret key. Create a new secret key, a GUID in our case, and store it in your user profile. Then return the secret key as part of the response to the mobile device, base64encoded once again.
On the mobile device with a successful response, store the base64encoded secret key for use in subsequent API calls. There is no need to decode it.
In each subsequent API call after successful authentication, insert your secret key into the Request Headers of the call using a key “Authorization” or something similar. Then, on the server side, retrieve the Authorization value from the request headers, base64decode it, and use the secret key value to perform a user account lookup to ensure the request is allowed. In your API logic, it’s helpful to base class this functionality so it’s handled in a single location.
When you want to logout from the mobile app or force a user’s session to timeout, you can simply delete the key in either location (mobile memory or server data store). This will force the app to re-authenticate before any further requests can be made.
Considerations and Conclusion
This is far from the most secure solution on the planet but the majority of security breaches don’t come from the transmission of data (especially over SSL), they come from server side breaches. When you consider that the secret key stored on the server is as good as the username and password for API usage, you might get a bit nervous. For that reason, I recommend you take extra steps to secure the secret key on the server side. You can encrypt the key in the database, or delete the key when a user logs off (or automatically based on timeouts). Better yet, you can do both. Stay safe out there.