> In short, servers are free to reject any token, which triggers a token refresh on the client-side.
Servers can of course implement whatever custom behaviour they desire, but the protocol itself (and common implementing libraries) does not have any direct support for revocation.
Furthermore, any revocation implementation will inherently have to compromise the statelessness that is JWT's most prominent selling point.
> Token revocation is even an intrinsic aspect of JWT as they suport issue and expiry timestamps, along with a nonce to avoid replay attacks.
JWT does indeed support expiry and nonces. But these are not the same thing as revocation.
> It seems some users have an axe to grind regarding the idea of having to keep track of some tokens that were poorly designed (i.e., absurdly long expiry dates without a nonce) but the solution quite obviously is to not misuse the technology. In the very least, if a developer feels compelled to use a broken bearer token scheme that does not expire tokens based on issue date then quite obviously he needs to keep a scratchpad database of blacklisted tokens to compensate for that design mistake.
Insults and "obviously"s are not a good way to convince people of your point of view.
> Servers can of course implement whatever custom behaviour they desire, but the protocol itself (and common implementing libraries) does not have any direct support for revocation.
That's patently false. The protocol does support revocation. In fact, its basic usage specifically states that servers are free to force the client to refresh its tokens by simply rejecting it. If a JWT is expected to be ephemeral and servers are free to trigger token reissues, what lead you to believe that JWT didn't supported one of its basic use cases?
> Furthermore, any revocation implementation will inherently have to compromise the statelessness that is JWT's most prominent selling point.
That's false as well for a number of reasons, including the fact that JWT use nonces to avoid replay attacks. And additionally JWT's main selling point is that's a bearer token that's actually standardised, extendable, provided as a third party service, and is usable by both web and mobile apps.
> JWT does indeed support expiry and nonces. But these are not the same thing as revocation.
Expiration timestamps and nonces automatically invalidate tokens, which are supposed to be ephemeral, and nonces are a specific strategy to revoke single-use tokens. As it's easy to understand a bearer token implementation that supports revoking single-use tokens is also an implementation that supports revoking tokens, don't you agree?
> Insults and "obviously"s are not a good way to convince people of your point of view.
Perhaps educating yourself on the issues you're discussing is a more fruitful approach, particularly if you don't feel confortable with some basic aspects of the technology and some obvious properties.
Servers can of course implement whatever custom behaviour they desire, but the protocol itself (and common implementing libraries) does not have any direct support for revocation.
Furthermore, any revocation implementation will inherently have to compromise the statelessness that is JWT's most prominent selling point.
> Token revocation is even an intrinsic aspect of JWT as they suport issue and expiry timestamps, along with a nonce to avoid replay attacks.
JWT does indeed support expiry and nonces. But these are not the same thing as revocation.
> It seems some users have an axe to grind regarding the idea of having to keep track of some tokens that were poorly designed (i.e., absurdly long expiry dates without a nonce) but the solution quite obviously is to not misuse the technology. In the very least, if a developer feels compelled to use a broken bearer token scheme that does not expire tokens based on issue date then quite obviously he needs to keep a scratchpad database of blacklisted tokens to compensate for that design mistake.
Insults and "obviously"s are not a good way to convince people of your point of view.