I have this really neat token-based authentication scheme that does not require a session-store on the server. On every authenticated call, an encrypted JSON payload is sent in a header, which holds the session information. The server can just decrypt the JSON token and grab info like the userId, organizationId, expiry, etc. This is ultra badass and I love it.
A customer asked today if he was able to just share his login credentials so that other people on his team could login. In my current system, this is possible. Problem is, we charge by the seat, so we don't want to allow credential sharing.
I'd love to keep my stateless auth mechanism, because it really impresses the ladies. I'd rather not have to install something on the server that keeps track of which users are currently logged-in, or whatever.
But I can't think of a stateless way to prevent people from sharing credentials. Is it possible?
Stateless... you're never really 100% there. I thought adding this to your mechanism but I don't recommend it...
Let's look at your token, it's about how you generate it, you're probably currently storing some random number on database somewhere, so you already have some state. Instead what you would do is generate the token based on client's identifiable information when he logs in. Such as User-Agent string and IP address. Then make a checksum for these values along with some token (such as a salted password) you have stored on server.
As the authenticated requests come in, you would have to re-create the Token each time to check if it is valid, making it computationally expensive. Could this also potentially be a security risk, exposing your clients salted password?
But what's the point in doing this? You'll force your clients to re-auth every time their IP changes. Instead play it cool and detect multiple IPs and user agents using the same account, then block the account for an hour or so.
It is much better to hold entire session information on the server, you won't have to spend processing power, storage is cheap, memcached for sessions isn't that bad. And, you forget there's a bit of a fallacy in saying you have no state... for you still store a token on the server.