Auth Mechanisms for Web Services
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
“A Secure Cookie Protocol” outlines a scheme for tokens, without the need of server side storage.
Auth web services is pretty similar to auth normal apps. It’s actually the same that old simple PHP session mechanism works. You check login and password, then you start session and token (session id) is generated that is stored at server side and passed by the client with each next request (either via cookie or uri). Nothing really changed.
Ren: Thanks for adding that link, I’ll definitely take a look!
Sobstel: I agree but its funny how moving the context leads people to solve problems that either aren’t there or they bring out quite unconventional solutions! As you rightly point out, there is no need.
I have been thinking, writing and speaking a little bit about web services recently, starting with a few thoughts on authorisation mechanisms for services. Today we’ll look at another really important aspect of authoring web services, and one feature tha
This is a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services, auth mechanisms for web servicesand
This the last entry in a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services, auth mechanisms for web services, saving state in web services and using version paramet
Over the summer months I wrote a series of posts about designing APIs in general, and web services in particular. This included posts on status codes for web services, error feedback for web services, auth mechanisms for web services, saving state in web
This is a mini series on points to consider when designing and building web services. So far there have been posts on error feedback for web services and auth mechanisms for web services. Web services, by their very natures, are stateless, and this is