Hacker News new | ask | show | jobs
by trebecks 2216 days ago
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.
2 comments
magicalhippo 2216 days 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...

link
bhl 2216 days 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! :)

link