Creating an API for mobile applications - Authentication and Authorization

Question

Overview

I\'m looking to create a (REST) API for my application. The initial/primary purpose will be for consumption by mobile apps (iPhone, Android, Symbian, etc

Answer 1

So what you're after is some kind of server side authentication mechanism that will handle the authentication and authorisation aspects of a mobile application?

Assuming this is the case, then I would approach it as follows (but only 'cos I'm a Java developer so a C# guy would do it differently):

The RESTful authentication and authorisation service

1. This will work only over HTTPS to prevent eavesdropping.
2. It will be based on a combination of RESTEasy, Spring Security and CAS (for single sign on across multiple applications).
3. It will work with both browsers and web-enabled client applications
4. There will be a web-based account management interface to allow users to edit their details, and admins (for particular applications) to change authorisation levels

The client side security library/application

1. For each supported platform (e.g. Symbian, Android, iOS etc) create a suitable implementation of the security library in the native language of the platform (e.g. Java, ObjectiveC, C etc)
2. The library should manage the HTTPS request formation using the available APIs for the given platform (e.g. Java uses URLConnection etc)
3. Consumers of the general authentication and authorisation library ('cos that's all it is) will code to a specific interface and won't be happy if it ever changes so make sure it's very flexible. Follow existing design choices such as Spring Security.

So now that the view from 30,000ft is complete how do you go about doing it? Well, it's not that hard to create an authentication and authorisation system based on the listed technologies on the server side with a browser client. In combination with HTTPS, the frameworks will provide a secure process based on a shared token (usually presented as a cookie) generated by the authentication process and used whenever the user wishes to do something. This token is presented by the client to the server whenever any request takes place.

In the case of the local mobile application, it seems that you're after a solution that does the following:

1. Client application has a defined Access Control List (ACL) controlling runtime access to method calls. For example, a given user can read a collection from a method, but their ACL only permits access to objects that have a Q in their name so some data in the collection is quiety pulled by the security interceptor. In Java this is straightforward, you just use the Spring Security annotations on the calling code and implement a suitable ACL response process. In other languages, you're on your own and will probably need to provide boilerplate security code that calls into your security library. If the language supports AOP (Aspect Oriented Programming) then use it to the fullest for this situation.
2. The security library caches the complete list of authorisations into it's private memory for the current application so that it doesn't have to remain connected. Depending on the length of the login session, this could be a one-off operation that never gets repeated.

Whatever you do, don't try to invent your own security protocol, or use security by obscurity. You'll never be able to write a better algorithm for this than those that are currently available and free. Also, people trust well known algorithms. So if you say that your security library provides authorisation and authentication for local mobile applications using a combination of SSL, HTTPS, SpringSecurity and AES encrypted tokens then you'll immediately have creditibility in the marketplace.

Hope this helps, and good luck with your venture. If you would like more info, let me know - I've written quite a few web applications based on Spring Security, ACLs and the like.