1

I have a REST Jersey web service.

My question is about the answer of this question, please check;

token based authentication in php

In that answer its mentioned that;

"It then sends a hash of this token and certain characteristics of the request to authenticate the request, e.g. sha1(Token + Timestamp + Request URL + Request Body). Your server can validate this without the client having to send the token in plain text on each request."

Can anyone explain how can the server validate "without the client having to send the token in plain text on each request" ? Client should to send token each time to server?

Another question is, once the server receives a hash of this token(which includes timestamp and userid..etc) How will server identify the user from this token without having a look table or DB where tokens are stored?

Community
  • 1
  • 1
Spring
  • 11,333
  • 29
  • 116
  • 185

2 Answers2

1

For the first question: the client can send a hashed version of the token and the server compares hashed value with the value received from the client.

For the second question: you can keep a mapping between token and user in memory or on disk or wherever you think appropriate.

Dan D.
  • 32,246
  • 5
  • 63
  • 79
  • could you also look at this? http://stackoverflow.com/questions/14003334/what-is-the-point-of-authentication-tokens-on-rest-services – Spring Dec 22 '12 at 13:45
  • ok so server keeps a list of all tokens, and client sends the token everytime. – Spring Dec 22 '12 at 13:46
  • Basically that's the way I implemented it in the past. – Dan D. Dec 22 '12 at 13:50
  • so I dont really need to create a token with all that information inside matched with a user id? in theory it can be any unique key, and all I need to know is if my DB contains that uniqe key and which user does it belong to – Spring Dec 22 '12 at 13:53
  • Something like that. On the server side you definitely need to know at least if the token belongs to a valid user or not. – Dan D. Dec 22 '12 at 13:54
0

This is an oversimplified example of an approach which employs encryption/decryption of a portion of the authorization token using a secretkey which exists only on the server side. The AUTHORIZATION_TOKEN can be sent to the client which would be transmitted in any subsequent request.

1) To log in, user sends userid, password, sessionid, timestamp
2) On successful validation server produces TOKEN = encrypt(secretkey, userid + sessionid + time_stamp).
3) Server sends AUTHORIZED_TOKEN = TOKEN + userid + sessionid + timestamp to client
4) Client sends this token with each and every request throughout the session
5) Server decrypts TOKEN portion of AUTHORIZED_TOKEN then unpacks and compares the decrypted userid, sessionid, timestamp from TOKEN and compares it to it's plain text counterpart in AUTHORIZED_TOKEN.
6) If there is any inequality, the server redirects to the login page.
7) No important info sent in plain text.
8) Secretkey only exists on server side
9) No user mapping to disk or memory necessary as token contains userid

Oliver
  • 76
  • 1