abid mohammed
abid mohammed

Reputation: 1

Which http return code should be returned when making request to resource server using DPOP bound access token but without DPOP proof

When a request is made to resource server to access protected resource using DPOP bound access token but without DPOP JWT proof, my understanding based on DPOP RFC 9449 is that 401 Unauthorized status should be returned.

https://datatracker.ietf.org/doc/html/rfc9449#name-decoded-content-of-the-dpop

Based on guidelines for error codes based on RFC 6750, 401 Unauthorized should be returned when an access token is expired, revoked, malformed, or invalid for other reasons. https://www.rfc-editor.org/rfc/rfc6750#section-3.1

Since given access token is valid i.e.. its not expired/revoked/malformed/invalid, i feel that returning 401 Unauthorized status code for such scenario indicates that access token is invalid while there is no problem with given access token by itself.

Since authorization server expects additional DPOP header to be set with valid JWT, but is missing, a client should be forbidden from using DPOP bound access token without DPOP JWT and hence 403 Forbidden error feels more meaningful representation of current situation.

Please correct if my understanding is incorrect or if there are better ways to send meaningful error message and status code for such scenario.

Request:
GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU

Response:

Status code : "403 Forbidden",

Payload:
{
    "error": "invalid_authorization_details",
    "error_description": "DPoP JWT must be set in request header."
}

Scenario and sample error message added to description.

Upvotes: 0

Views: 883

Answers (1)

Hans Z.
Hans Z.

Reputation: 53918

The access token lacks the required DPoP proof so the sender cannot be authenticated, which is ultimately what DPoP is designed for. This really means that it is invalid for its usage - even though it may contain the claims that would be sufficient for access, thus avoiding a 403 - therefore a 401 makes most sense, as the DPoP spec dictates. On top of that, note that the cnf claim is required to be present in the access token when DPoP is used, which would probably be lacking the case that you describe, so more reason to consider it invalid.

See also https://datatracker.ietf.org/doc/html/rfc9449#section-7.1 which says:

Upon receipt of a request to a protected resource within the protection space requiring DPoP authentication, the server can respond with a challenge to the client to provide DPoP authentication information if the request does not include valid credentials or does not contain an access token sufficient for access. Such a challenge is made using the 401 (Unauthorized) response status code ([RFC9110], Section 15.5.2) and the WWW-Authenticate header field ([RFC9110], Section 11.6.1). The server MAY include the WWW-Authenticate header in response to other conditions as well.

...

  • An error parameter ([RFC6750], Section 3) SHOULD be included to indicate the reason why the request was declined, if the request included an access token but failed authentication. The error parameter values described in [RFC6750], Section 3.1 are suitable, as are any appropriate values defined by extension. The value use_dpop_nonce can be used as described in Section 9 to signal that a nonce is needed in the DPoP proof of a subsequent request(s). Additionally, invalid_dpop_proof is used to indicate that the DPoP proof itself was deemed invalid based on the criteria of Section 4.3.

  • An error_description parameter ([RFC6750], Section 3) MAY be included along with the error parameter to provide developers a human-readable explanation that is not meant to be displayed to end-users.

and Figure 15: HTTP 401 Response to a Protected Resource Request without Authentication https://datatracker.ietf.org/doc/html/rfc9449#figure-16 :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP algs="ES256 PS256"

Upvotes: 1

Related Questions