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
The token is generated using:
encrypt(username, salt, hash, expirationDate)
Where 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 salt
and hash
properties stored in the database.)
The concerns I have with this:
If the private key or
Cipher
password are known, these tokens can be spoofed.I've considered using
password
instead ofsalt
andhash
, but I didn't like the idea of thepassword
being known if the private key orCipher
password 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?