Supposedly bearer tokens should be ephemeral, which means either short-lived (say single-digit minutes) or one-time use.
This was supposed to be the way bearer tokens were supposed to be used.
> What does that give you?
Security.
The desirable properties for tokens is that they have some means of verifying their integrity, that they are being sent by the authorized party, and that they are being consumed by the authorized recipient.
A "reusable" bearer JWT with a particular audience satisfies all three - as long as the channel and the software are properly protected from inspection/exfiltration. Native clients are often considered properly protected (even when they open themselves up to supply chain attacks by throwing unaudited third party libraries in); browser clients are a little less trustworthy due to web extensions and poor adoption of technologies like CSP.
A proof of possession JWT (or auxiliary mechanisms like DPoP) will also satisfy all three properties - as long as your client won't let its private key be exfiltrated.
It is when you can't have all three properties that you start looking at other risk mitigations, such as making a credential one time use (e.g. first-use-wins) when you can't trust it won't be known to attackers once sent, or limiting validity times under the assumption that the process of getting a new token is more secure.
Generally an extremely short lifetime is part of one-time-use/first-use-wins, because that policy requires the target resource to be stateful. Persisting every token ever received would be costly and have a latency impact. Policy compliance is an issue as well - it is far easier to just allow those tokens to be used multiple times, and non-compliance will only be discovered through negative testing. Five minutes is a common value here, and some software will reject a lifetime of over an hour because of the cost of enforcing the single use policy.
I haven't seen recommendations for single-digit minute times for re-issuance of a multi-use bearer token though (such as for ongoing API access). Once you consider going below 10 minutes of validity there, you really want to reevaluate whatever your infrastructure requirements were that previously ruled out proof-of-possession (or whether your perceived level of risk-adversity is accurately represented in your budget)
Those are desirable properties.
But session hijacking is a known problem. You have to expect a scenario where an attacker fishes one of your tokens and uses it on your behalf to access your things.
To mitigate that attack vector, either you use single-user tokens or short-lived tokens.
Also, clients are already expected to go through authentication flows to request tokens with specific sets of claims and/or scopes to perform specific requests.
Single-use tokens were expected to be the happy flow of bearer token schemes such as JWTs. That's how you eliminate a series of attack vectors.
> Generally an extremely short lifetime is part of one-time-use/first-use-wins, because that policy requires the target resource to be stateful.
Not quite.
Single-use tokens are stateful because resource servers need to track a list of revoked tokens. But "stateful" only means that you have to periodically refresh a list of IDs.
Short-lived tokens are stateless. A JWT features "issued at" time, "not before" time, and "expiration" time. Each JWT already specifies the time window when resource servers should deem it valid.
> Persisting every token ever received would be costly and have a latency impact.
No need. As per the JWT's RFC, JWTs support the JWT ID property. You only need to store the JWT ID of a revoked token, not the whole token. Also, you only need to store it during the time window it's valid.
> Policy compliance is an issue as well - it is far easier to just allow those tokens to be used multiple times, and non-compliance will only be discovered through negative testing.
I think "easier" is the only argument, and it's mostly about laziness.
Authentication flows already support emitting both access tokens and refresh tokens, and generating new tokens is a matter of sending a request with a refresh token.
Ironically, the "easy" argument boils down arguing in favor of making it easy to pull session hijacking attacks. That's what developers do when they fish tokens from some source and send them around.
> I haven't seen recommendations for single-digit minute times for re-issuance of a multi-use bearer token though (such as for ongoing API access). Once you consider going below 10 minutes of validity there, you really want to reevaluate whatever your infrastructure requirements were that previously ruled out proof-of-possession (or whether your perceived level of risk-adversity is accurately represented in your budget)
This personal belief is not grounded in reality.
It's absurd to argue that clients having to do a request each 5 minutes is something that requires you to "reevaluate your infrastructure requirements". You're able to maintain infrastructure that handles all requests from clients, but you draw the line in sending a refresh request each minute or so?
It's also absurd to argue about proof-of-possession and other nonsense. The token validation process is the same: is the token signed? Can you confirm the signature is valid? Is the token expired/revoked? This is something your resource servers already do at each request. There is no extra requirements.
You're effectively talking about an attacker breaking https aren't you? Unless you can detail another way to get at a user's token. I'm curious to hear about it.
