JWT opaque token || blacklist/deny list

[nik2208]

what about putting up something like this?

[nik2208]

actually a session cookie (as per dbAuth) along with the token could do the trick. One could check both the validity of the token and presence of the cookie. Removing the session cookie on logout would invalidate the actual session.
Could it be?

[mevdschee]

what about putting up something like this?

It is an interesting idea to allow for invalidating your long lived tokens. In a username/password situation one would just clear the password hash to disable an account. A JWT token cannot be invalidated that easy and that's where the idea comes from. Not a bad idea. On the other hand there is a reason why people do frequent key rotation. This is a difficult topic.

Removing the session cookie on logout would invalidate the actual session.

It would, but that's not what this is about. It is about denying somebody you once gave access to further use their token, even though other tokens signed with the same key should stay valid.

[nik2208]

It would, but that's not what this is about. It is about denying somebody you once gave access to further use their token, even though other tokens signed with the same key should stay valid.
I understand that, but storing blacklisted keys is quite expensive (from all of the points of view).

the last part of the article opens to opaque token and key rotation.
I haven't investigated enough the topic and the process though.

would be painful to implement that?

[nik2208]

in case of using auth.php pointing to the same db,
what about storing the php session in the claims array?

we could keep the session id across the api.php instances, and check the correspondence between the session stored in the claims and the value of the cookie.
Once the session is closed manually, it would be impossible to check the couple's validity with the sole token (meaning that there is no value to compare with)