Skip to content

Stronger recommendation for client authentication #68

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
aaronpk wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Stronger recommendation for client authentication #68

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
21719b8
Stronger recommendation for client authentication
aaronpk Mar 6, 2026
443dc07
Apply suggestion from @aaronpk
aaronpk Mar 6, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions draft-ietf-oauth-client-id-metadata-document.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,7 @@ informative:
- name: V. Dzhuvinov
org: Connect2id
I-D.draft-ietf-oauth-attestation-based-client-auth:
I-D.draft-ietf-oauth-spiffe-client-auth:
RFC7523:
RFC9111:

Expand Down Expand Up @@ -262,9 +263,12 @@ Some restrictions on `redirect_uris` can make developer usage of Client ID Metad
## Client Authentication {#client_authentication}

Since the client establishes its own registration data at the authorization server,
prior coordination of client credentials is not possible. However, clients MAY establish
prior coordination of client credentials is not possible. However, establishing
credentials at the authorization server by using authentication methods that use
public/private key pairs, by publishing the public key in their metadata document.
public/private key pairs is possible by publishing the public key in their metadata document.

Clients that are capable of maintaining private key material and performing client authentication
SHOULD do so with an acceptable method.
Comment on lines +270 to +271
Copy link
Contributor

@ThisIsMissEm ThisIsMissEm Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this just explicitly say "e.g., private_key_jwt" ?

Copy link
Member Author

@aaronpk aaronpk Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to leave the door open for other methods in the future

Copy link
Contributor

@ThisIsMissEm ThisIsMissEm Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I can see that... maybe we could reference https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method ?


For example, the client MAY include the following properties in its metadata document
to establish a public key and advertise the `private_key_jwt` authentication method defined in {{OpenID}}:
Expand All @@ -279,7 +283,10 @@ to establish a public key and advertise the `private_key_jwt` authentication met
This establishes this client as a confidential client, and any communication with
the authorization server MUST include client authentication of the registered type.

The particular method of how the client manages the private key is out of scope of this specification, but may include manual provisioning or methods such as Attestation Based Client Authentication [I-D.draft-ietf-oauth-attestation-based-client-auth]. For example, the client developer could run a Client Attester Backend, using a native application's platform-specific APIs to authenticate to the backend service, where the private key corresponding to the `jwks_uri` key is managed by the backend service. This would allow a mobile app to request JWTs from the backend service that the mobile app could then use as client authentication to the authorization server.
When a client declares `token_endpoint_auth_method` as `private_key_jwt`, the authorization server
MUST require client authentication according to {{Section 2.2 of RFC7523}} using the corresponding key published in the client's metadata document.
Copy link
Contributor

@ThisIsMissEm ThisIsMissEm Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes it sound like we MUST use jwks in the CIMD, instead of jwks_uri (which I think we prefer?)

Copy link
Member Author

@aaronpk aaronpk Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah that was not my intent. maybe "published or referenced"?

Copy link
Contributor

@ThisIsMissEm ThisIsMissEm Mar 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd probably just say "referenced", since embedding is a reference in a way.. maybe "discovered from the client's metadata document" ?


The particular method of how the client manages the private key is out of scope of this specification, but may include manual provisioning or methods such as "Attestation Based Client Authentication" [I-D.draft-ietf-oauth-attestation-based-client-auth] or "OAuth SPIFFE Client Authentication" [I-D.draft-ietf-oauth-spiffe-client-auth]. For example, the client developer could run a Client Attester Backend, using a native application's platform-specific APIs to authenticate to the backend service, where the private key corresponding to the `jwks_uri` key is managed by the backend service. This would allow a mobile app to request JWTs from the backend service that the mobile app could then use as client authentication to the authorization server.


## Changes in Client Metadata
Expand Down