Erlang/OTP: authorization/authentication in RESTful applications

Question

I am in the process of designing an Erlang/OTP application which will expose its services (SOA) via a RESTful API.

The services, which comprise the backend will be a database service, a price calculation service, etc.

The clients can be of many types: a web client, mobile clients, an Asterisk server client (which needs to look up user records in the database service) and even the clients which I do not plan to have and do not know about yet. The clients will use the RESTful API differently: some will consume all the services, some will consume just some of the services (the SOA way).

The main concern that I have is the authentication/authorization.

I can not use the built-in authentication/authorization of Ruby on Rails, because the web-client is just the one client of many possible clients that will use the application via the RESTful API.

So, my question is:

• what is the general concept of authentication/authorization for a typical RESTful web application which is expected to be used with many different clients?
• what is the most practical software design pattern for authorization/authenication in a RESTful web application?
• what Erlang/OTP open source software libraries could you recommend to implement authentication/authorization for such an application?

Answer 1

Just check how others are doing this, for example in this article: Authentication on Facebook.

In general the idea is that there is a separate API call that the client calls in order to authenticate itself to the system. The system may accept any client or only from a list of registered clients. Once the system verifies the client, it issues a special token that the client is then using in all API calls. In Facebook documentation it's called Access token. If the client tries to call an API without a valid token the system reports this as an error and in certain conditions may block the client.

In REST the token may be send simply as another parameter in the URL, in POST or as additional field directly in JSON. Sending it as POST or in JSON is probably best as it keeps the URL clean (and won't collide with any caching that may be based on URLs).

This is the merit of the idea but there are, as usually, more things to consider. For example the token should be difficult to guess so the client isn't able to recreate a valid token without authenticating with the system. Also, the system may need to expire the token if no API is called within a specified period of time.

To answer the last part of your question, some libraries to point out:

• erlang:phash2 or crypto library can be used to generate unique tokens that aren't easy to guess
• Webmachine as an excellent framework, or REST toolkit as they like to call it, to create REST interfaces in Erlang
• the logic behind API calls could be implemented in Erlang and served directly from a web server, e.g. inets or yaws, or it can be implemented using a web framework like Nitrogen or Chicago Boss. Check this list of Erlang web frameworks.