[yladiz]

If there is a deny list, and you have multiple services, you either do need to sync it or have a service fully responsible for this, and this does come with the burden of dealing with consistency guarantees, so it’s not as simple as “periodically refreshing the list” especially if the need is high for accurate revocation information, like if a service is dealing with very sensitive data. Handling the list is arguably a bit easier than dealing with a bespoke session, since it’s less data to handle and can be scaled more easily, but I think it’s disingenuous to argue that you “just need to maintain a single deny list”.

[lysp]

Revocation checking could be moved to the proxy level.

[motorest]

> If there is a deny list, and you have multiple services, you either do need to sync it or have a service fully responsible for this, and this does come with the burden of dealing with consistency guarantees (...)

No. Revocation is typically implemented as a shortcut to token expiration. Token expiration involves a grace period. The goal is to arbitrarily reject a long-lived token before it's expiration.

> (...) like if a service is dealing with very sensitive data.

No. That's why single-user tokens are used.