4 ms·

yeah, that is what refresh tokens are used for and it works well for access tokens with a short ttl. in practice i have seen access tokens with ttl of a few hou

yeah, that is what refresh tokens are used for and it works well for access tokens with a short ttl. in practice i have seen access tokens with ttl of a few hours. i think it might be done to cut down on the refresh calls? in that case, if you want to deny requests with a revoked token sooner than the potentially few hours it takes for it to expire, you could keep the set of revoked tokens server side. that feels like a weird place to be in with server side state for stuff that is supposed to be stateless. i guess the revoked set is smaller than the full set of active tokens so maybe that is a win? curious if anyone has experience with this.

bhl 6y ago
> the revoked set is smaller than the full set of active tokens so maybe that is a win Yeah, it seems to me the difference between having a revocation / blacklist and a non-JWT based sessions isn't the number of queries to a redis cache, since each request to the resource server will result in a check first. It's the in-memory size of the cache. I think that clears up my question about the benefits of using JWT. Thanks! :)
magicalhippo 6y ago
> in practice i have seen access tokens with ttl of a few hours The JWT tokens we get for m2m from Maskinporten[1] have a TTL of a couple of minutes. No refresh tokens though, I guess they figure it doesn't make much difference since the "user" is a machine so no hassle just sending a full request again. [1]: https://difi.github.io/felleslosninger/maskinporten_protocol_jwtgrant.html https://difi.github.io/felleslosninger/maskinporten_protocol...