Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Token revocation

biscuitsec.org

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Token revocation

#31

Post by buzer »

jcrites wrote: post #24

> It is now recommended to have a refresh token with an expiration date, that can be long, and have that refresh token be single use. When it is sent to the authorization server to get a new access token, the authorization server will revoke the old refresh token and issue new refresh and access tokens. I've been wondering briefly about this specific flow. It seems prone to a problem: if the refresh request gets sent…

One option could be to require that the access token needs to used within X seconds after it has been issued. During this period:

* Old refresh token can be used. Using it will revoke previous "new" tokens (and possibly generate some warnings, especially if new tokens are used after this)

* Using new access token will revoke old refresh token and access tokens, possibly requiring access on dedicated path (something like lookup, essentially confirming that you received it)

This probably should be rate limited to avoid malicious/buggy client filling the revoke list with junk. And it may also make sense to decrease the lifetime of the old refresh token (e.g. if it was originally going to expire in 24h make it expire in 30 minutes) or set maximum of times this swap can happen.

Of course this would still cause issues if e.g. database server where these were stored failed and client had to restore from backups.

Re: Token revocation

#32

Post by sverhagen »

ravenstine wrote: post #4
sverhagen wrote: post #2

I'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…

You can make a lot of decentralized requests with an access token, before needing one centralized request with a refresh token.

Re: Token revocation

#33

Post by quesera »

creamyhorror wrote: post #30
quesera wrote: post #22

Earlier quoted context omitted.

Defeats the purpose of a token. You've just reinvented the session cookie.

What do we call a token that's stored in a cookie, sent via the HTTP 'Authorization' header to the API with each request, and Redis-cached on the server for say 5 minutes after looking it up in the users/token service? I still call it a token, just not a JWT. Maybe I should change my terminology?

I think that's reasonable terminology. "Token" is an overloaded term.

I'd be careful about "stored in a cookie" (really "sent in a cookie") because that would not be how an auth token would be sent or received. Not in a literal cookie, but another HTTP header.

I think it's fair to say that all cookies are tokens. The distinction between a typical cookie and a token in this context (i.e. a token that is difficult to revoke) is:

If a token needs to be looked up to know its authorization scope, it is easy to revoke (just update it or clear it in the lookup database). This is equivalent to a session cookie.

The challenge is when the token contains the auth scope. This might be used when the two systems do not share a lookup mechanism. These can be difficult to revoke before their built-in expiration time. This (token revocation) is the "hard part" about JWTs.

Re: Token revocation

#34

Post by SgtBastard »

charcircuit wrote: post #28
CGamesPlay wrote: post #23

Earlier quoted context omitted.

Snarky peer comment, but if you can do this, then yeah, it sidesteps all of the complexity of a distributed authorization system. The trade off is the single point of failure: when your token verifier goes down, so does the entire system.

A blacklist checker is also a single point of failure.

An unavailable whitelist checker fails deadly for all items.

An unavailable blacklist checker fails deadly for only blacklisted items.

Only if your system design must fail safe in all scenarios (and most do, to be fair), only then does it become a single point of failure.

Re: Token revocation

#35

Post by SgtBastard »

grandpoobah wrote: post #13

Don't reference tokens solve this problem?

At the cost of having to lookup the validity of the reference token AND its claims on every request.

People use bearer tokens (with bearer claims) to improve system performance and availability … at the cost of increased complexity as now bearer tokens need both expiration and revocation mechanisms.

Re: Token revocation

#36

Post by grandpoobah »

SgtBastard wrote: post #35
grandpoobah wrote: post #13

Don't reference tokens solve this problem?

At the cost of having to lookup the validity of the reference token AND its claims on every request. People use bearer tokens (with bearer claims) to improve system performance and availability … at the cost of increased complexity as now bearer tokens need both expiration and revocation mechanisms.

Yes but you can cache the lookup for as short a period as is desired :P
Post reply on HN