OAuth: require Authorization Code Binding to a DPoP Key

[randomstuff]

The FAPI 2.0 profile have this requirement:

Authorization Servers[...] if using DPoP, shall support "Authorization Code Binding to DPoP Key" (as required by Section 10.1 of [RFC9449]);

with this note:

NOTE 2: Although authorization servers are required to support "Authorization Code Binding to DPoP Key" (as defined by Section 10.1 of [RFC9449]), clients are not required to use it.

Shall we include a corresponding requirement: "Verify that authorization server supports Authorization Code Binding to DPoP Key."? We could even go as far as require it it used by clients?

[elarlang]

If we only require that the AS need to support it, but not require the client to use it, it does not provide any security. So the question is - should it be required for the client?

[randomstuff]

If we only require that the AS need to support it, but not require the client to use it, it does not provide any security.

I would not say it provides no security at all. It makes sure that any client which actually supports it will benefit from it.

Then I agree, it makes sense to require it from the client as well. I don't see any reason why the client would not want to use it if it implements DPoP.

[elarlang]

We had the same discussion with PKCE requirement (Verify that the AS supports PKCE). If we have a requirement, that the client need to use PKCE, it means, the AS also need to support PKCE. Only requiring some support is functionality testing area for me and I prefer requirement for the client.

[elarlang]

NOTE 2: Although authorization servers are required to support "Authorization Code Binding to DPoP Key" (as defined by Section 10.1 of [RFC9449]), clients are not required to use it.

So, our options:

• option 1 - for just to be aligned with FAPI 2.0 - ask support from AS, without requiring it from the client
• option 2 - we don't add any requirement for this. As stated already, in my opinion "the option 1" does not solve any problem to require it
• option 2 - to be in conflict (more strict) with FAPI 2.0 and require it from clients

I prefer "option 2".

[randomstuff]

FWIW, here is the motivation for authorization code binding to a DPoP key:

If an authorization server does not (or cannot) strictly enforce the single-use limitation for authorization codes and an attacker can access the authorization code (and if PKCE is used, the code_verifier), the attacker can create a forged token request, binding the resulting token to an attacker-controlled key. For example, using XSS, attackers might obtain access to the authorization code and PKCE parameters. Use of the dpop_jkt parameter prevents this attack.

I'm finding this somewhat far-fetched.

[elarlang]

Are we talking about level 3 requirement here?

[elarlang]

I would say that the section before the quoted section is more convincing for me.

[randomstuff]

I would say that the section before the quoted section is more convincing for me.

Yes but the section that I quoted, describes the scenario under which this may be useful:

• the attacker has access to the authorization code;
• and the attacker has access to the code verifier;
• and the attacker has access to the client credentials (for confidential clients);
• and the attacker manages to use the authorization code before it is invalidated (single-use).

Are we talking about level 3 requirement here?

Yes, I would say L3 but on the other hand L3 requires the usage of confidential clients which makes the attack scenario quite unlikely.

Maybe option 2 is fine.

[elarlang]

Let's get the requirement text in as L3 requirement. We need to justify all levels anyway, but as by spec it is not required, I'm not very keen to use it for L2.

[elarlang]

I think we have agreement here to add another requirement, @randomstuff - can you come up with proposal?

[randomstuff]

Proposals below which separates in two different requirements. I'm not sure how to combined them in a single requirement (and whether this is desirable).

Requirement for OAuth client (L3):

Verify that the OAuth client supports authorization code binding to a DPoP key when it uses DPoP by including its DPoP public-key in the authorization code request.

Note: this can be achieved using the dpop_jkt parameter or, when using PAR, in a DPoP HTTP header.

Requirement for Authorization server (L3):

Verify that the OAuth authorization server supports authorization code binding to a DPoP key when it supports DPoP. When it receives a authorization code request including a DPoP client public key, it must bind the resulting authorization code to this public key and must reject the subsequent access token request if it does not include a DPoP proof for the same public key.

I'm am not very happy about this second requirement and would gladly see improvement proposition :)

---

For references, Authorization Code Binding to DPoP Key is about including a SHA-256 hash of the (DPoP) client public key inside the initial authorization request.

This is usually done using the dpop_jkt parameter:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz\
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb\
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM\
    &code_challenge_method=S256\
    &dpop_jkt=NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs HTTP/1.1

or using a DpoP push when using PAR.

[elarlang]

I'm back and forward with this one, the likelihood (as described in https://github.com/OWASP/ASVS/issues/2160#issuecomment-2425817543) seems here niche, and seems more like a level 5 requirement.

@randomstuff - if you are sure that ASVS needs those requirements, we can have them as level 3 requirements. A bit updated formating:

Verify that the OAuth client supports authorization code binding to a Demonstrating Proof of Possession (DPoP) key when it uses DPoP by including its DPoP public-key in the authorization code request.

Verify that the OAuth authorization server supports authorization code binding to a Demonstrating Proof of Possession (DPoP) key when it supports DPoP. When it receives an authorization code request including a DPoP client public key, it must bind the resulting authorization code to this public key and must reject the subsequent access token request if it does not include a DPoP proof for the same public key.

[randomstuff]

if you are sure that ASVS needs those requirements

I believe we can probably skip this one.

[elarlang]

ack, proposals are written and ready for PR if we rethink that. Closing for now.