In the event this client authentication method is used with DPoP bound access tokens. An AS may want the assurance that the key they bind an issued access token, is in fact authenticated to the client. Without this assurance a MITM attack is possible where an intermediary could substitute the DPoP proof in the token request for a key they control, thus then being able to use the returned access token.
Below is a simple diagram depicting this attack
sequenceDiagram
participant C as Client
participant A as Attacker
participant AS as Authorisation Server
participant RS as Resource Server
C->>C: Prepare Token Request (including DPoP proof)
C->>A: Send token request (intercepted by attacker)
A->>A: Generate new DPoP key and DPoP proof
A->>A: Generate new token request using the clients original request but with the new DPoP proof substituted
A->>AS: Send token request
AS->>AS: Validate and generate access token bound to attackers DPoP key
AS->>A: Send token response (with access token bound to attackers DPoP key)
A->>RS: Protected resource request using obtained access token
Related to this issue, is PR #67, which explores using the DPoP proof syntax instead of defining a new JWT PoP syntax as is the case with the current draft. Consequently if #67 were adopted, the usage of this client authentication method with DPoP bound access tokens becomes much simpler and the above attack scenario would be prevented implicitly through the design. However, there is concern that #67 risks coupling together the DPoP key and client attestation key where there maybe usecases where these keys should be seperate (cc @tlodderstedt). Personally I'm not convinced that the DPoP key and client attestation key need to be different and I believe the complexity it creates is not worth it. However, if #67 is not adopted, then a different solution to solving the above problem needs to be devised which may require putting the DPoP key in the client attestation PoP so it can be authenticated back to the client.
In the event this client authentication method is used with DPoP bound access tokens. An AS may want the assurance that the key they bind an issued access token, is in fact authenticated to the client. Without this assurance a MITM attack is possible where an intermediary could substitute the DPoP proof in the token request for a key they control, thus then being able to use the returned access token.
Below is a simple diagram depicting this attack
DPoP as stated in the RFC is not designed as a client authentication method, but is instead designed to work with client authentication. The client authentication method as defined by this draft could be such a suitable method that would provide a way to prevent the above attack from occurring.
Related to this issue, is PR #67, which explores using the DPoP proof syntax instead of defining a new JWT PoP syntax as is the case with the current draft. Consequently if #67 were adopted, the usage of this client authentication method with DPoP bound access tokens becomes much simpler and the above attack scenario would be prevented implicitly through the design. However, there is concern that #67 risks coupling together the DPoP key and client attestation key where there maybe usecases where these keys should be seperate (cc @tlodderstedt). Personally I'm not convinced that the DPoP key and client attestation key need to be different and I believe the complexity it creates is not worth it. However, if #67 is not adopted, then a different solution to solving the above problem needs to be devised which may require putting the DPoP key in the client attestation PoP so it can be authenticated back to the client.