CODEWITHSUNDEEP
web-servicesauthenticationrest
jerhinesmith
jerhinesmith

Reputation: 15502

Service-Based Authentication Using Tokens

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?

Upvotes: 13

Views: 12565

Answers (5)

Cheeso
Cheeso

Reputation: 192577

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.

EDIT 2013 June

It's been several years now, and this answer is still getting votes. I'd suggest that people look into the OAuth 2.0 Framework, and Bearer tokens.

Basically they do just what is described here.

If you want a good example implementation, you can look at Apigee's Usergrid. It works this way:

  1. User Authenticates

    POST https://api.usergrid.com/token -d '{"username":"Joe","password":"Sec4et!","grant_type" : "password"}'

  2. User receives an access_token in response

  3. User makes subsequent calls with header Authorization: Bearer XXXXXXXXXX where XXXXX is replaced with the bearer token. This token has a Time-to-Live set by the usergrid server.

Upvotes: 26

redben
redben

Reputation: 5686

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...

Upvotes: 0

gsobocinski
gsobocinski

Reputation: 295

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.

Upvotes: 1

chaos
chaos

Reputation: 124325

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.

Upvotes: 1

grawity_u1686
grawity_u1686

Reputation: 16532

This seems a lot like how Kerberos works.

Upvotes: 0

Related Questions