Hacker News Reader

Comment by dwaite | Hacker News Reader

The strategies tend to be:

1. shorter lifetimes with no other revocation system. This works well if you go back to a central party which has the actual business logic/state to decide whether to issue a new token

2. token introspection API, possibly with caching to reduce network calls/user latency

3. API-based blacklist with invalidated token identifiers (either JTI or SID)

In the first two approaches you are trying to prevent state from being pushed out to the apps at the edges.

The third approach is what I took with Distributed Token Validity API, which was basically a distributed system (via state replication or fetch + cache) to move the minimal state needed as close to the app as feasible.

View on HN

Anyone do the kerberos way, with two lifetimes? In theory this allows one time authentication, paired with continuous renewal - where refusing renewal becomes a way to invalidate the session/ticket (by way of expiration):

https://stackoverflow.com/questions/14682153/lifetime-of-ker...

Ed: Note that the service doing the renewal won't need the user/password - only a way to check if the user is blacklisted, as well as a way to sign/make tokens - and doesn't have to be the same system that issues the initial token.

Most systems use this method but over two tokens, usually referred to as a session/access token and a refresh token. See OAUTH.

Exactly. JWTs can't be extended since the signature is part of the JWT and signs the JSON body, where the expiration is.

I'd think "extension" in this case means "hand in a jwt with expiration/renewal fields still valid, get a new jwt with extended expiration".

Obviously the renewal service would need to be able to sign the new/extended token.

These are strategies I've seen. Here are some issues with each:

1. The shorter the lifetime, the more JWTs and refreshes are needed. This includes the signing and verification, both of which can be heavy operations depending on key length.

2. Token introspection is a coupling hub and spoke. If every service needs to introspect every JWT, it will be coupled to the introspect API. While that isn't horrible in some cases, it can be a nightmare in others. Additionally, new services need to always remember to use this pattern. You can get around this with an API gateway though. In either case, the introspection API either needs to store all the JWTs (in memory or a database) to determine if they have been revoked, or use some other mechanism to determine revocation. If you have large numbers of JWTs valid at any time, this doesn't scale well.

3. This is basically the same as my approach. It sounds like you are using a distributed cache. I'm using Webhooks and multiple local caches. Basically the same thing if your Webhooks are written properly.

FWIW, I discourage the use of Webhooks (mentioned in the article) because they aren't reliable. An application cannot easily detect if a logic or network issue has caused it to stop recognizing invalid tokens.

Adding a transaction around the webhook could help with this. At least you'd know for sure everyone has agreed upon the state of the user.

But agreed, webooks in general are not excellent for critical events in general unless there are additional ways and of confirming receipt and confirmation.

I'll add on to what @robotdan mentioned. A distributed cache is basically a Webhook approach to pushing cached values around. If your Webhooks (or whatever you want to call them really) are transactional, then the state sync is handled and guaranteed by the nature of events and the server generating them.

Reply on news.ycombinator.com