I have clients which are all browsers. All clients render just a single page application getting data from a Web API. The design of the API follows REST principles.
I use token-based authentication without OAuth because I have no third parties for my API and I want to feel how security can hurt my brain ;-)
The format of my token I issue is Json Web Token (JWT): It contains the userId, lifetime (exp date), issuer and signing key (alg: HS256 which is SHA-256 hash algo)
The token is valid 7 days. So the user has to reauthenticate every 7 days. (Maybe thats not yet the final solution in this field...)
This is my authentication flow:
1) I use basic authentication over SSL for my login endpoint
2) If the user`s sent username and password are valid I put a token into the response
3) This token is stored in the local/session storage on client side
4) Each further request to a ressource endpoint of the server API must include a valid token else the request gets a 401 and sees the login view again.
5) Before I do further investigation with the token like checking its expiration date I need to know wether the authenticity of the token is still valid or a legit user has modified it. This assumes that the token was signed with a key before which we call MAC (Message Authentication Code)
I validate the token with the same signing key the token was signed during token creation. I store the signing key which is a bunch of randomly generated numbers in the user sql table belonging to the userId. The userId I get from the token see above. Or better said I store the hash of the key (byte array) in the user sql table hashed with BCrypt.
Is there something wrong I do?
Should I store the full token in the database instead of the signing key only and whats the advantage?