[crabmusket]

> sign a JWT per request

That's interesting - why do it this way rather than including a "reusable" signed JWT with the request, like an API token? Why sign the whole request? What does that give you?

Also what made that API so nice? Was this a significant part of it?

[motorest]

> That's interesting - why do it this way rather than including a "reusable" signed JWT with the request, like an API token? Why sign the whole request?

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.

https://en.wikipedia.org/wiki/Session_hijacking

[dwaite]

> Supposedly bearer tokens should be ephemeral, which means either short-lived (say single-digit minutes) or one-time use.

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)

[motorest]

> 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.

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.

[thdhhghgbhy]

>But session hijacking is a known problem.

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.

[motorest]

> You're effectively talking about an attacker breaking https aren't you?

No. There are many ways to fish bearer tokens. Encryption in transit only addresses some of them.

[thdhhghgbhy]

I'm all ears, please provide one potential way.

[maxwellg]

Each JWT was passed as a query param over a 307 redirect from my service to the other side, so the JWT itself was the whole request to prevent tampering from the browser. It was for an internal tool that did one thing, did it well, and never caused me any problems.