Thinking about statelessness I wonder how I can overcome the issue of saving the user's password on the client side in a secure but also comfy way.
I assume the client always sends credentials to the server and that uses CPU power to verify the authenticity and also make sure the user has the authorization to do whatever is requested.
That way I hope to achieve a setup where no server needs to query the database for some session info upon each request and instead wastes some CPU cycles. Of course I could add a cache to the server, but with many concurrent users what do I keep in cache and what can I get rid off? Each server would need to have a user in it's cache or look it up from the db. Now if sequential requests always hit other servers they unnecessarily hit the db or put something in their cache.
On the other hand they need to do this anyway to ensure authenticity (I mean they need to check creds) or authorization. But for the sake of the argument, let's assume they do not.
Now: How could I store the password on the client so that after an initial authentication message an arbitrary server that replies with "Credentials okay" I can reuse them, but not send them plaintext upon every request. (I mean plaintext here. Of course I need to send the password or some token upon every request, that's the essence of being stateless. If I introduce a token on the other hand, I am not really stateless anymore, am I? And if I store the salted/encrypted password from the server - given that he returns it upon initial handshake, this is also bad, I assume.)
Let's assume the client is:
a) a Webbrowser b) an arbitrary application