V51 - OAuth - sender-contrained refresh tokens

[elarlang]

Spin-off from #2040 (comment)

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.