Token revocation
biscuitsec.org
Token revocation
1–10 of 36 posts
Re: Token revocation
#2I'm still skeptical whether expiration times wouldn't be adequate for many applications, assuming these times are short enough, like five minutes?
Re: Token revocation
#3I'm still skeptical whether expiration times wouldn't be adequate for many applications, assuming these times are short enough, like five minutes?
This approach doesn't really solve anything. If you have expiration times that short you will need a mechanism for renewing tokens and a compromised token can be renewed all the same. All you have is slightly higher server load because your regular users need to renew their tokens all the time.
Re: Token revocation
#4I'm still skeptical whether expiration times wouldn't be adequate for many applications, assuming these times are short enough, like five minutes?
A malicious actor can do quite a lot in 5 minutes. And now you've got to have your users/services renew their authentication at least every 5 minutes, meaning there has to be some central authentication authority to be renewing through... which completely defeats the whole decentralization thing and is more complicated than just issuing randomized tokens and keeping hashes of those in Redis.
At best, you've got a system where a malicious actor doesn't think to renew their token fast enough.
Re: Token revocation
#5I'm still skeptical whether expiration times wouldn't be adequate for many applications, assuming these times are short enough, like five minutes?
This approach doesn't really solve anything. If you have expiration times that short you will need a mechanism for renewing tokens and a compromised token can be renewed all the same. All you have is slightly higher server load because your regular users need to renew their tokens all the time.
If your access token is compromised, you would normally need your refresh token to get a new access token? So it would increase security, but if you lose your refresh token, you def have the same problem.
Or am I missing some context?
Re: Token revocation
#6I'm still skeptical whether expiration times wouldn't be adequate for many applications, assuming these times are short enough, like five minutes?
A malicious actor can do quite a lot in 5 minutes. And now you've got to have your users/services renew their authentication at least every 5 minutes, meaning there has to be some central authentication authority to be renewing through... which completely defeats the whole decentralization thing and is more complicated than just issuing randomized tokens and keeping hashes of those in Redis. At best, you've got a sys…
[deleted]
Re: Token revocation
#7Biscuit has been one of those pieces of tech that makes me re-think the way we organize our stack, with a couple of key ideas that make us more user-centric and enable decentralized systems.
Granted I haven't used it, on toy project or in anger, but it sounds really neat.
Re: Token revocation
#8I'm still skeptical whether expiration times wouldn't be adequate for many applications, assuming these times are short enough, like five minutes?
Same idea with certificates right? No-one checks certificate revocation lists, so Google is shortening maximum lifetimes reducing chance of long-time malicious use.
Re: Token revocation
#9You're still stuck with a delay of you fetching the list of revoked tokens and someone getting to your service.
And that delay allows someone to come in with a compromised token.
However, with short expiration dates you achieve the same. You shorten the duration that a token is valid for.
Assume a token is revoked. It can be used against any target until they refresh their revocation list.
Same goes with just tokens with a short expiration date. It can be used against any target until it expires.
I guess the difference is users extending their token lifetime more often (more load for your signing server) vs offering an API that you can use to share revoked tokens which needs to be checked every time (in which case it's no longer stateless) or checked every once in a while.
Pick your poison.
Re: Token revocation
#10Earlier quoted context omitted.
This approach doesn't really solve anything. If you have expiration times that short you will need a mechanism for renewing tokens and a compromised token can be renewed all the same. All you have is slightly higher server load because your regular users need to renew their tokens all the time.
If your access token is compromised, you would normally need your refresh token to get a new access token? So it would increase security, but if you lose your refresh token, you def have the same problem. Or am I missing some context?
Depends. Some systems allow for access tokens to be extended, some don't.
We only use refresh tokens for mobile devices as those can be security stored.
Access token renewal is allowed for browsers for as long as we detect a valid session.
And that session cannot be extended. Every 8 hours it's back to the authentication page with your YubiKey.