Hi,
The Bearer Token Usage RFC allows
<https://datatracker.ietf.org/doc/html/rfc6750#section-2.2> for an access
token to be passed as a body form-encoded parameter. With DPoP, this leads
to ambiguity if a protected resource supports DPoP and Bearer schemes
simultaneously, as per DPoP Section 7.2.
The ambiguity arises from the inability to derive the authentication scheme
used with the token, as opposed to "Authorization: XXX" header use. In its
turn, the scheme would be needed for the protected resource to form the
correct "WWW-Authenticate" challenge in the case of invalid token. (For a
protected resource supporting Bearer and DPoP in parallel, the challenge
would include both schemes.)
Example challenge for the Bearer scheme:
401 Unauthorized
WWW-Authenticate: Bearer realm="foo", error="invalid_token", DPoP
realm="foo", algs="ES256"
Example challenge for the DPoP scheme:
401 Unauthorized
WWW-Authenticate: Bearer realm="foo", DPoP realm="foo",
error="invalid_token", algs="ES256"
(In a nutshell, we need to know which scheme in the challenge should be
marked as failed, and thus include the "error=..." attribute.)
Additionally, the knowledge of the scheme would be needed to properly
prevent the downgraded usage of DPoP-bound tokens, as per DPoP Section 7.2.
This might seem an insignificant edge case, but there is an important
instance of such a protected resource, namely OIDC UserInfo endpoint. As
per OpenID Connect Core, 5.3 UserInfo Endpoint
<https://openid.net/specs/openid-connect-core-1_0.html#UserInfo>:
The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns
> Claims about the authenticated End-User.
> The UserInfo Endpoint MUST support the use of the HTTP GET and HTTP POST
> methods defined in RFC 2616 [RFC2616].
> The UserInfo Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token
> Usage [RFC6750].
>
The problem is that UserInfo is not bound to any client, and DPoP support
would be normally enabled/disabled on a per client basis (rather than
per-realm or per-server). Therefore, UserInfo won't be able to make a
decision upon the default authentication scheme until it parses the token
and resolves a client that it was issued for; it might not be able to do
this at all in the case of invalid token. Hence, UserInfo must support (and
advertise via WWW-Authenticate) both Bearer and DPoP schemes
simultaneously, and to deduce which one has been used with the POST request
containing access_token as a form-encoded param.
I see the following possible approaches:
- require that hybrid Bearer/DPoP protected resources honor a variant of
the POST parameter, like e.g. "access_token+dpop=...", or
- restrict the use of access_token POST param and require that
"Authorization: XXX" header be always used with DPoP.
What do you think?
Dmitry
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
