Question

I want to create a Rails application which exposes an API to be consumed by only authorised client applications (will be mobile apps for iOS / android). I’ve not started working on the app yet, but the primary method of accessing the underlying data will be through the api. I’ve been looking at using the grape gem, but would need to add an authentication layer to it. I was thinking about using devise and adding another model for storing client details, api key and secret key. Upon sign in through the api, the api key and secret are returned. The API key is transmitted with each request, but the secret key is not. Instead, it is used to sign each request; the request parameters are ordered by name, hashed using the secret key as the hash key. This signature is then added as a parameter to the request.

Does this system of authentication sound logical and secure?

I tried to prototype the system earlier, but ran into difficulty signing up a user using JSON with devise. At first I was getting a CSRF error. I then turned off protect_from_forgery and was getting another error. Is it safe to turn this off if I am authenticating in this way?

Answer 1

protect_from_forgery helps you protect your HTML forms. If you’re consuming JSON from mobile clients, you don’t need it.

Here’s what I would do if I were you:

• on user’s account page, have a button that says “(re)generate API key”

• client then embeds this key into his calling code and passes with each request.

• your API server checks whether this API key can be used with this client id.

Very easy to implement and serves well.

Signing parameters also works and I used it in several projects with success. But it increases code complexity without any real gain (secret key is on the client, attacker already knows it).