I'm looking to implement stateless REST authentication into an API. I've been reading up on articles here, and have implemented an idea that works, but I was hoping to get some feedback on its security, and any potential improvements.
Initial authentication happens over HTTPS Basic Auth. Username and password are provided in plaintext.
The server generates and provides a token that is provided to the client, but is not stored in the database. All articles I've read on auth tokens suggest storing not the token itself, but some value that can be hashed with another value (the username, etc.) to generate the token again and validate - but I thought the point of a REST API was to be stateless, and not store any tokens/values related to the auth?
This token is then used for subsequent requests in place of always requiring the username/password in the headers.
The token is generated using:
encrypt(username, salt, hash, expirationDate)
encrypt is reversible using currently a DES
Cipher, but in the future possibly a private key or server-stored resource that can be easily replaced without relying on a value in source code.
The benefit is that this allows the server to decrypt the incoming token, and compare the salt/hash against what is stored in the
User model object. (Which has
hash properties stored in the database.)
The concerns I have with this:
If the private key or
Cipherpassword are known, these tokens can be spoofed.
I've considered using
hash, but I didn't like the idea of the
passwordbeing known if the private key or
Cipherpassword is found.
So: Is there a better way to do this kind of "decryptable" token authentcation? And, is it worth maintaining this "stateless" goal of REST, or should I just be storing some hashed version of the token and username (but not the token itself) in the database and throwing the "stateless auth" idea out the window?