I have read a few things about token authentication and there's one thing I don't understand. I thought if a user logs in with his password (via https) I generate a random token (with 'md5(random + timestamp)' ?) and an expire date and put it in the database. Now on every request (also via https?) the user can send the token and I check in the database if there's a user with that token and logging in that user. Now I've read that some tokens contain the username and a timestamp encrypted with a public/private key algorithm. What I don't understand is the reason for that. I have the token in my database and compare it with the token a user sends me. If he changes the token I don't find a user with that token and so it's an invalid token. I don't see a reason why I have to check the validity of a token on a different way? Thanks!
-
The username and timestamp aren't used to check the user's identity, they're just used to help ensure a unique token is generated. – Steve Wilkes Jan 22 '14 at 15:08
-
But why encrypting it with public/private key then and not just with md5? – user2170547 Jan 22 '14 at 15:31
1 Answers
Hashing is not Encryption: Fundamental difference between Hashing and Encryption algorithms
You need NOT to store the token on the server. The client has to store it (local/session storage) and resend it with https of course. The body/payload of the token has claims like the userId, name or email or even Roles/Permissions. Why is this info needed? Because with every ressource request you must assure on server side that the client is allowed to do the current action by checking the claims data in the token.
You validate the authenticity of the token wether some bad guy (man in the middle attack on your https connection) modified the token. This can be done with signing the token. Have a look at the json web token: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html
