Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7823)

[Aaron Parecki <[e-mail]>]

I'm not sure where the mismatch is happening then, because there is no
requirement that scopes are limited to certain clients at least from the
perspective of the specification. If the authorization server has a policy
that only "Client A" can request "scope_a", and then it allows "Client B"
to request that scope, that sounds like a problem with that authorization
server implementation. However this would be allowed according to RFC6749.

I did find this text you might be able to point to that makes this clearer:

https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.1

> Since the client authentication is used as the authorization grant,
> no additional authorization request is needed.

The key being that the client authentication (mTLS in your example) IS the
authorization grant, so should be used to make authorization decisions.

Aaron


On Mon, Feb 26, 2024 at 3:37 PM Alexander Stumpf <[e-mail]> wrote:

> Thanks for the quick reply and I understand your rationale.
>
> Maybe I rephrase the issue we are having right now:
>
> The authorization server should use the identity of the client (proven by
> authentication) to come to a conclusion whether or not the client is
> authorized to receive the access token. While this sounds trivial and
> obvious, it is not explicitely stated in the RFC (please correct me if I am
> wrong), and therefore $VENDOR exist that claims that they are in accordance
> with the RFC when they
>
> 1) receive the identity of the client through a valid and trusted client
> certificate ("authentication" via mTLS)
>
> 2) issue the access token to the client according to the demanded scope,
> ignoring the identity from 1)
>
> I thought proving them wrong by finding the respective section in the RFC
> would be easy, but I did not find any statement to support my view.
>
>
>
> Am 2024-02-27 00:19, schrieb Aaron Parecki:
>
> This errata should be rejected.
>
> The client credentials grant results in an access token issued to
> the client that presented credentials. There is no mechanism for "Client A"
> to request a token for "Client B" using the client credentials grant, since
> the credentials themselves are what determines which client the token is
> issued to. However, this access token is not "bound" to the client, since
> it is still a bearer token. (Other extensions like DPoP can add a binding
> of the access token to the client.)
>
> Aaron
>
>
> On Mon, Feb 26, 2024 at 3:14 PM RFC Errata System <
> [e-mail]> wrote:
>
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7823
>
> --------------------------------------
> Type: Editorial
> Reported by: Alexander Stumpf <[e-mail]>
>
> Section: 3.2.1
>
> Original Text
> -------------
>    Confidential clients or other clients issued client credentials MUST
>    authenticate with the authorization server as described in
>    Section 2.3 when making requests to the token endpoint.  Client
>    authentication is used for:
>
>    o  Enforcing the binding of refresh tokens and authorization codes to
>       the client they were issued to.  Client authentication is critical
>       when an authorization code is transmitted to the redirection
>       endpoint over an insecure channel or when the redirection URI has
>       not been registered in full.
>
> Corrected Text
> --------------
>    Confidential clients or other clients issued client credentials MUST
>    authenticate with the authorization server as described in
>    Section 2.3 when making requests to the token endpoint.  Client
>    authentication is used for:
>
>    o  Enforcing the binding of refresh tokens, authorization codes, and
>       (in the case of the Client Credentials Grant as described in
>       Section 4.4) the access token to the client they were issued to.
>       Client authentication is critical when an authorization code is
>       transmitted to the redirection endpoint over an insecure channel
>       or when the redirection URI has not been registered in full.
>
> Notes
> -----
> Section 4.4.2 requires for the "client_credentials" grant type that the
> client is authenticated to the authorization server according to section
> 3.2.1. The reason for this authentication is (or so I assume) that the
> to-be-issued access token shall be bound to the correct (authenticated)
> client. Otherwise, the client could authenticate with valid credentials as
> "client A" and request a token for "client B", and would still be in
> accordance with the RFC, which is probably not intended.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6749 (draft-ietf-oauth-v2-31)
> --------------------------------------
> Title               : The OAuth 2.0 Authorization Framework
> Publication Date    : October 2012
> Author(s)           : D. Hardt, Ed.
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>