> This is no more true in my technique than in session tokens. Which is to say that it's equally true, but you're advocating for a more ephemeral storage. > P

> This is no more true in my technique than in session tokens. Which is to say that it's equally true, but you're advocating for a more ephemeral storage. > People also put session tokens in memory, and your concern about caching and consistency applies equally in that context. The blacklist is in some ways easier to manage because it is not sensitive like a session token. It's more difficult in other ways, but IMO harder to get wrong. If you're leaking session tokens your entire authN/authZ system collapses I guess that's not wrong, but it's not clear that your invalidation session is as insensitive as you suggest. For example, if your token generator's RNG has flaws, you're essentially enabling that discovery via a public stoplist store. Ultimately, it's weird to imagine using something like JWT and having a request-to-authZ scheme. You have all the equipment to do short-lived renewable tokens, and then you get invalidation (to the resolution of your timing) for free and better scaling properties and a whole host of other security benefits. I personally strongly discourage people to use JWTs at all, but if you are at least take advantage of them!