[jurassic]

The more confidently people make blanket pronouncements, the less you should believe them. There are a lot of use cases for OAuth2 and OIDC that are not covered by “just use a web session”.

The real thing to push back on is the logout requirement. Everyone pretends they need this, when what almost everyone should do is just mandate appropriately short token lifetimes and revoke refresh tokens as needed.

[Aeolun]

> revoke refresh tokens as needed

That’s a logout requirement?

[jurassic]

Not as I understand it. When I've seen this discussed, a "logout requirement" has usually meant some stakeholder thinks they need a way to prevent previously issued access tokens from being used even though the tokens are signed by the trusted authorization server and not expired (i.e. still valid). This requirement asks that you find a way to instantly shut off access even though the auth server has previously issued access tokens that should entitle the bearer to perform actions against protected resources until the token expires.

Blocking refresh in the authorization server is trivial, but trying to implement the same on access tokens in the resource server at the point of use breaks the entire security model of JWT. It's unreliable, because now every resource server has to take on partial responsibility for authorization which multiplies opportunities for mistakes. As the OP points out, you need to keep track of some sort of block list and lose out on many of the benefits of JWT (i.e. a resource server being able to rely fully on claims in a signed token before allowing an action).

When people show up with this kind of requirement, in my experience, it is often because they foolishly configured a client with a very long expiration on access tokens (e.g. ~months/years instead of ~minutes/hours). This creates a problem when some aspect of a user's access needs to change (e.g. disgruntled employee was fired, customer didn't pay their bill, etc). You can address this more easily by pairing a short access token lifetime with a long refresh token lifetime.

[Aeolun]

Ah, right. Yeah, I've had people ask for that too. It defeats the whole point of the JWT though. You might as well use sessions at that point because that's essentially what they are if you want to be able to instantly revoke (e.g. check every request).

[u32480932048]

Yeah, we had a couple customers ask about this, but they were ultimately satisfied with dropping the token from the session to give the appearance of logging out (so they could log in as another user), and just decided to accept whatever risk goes along with someone copying the session token, hitting "logout", then running cURL commands for 4 more minutes.