1

I have been looking on a lot of questions about REST API and security and found some interesting informations but there is still one thing I don't understand.

So, I have a REST API developped with Zend Framework with basic authentication over an https channel (so if I understoud what I have read, the login/password are encrypted when they are sent). The purpose of this API is to be called by Android/iPhones apps and will only be available to people who have a login and a password

SO, currently, to call the API, the login and password are always sent with the call and so, I check them at every call (the result is it makes a call to the database just for authentication at each call to the API).

Is there some kind of session management (as in web developpement) to avoid that?

Thank,

Olivier
  • 3,121
  • 2
  • 20
  • 28

1 Answers1

0

REST API should be stateless, but you can use request signing using some secret key you obtain after first submission of username + password.

In other words, do not send username and password every time, just use once, to obtain secret key.

You may take a look at several APIs that sign the requests, eg. some implementing OAuth.

Tadeck
  • 132,510
  • 28
  • 152
  • 198
  • So, if I understand, First request, I send the username and password, then the server sends me a secret key that is used then by the client to call the API. So, I have to store this secret key (I suppose I have to generate one "randomly") in the database so I still have to make a request in my database at each call right? Second question : how long is this key supposed to be valid? I had a look at how twitter works (it uses OAuth2) but I have to admit that I did't really understand :/ – Olivier Aug 10 '12 at 21:35
  • @user1571681: Basically "it depends" :) You have to basically be able to use the same secret key both on the client and server, even though you are not exchanging it in any request after the first one (you are using this secret to sign requests). This secret does not need to be stored in the database, but it is the most common approach. It should be random and thus hard to guess, but it is not required, if you do not need that kind of security. You can invalidate the key in a way you want - it may be permanent, but choose reasonable time limit depending on your API. – Tadeck Aug 10 '12 at 22:24
  • @user1571681: When it comes to OAuth, it may be hard to understand at first, but the clue is that user authenticates on Twitter site and then is redirected with specific access token passed to the client app. The client app then exchanges it for request token, which is being used as the secret key I described. Every request in your API should be signed (build string from information identifying your request, such as HTTP method, body, content type etc. - and append secret key, then hash the whole thing using eg. `sha1` algorithm). You are in charge of what your API uses, but may base on OAuth. – Tadeck Aug 10 '12 at 22:28
  • Thanks for all your reply. I have just watched this long video (http://www.youtube.com/watch?v=M42ouAgPCQI) and I know understand how OAuth works, I put the link as it is a very good video I think. I will probably store the keys in my database but in a small table (to increase select performances). I will also go for permanent key and let the user be able to revoke it from his profil in the website (it is mobile is stolen for example). Well, now I have to find out is there is an easy way to build an OAuth server with Zend Framework... :) – Olivier Aug 10 '12 at 23:16
  • @user1571681: Nice, I am happy you have solved your problem :) When it comes to building OAuth with Zend Framework (or any other framework), you are looking for _OAuth provider_ library or module. I do not know, if that was described in the clip you have linked (I wish to watch it myself), but your API will be _OAuth provider_ (thus you can use existing modules for it), as opposed to _OAuth consumer_ (the mobile app/site). You can start looking for OAuth provider in ZF [here](http://stackoverflow.com/q/4061435/548696) and [here](http://stackoverflow.com/q/3553044/548696) (both dated 2010). – Tadeck Aug 10 '12 at 23:30