[EdJiang]

I work at Stormpath (an Auth as a Service company) and see stuff like this all the time. It's actually really hard to do token revocation properly; People implement tokens and see revocation as a feature to be implemented "in the future".

I also noticed, for instance, that a LinkedIn app developer cannot rotate API Keys used to access LinkedIn's service. Again, the solution is to delete the app & restart. :/

[yoo1I]

Would you mind sharing a bit what makes you say it's really hard ?

[EdJiang]

No problem. It might not seem obvious when you build small-mid size backends, because in that scenario you might have an access token stored in your database that's checked each time someone makes a request. Token revocation is as easy as deleting that access token from your database.

Once you start building something at scale, it's harder to revoke tokens instantly. You still need to validate the token on each request, you need to build a highly available, fault tolerant system that can scale with the load of the rest of your application. Usually to reduce this load and improve performance, you'll see two strategies to deal with it:

Caching - check for the access token on the first request, and cache the access token for a certain period of time.

Signed / Encrypted tokens - JWTs are one example. The token contains the user ID, expiration, and other info, and is signed / encrypted. A server can read this, and knowing the signing key, verify the token.

However, if you revoke one of these tokens, it's not instant. A centralized store won't update any of the caches, and a Signed / Encrypted token lives on the client. So for token revocation, you now need to create a cache invalidation scheme, or maintain a blacklist of signed tokens.

While it's still not that hard, it'd hard enough that most teams would rather work on a new feature or something else that's on fire than figuring out token revocation.

[acchow]

> So for token revocation, you now need to create a cache invalidation scheme

To be a cache, it needs an invalidation scheme already.

Also, no one is asking for "instant" consistency on revoking a token, but at least "eventual consistency".

[seanp2k2]

Yeah, this. I don't care if it takes 24 hours to revoke it across the board, just let me revoke it somehow. Sub-second revocation isn't something that I'm aware of anyone asking for in this instance, and global Cassandra quorum should be on the order of a few seconds for massive data stores. Even with aggressive caching and long TTLs, you could do something with event notification for the rare events in which someone invalidates a token, and get it propagated within seconds around the world.

[ars]

They manage to distribute your password everywhere don't they?

IMO every auth key should always be hashed with your password (or its hash) - changing your password should automatically revoke every auth key even if you don't do it manually.

[stable-point]

When generating auth tokens for Django apps, I've previously put the user's password's salt into the token for this purpose. The salt is not secret and changes whenever the password changes.