V51 - OAuth - sender-contrained refresh tokens

[elarlang]

Spin-off from https://github.com/OWASP/ASVS/issues/2040#issuecomment-2338933353

Verify that refresh tokens for public clients are either sender-constrained, using DPoP or Certificate-Bound Access Tokens (mTLS), or use refresh token rotation to mitigate refresh token replay attacks. (L1, L2, L3)

The proposal updates the requirement we already have as 51.2.4

Verify that refresh tokens are sender-constrained or use refresh token rotation to prevent token replay attacks. Refresh token rotation prevents usage in the event of a compromised refresh token. Sender-constrained refresh tokens cryptographically binds the refresh token to a particular Client.

---

Verify that refresh tokens for public clients ... (L1, L2, L3)

For how many levels we allow "public clients"?

And we have a separate discussion/requirement for confidential clients in #2109

Verify that confidential clients must use client authentication in refresh token requests. (L1, L2, L3)

[randomstuff]

Verify that refresh tokens for public clients are either sender-constrained, using DPoP or Certificate-Bound Access Tokens (mTLS), or use refresh token rotation to mitigate refresh token replay attacks. (L1, L2, L3)

I'm wondering whether it would make sense to require the usage of sender-constrained refresh tokens (as opposed to refresh token rotation) in L3.

For how many levels we allow "public clients"?

Maybe, this does not really matter in this verification but would be the object of another verification (?). Even if public clients are disallowed in L3, you would still want to have (because some L3 applications won't be 100% conformant from day one):

Verify that refresh tokens for public clients are either sender-constrained, using DPoP or Certificate-Bound Access Tokens (mTLS), or use refresh token rotation to mitigate refresh token replay attacks. (L1, L2, L3)

[elarlang]

We must be aligned with proposal from #2038

Verify that all clients are confidential and configured to use strong client authentication methods, i. e. 'mTLS' or 'private-key-jwt'.

[jmanico]

Verify that refresh tokens for public clients are either sender-constrained, using DPoP or Certificate-Bound Access Tokens (mTLS), or use refresh token rotation to mitigate refresh token replay attacks. (L1, L2, L3)

The refresh-refresh pattern by itself is more of intrusion detection as opposed to attack mitigation. The other defenses force me to have full access to the client. Refresh refresh does not. If I can steal an active refresh token there is no other sender constraint that prevents me from using it. Only stealing am expired refresh token asserts the defense.

I suggest recommending (DPoP AND refresh-refresh) or (mTLS AND refresh-refresh) as opposed to recommending refresh-refresh as an alternative to the other defenses.

[TobiasAhnoff]

I'm wondering whether it would make sense to require the usage of sender-constrained refresh tokens (as opposed to refresh token rotation) in L3.

From OAuth 2.1 and FAPI 2, as far as I understand, refresh-token misuse is primary mitigated by client authentication for confidential clients. So, L3 is covered by requiring confidential clients (with strong authentication methods) and client authentication for all token requests (#2009)

For public clients (which I think needs to be allowed for L1 and L2) OAuth 2.1 states: Either DPoP/mTLS or Refresh-token rotation. Which was the intent to capture with

Verify that refresh tokens for public clients are either sender-constrained, using DPoP or Certificate-Bound Access Tokens (mTLS), or use refresh token rotation to mitigate refresh token replay attacks. (L1, L2, L3)

But e g FAPI 2 notes that refresh-token rotation is a weaker mitigation (and sometimes problematic), so, as I think @jmanico suggests, ASVS should reflect this and more clearly recommend DPoP or mTLS over just rotation, correct? Perhaps like this

Verify that refresh tokens for public clients are sender-constrained using DPoP or Certificate-Bound Access Tokens (mTLS) and, if appropriate, also use refresh token rotation to mitigate refresh token replay attacks. (L1, L2, L3)

[elarlang]

Verify that refresh tokens for public clients are sender-constrained using Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS) and, if appropriate, also use refresh token rotation to mitigate refresh token replay attacks.

@randomstuff - any further feedback or need for changes?

[randomstuff]

I think that requiring sender-constrained tokens even for L1 is a little drastic. Using sender-constrained access tokens all the time is a good idea but I'm not sure this matches much with the current state of software/frameworks, etc. This might therefore be a little too much for L1?

[elarlang]

I agree with that. To this direction?

Verify that the authorization server mitigates refresh token replay attacks for public clients by using (L1, L2) refresh token rotation or (L3) sender-constrained refresh tokens using Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS).

[randomstuff]

Maybe:

Verify that the authorization server mitigates refresh token replay attacks for public clients by using (L1, L2) refresh token rotation or (L1, L2, L3) sender-constrained refresh tokens using Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS).

[randomstuff]

Verify that the authorization server mitigates refresh token replay attacks for public clients by using (L1, L2) refresh token rotation or (L1, L2, L3) sender-constrained refresh tokens using Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS).

Actually, I noticed that this conflicts with DPoP:

Refresh tokens issued to confidential clients (those having established authentication credentials with the authorization server) are not bound to the DPoP proof public key because they are already sender-constrained with a different existing mechanism.

The existing mechanism being client authentication.

[randomstuff]

Actually, I noticed that this conflicts with DPoP

Well actually no, it does not because of "public clients" :facepalm:

[elarlang]

So, all good or need for changes?

[elarlang]

Current 51.2.4:

#	Description	L1	L2	L3
51.2.4	[ADDED] Verify that the authorization server mitigates refresh token replay attacks for public clients by using (L1, L2) refresh token rotation or (L1, L2, L3) sender-constrained refresh tokens using Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens (mTLS).	✓	✓	✓

For refresh token rotation - we should require revoking previous refresh token, as decribed in: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-11#section-4.3.1-10.2.1