Service-Based Authentication Using Tokens

Question

I'm having a tough time trying to find clear and concise examples of how one would implement a service-based authentication scheme using tokens. As far as I can tell, the basic steps are as follows:

1. Client requests username/password from user
2. Client passes username/password to identity provider
3. Provider checks username/password and sends back a token if the user is valid
4. Client does something with the token?

The third and fourth step are where I'm getting stuck. I assume the "token" in this case just has to be either an encrypted string that the client can decrypt or some random string that gets stored somewhere (i.e. a database) that the client can then verify against, but I'm not really sure what the client is then supposed to do with the token or why you even need a token at all -- couldn't a simple user ID also suffice?

Answer 1

This seems a lot like how Kerberos works.

Answer 2

A typical token is a random hash that's stored on the server side. The client passes it back with its requests. What this gets you is that you don't have to pass around the password all the time, which is obviously all to the good, and the token can be invalidated any time you like without having to change the password.

Answer 3

I found this documentation for Amazon S3 useful when I was looking into the same problem.

Authenticating REST Requests

The general principal is you don't want to be passing around your user name and password for each successive service call as this wouldn't be that secure.

You mentioned about just passing the user name back to the service however again this would not be very secure.

You might be thinking of using session state to store the fact that a user has been authenticated, however this against one of the general principles of REST whereby everything should be stateless.

Answer 4

I assume the "token" in this case just has to be either an encrypted string that the client can decrypt or some random string that gets stored somewhere (i.e. a database) that the client can then verify against, but I'm not really sure what the client is then supposed to do with the token or why you even need a token at all -- couldn't a simple user ID also suffice?

No - the token is a "ticket to ride." Just like a subway token. The client presents it to the gatekeeper when requesting service. In this case the provider does its own authentication, so the client presents the token back to the provider. In some cases the provider might delegate authentication - for example in the STS model, in which case the provider might hand the token off to a third party for authentication and even authorization.

From the service point of view, this token must:

• have a "shelf life". Otherwise, the token would be infinitely re-usable. So on the server-side, you can store the token in a session-based store, where you will get timeout for free. Or you can build a simple hashtable with expiration.
• be associated solely to the holder. In many cases the provider uses an approximation here and asserts that the token can be used only from the original requesting IP address.

So in step 3, the provider needs to check the username and password. If that validates, then create a token (hash), which refers to an entry in a Dictionary or Hashtable. The objects in the Hashtable are structures containing the username, the IP address, probably the original time-of-issuance, maybe the roles associated to the username, and whatever else you want to store. The service provider sends back this token - the hash, not the structure - to the client, typically as a Set-Cookie. When the client sends back the token (as a Cookie) on subsequent requests, the provider checks the dictionary to see if the token is available, has not timed out, matches the requesting IP address, is authorized for the requested resource, etc. If everything is ok, honor the request.

Answer 5

Web service with sessions...hmmm that's not how it should be. Web services are not meant to keep state.
I looked around on the web and most examples and articles talk about SSL/TLS + username/password. It would be nice to replace the username/password with "API key" infrastructure, but i have no clue how to "architect" such a thing...