3 ms·

Remember that the author’s intended audience is developers who want to use JWTs specifically to avoid server side state in the authentication/authorization log

Remember that the author’s intended audience is developers who want to use JWTs specifically to avoid server side state in the authentication/authorization logic. The point is that, if you want to revoke the refresh token, you have to maintain a blacklist somewhere, and now you’ve contradicted your original goal of avoiding all state, which means that choosing JWT for this particular purpose was illogical, and probably warrants further thought. (TBC, in logic, if your hypothesis leads to a contradiction, then your hypothesis must be false, which is exactly what we’re seeing here in this scenario.)

0x5345414e 7y ago
> revoke the refresh token, you have to maintain a blacklist somewhere Store CreationDate in the refresh token. Store RefreshTokenInvalidBefore in the user record. When refresh is attempted, if Token.CreationDate <= User.RefreshTokenInvalidBefore, reject the refresh. The only drawback here is that it would sign the user out on all devices. However, assuming this is because of a password or token compromise, that's likely the least of their worries.
james_s_tayler 7y ago
I disagree. If you make an API Gateway responsible for that concern then it's the only thing that needs to maintain state. The blacklist itself probably kept in something like Redis and the API Gateway just checks against it. Then all downstream services get the benefit of JWT in a "stateless" fashion as advertised. That is, none of the downstream services know or care about any state. They get a request with a JWT and if it has the right claims, it services the request.
kelnos 7y ago
I don't see this as rendering JWTs useless, though. If you have a 10-15 minute validity time, and you only check for revocation on refresh (and perhaps, optionally, on sensitive operations), then you don't have to check the the revoked-tokens table on every request, which means your database doesn't have to scale up nearly as much. And since the IDs in the revoked-tokens table only matter for the duration of token validity, you can prune the table pretty often, meaning necessary space needed in the DB is relatively small. It's certainly more complicated than just dealing with stateful session tokens, so you might decide that the trade off isn't worth it, though.

0x5345414e 7y ago

> revoke the refresh token, you have to maintain a blacklist somewhere Store CreationDate in the refresh token. Store RefreshTokenInvalidBefore in the user record. When refresh is attempted, if Token.CreationDate <= User.RefreshTokenInvalidBefore, reject the refresh. The only drawback here is that it would sign the user out on all devices. However, assuming this is because of a password or token compromise, that's likely the least of their worries.

james_s_tayler 7y ago

I disagree. If you make an API Gateway responsible for that concern then it's the only thing that needs to maintain state. The blacklist itself probably kept in something like Redis and the API Gateway just checks against it. Then all downstream services get the benefit of JWT in a "stateless" fashion as advertised. That is, none of the downstream services know or care about any state. They get a request with a JWT and if it has the right claims, it services the request.

kelnos 7y ago

I don't see this as rendering JWTs useless, though. If you have a 10-15 minute validity time, and you only check for revocation on refresh (and perhaps, optionally, on sensitive operations), then you don't have to check the the revoked-tokens table on every request, which means your database doesn't have to scale up nearly as much. And since the IDs in the revoked-tokens table only matter for the duration of token validity, you can prune the table pretty often, meaning necessary space needed in the DB is relatively small. It's certainly more complicated than just dealing with stateful session tokens, so you might decide that the trade off isn't worth it, though.