Having been involved in quite a few service-related activities in the last year or so, I’ve been having a few thoughts about what I’ve learned from this and what decisions I make when designing a service. Hopefully there will be a few of these posts – but to start with, I’m considering the options for authorising users.

Quite a lot of services don’t require any authentication at all, similar to quite a lot of the web. In either setting, the information is there for users to consume when they want. However the difference comes when services start doing more than making data available. If changes can be effected by the service, then we need to identify who is requesting the change.

Traditional websites use a username and password, and we can do exactly the same thing here. Services work on a series of discrete requests and its common to require that the username and password be supplied with every request. However for high-load services or where a particularly fast response time is needed, we can use something similar to sessions, where the user first has to authenticate and is given a token. On subsequent requests they supply the token and we wave them through without requiring their credentials again.

There are a number of considerations involved in deciding whether this setup can work for a particular application:

• Does it take time to authenticate? For example is there an external system to wait for or lots of user information to retrieve?
• How guessable is the token? Any kind of reasonable length hashing will help you here. I tend to use salted md5 tokens*.
• How long will the token be valid for? If interaction with the service is likely to be a burst of related requests, you might allow validity for 30 minutes for example.
• Will you require other identifying information as well as the token? For example you might require that the user also supply their username, which would have to match the token. I’ve also seen systems which only accept tokens from the same user ip address as the user’s original authentication call came from.

Also think about storing these tokens. They can go in their own table along with the information you want to use frequently – this is the same idea as storing information about a user in a session, for example. So user id, maybe display name plus the token itself, some information about when it was created or when it expires, and anything else that will be needed to check the token’s validity. With this information being independent and just used to verify the user, there is also the option of storing this in an alternative, faster, mechanism such as memcache.

This isn’t by any means everything there is to think of, but just some ideas of things to consider when designing a service.

* I blogged about salting md5s in PHP recently, if you are interested