Skip to content

feat: add client credentials as a MUST #245

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
jeswr wants to merge 1 commit into
base: main
Choose a base branch
from
Open

feat: add client credentials as a MUST #245

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
35 changes: 31 additions & 4 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,7 +113,11 @@ from a browser or an application.

Therefore, this specification assumes the use of the
[Authorization Code Flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps) with
PKCE, in accordance with OAuth and OIDC best practices. It is also assumed that there are no
PKCE, in accordance with OAuth and OIDC best practices, for interactive browser-based login.
For non-interactive use cases such as scripts, automated agents, and server-to-server communication,
this specification also requires support for the
[Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4).
It is also assumed that there are no
preexisting trust relationships with the OP. This means that client registration, whether dynamic,
or static, is entirely optional.

Expand Down Expand Up @@ -288,13 +292,31 @@ Solid-OIDC defines the following `scope` value for use with claim requests:
REQUIRED. This scope requests access to the End-User's `webid` Claim.
</dl>

# Client Credentials Grant # {#client-credentials}

OpenID Providers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4)
Copy link
Contributor

@laurensdeb laurensdeb Feb 16, 2026

Choose a reason for hiding this comment

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

Generally OpenID Connect does not define a client credentials grant mechanism for OPs. It would be more correct to refer to Authorization Servers rather than OpenID Providers.

to enable non-interactive authentication for scripts, automated agents, and server-to-server
communication.

When using the Client Credentials Grant, the Client authenticates with the OP using a
`client_id` and `client_secret` pair previously obtained through client registration
Copy link
Contributor

@laurensdeb laurensdeb Feb 16, 2026

Choose a reason for hiding this comment

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

I would avoid making any assumptions on which assertions a client provides to the AS for the client credentials grant. Quite a few Authorization Services rely on public keypairs to authenticate clients, cfr. RFC7523, for example this is the case in MS Entra

Copy link
Member

@elf-pavlik elf-pavlik Feb 16, 2026

Choose a reason for hiding this comment

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

For example this draft PR to CSS uses RFC7523

(either static or dynamic). The Client sends a token request to the OP's token endpoint
with `grant_type=client_credentials` and the `webid` scope.
Comment on lines +301 to +304
Copy link

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

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

There's a potential contradiction with the statement at lines 121-122 which says "client registration, whether dynamic, or static, is entirely optional." The Client Credentials Grant inherently requires client registration to obtain the client_id and client_secret pair. Consider either: (1) clarifying at lines 121-122 that client registration is optional for some flows but required for Client Credentials Grant, or (2) adding a note in the Client Credentials section that explicitly acknowledges this requirement represents an exception to the general optional nature of client registration mentioned in the Core Concepts section.

Suggested change
When using the Client Credentials Grant, the Client authenticates with the OP using a
`client_id` and `client_secret` pair previously obtained through client registration
(either static or dynamic). The Client sends a token request to the OP's token endpoint
with `grant_type=client_credentials` and the `webid` scope.
When using the Client Credentials Grant, the Client MUST be registered with the OP and
authenticate using a `client_id` and `client_secret` pair previously obtained through
client registration (either static or dynamic). This requirement is an exception to the
general statement in the Core Concepts section that client registration is optional. The
Client sends a token request to the OP's token endpoint with `grant_type=client_credentials`
and the `webid` scope.

Copilot uses AI. Check for mistakes.
Copy link
Member Author

@jeswr jeswr Feb 15, 2026

Choose a reason for hiding this comment

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

@acoburn @joachimvh can you confirm this is accurate with your implementations?


The OP MUST validate the `client_id` and `client_secret`, and if valid, MUST return
Copy link
Contributor

@laurensdeb laurensdeb Feb 16, 2026

Choose a reason for hiding this comment

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

See comment above, I would not normatively require the use of a client_secret.

a DPoP-bound Access Token. The Client MUST include a valid DPoP proof [[!DPOP]]
Copy link

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

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

There's an inconsistency between this statement and line 319 in the Token Instantiation section. This line states the OP must return "a DPoP-bound Access Token" for the Client Credentials Grant, but line 319 (which explicitly covers both Authorization Code Grant and Client Credentials Grant per line 316) states "the OP MUST return a DPoP-bound OIDC ID Token". These two statements need to be aligned. Based on the structure of the specification and line 319's scope covering both grant types, this should likely say "a DPoP-bound OIDC ID Token" instead of "Access Token".

Suggested change
a DPoP-bound Access Token. The Client MUST include a valid DPoP proof [[!DPOP]]
a DPoP-bound OIDC ID Token. The Client MUST include a valid DPoP proof [[!DPOP]]

Copilot uses AI. Check for mistakes.
Copy link
Member Author

@jeswr jeswr Feb 15, 2026

Choose a reason for hiding this comment

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

@acoburn could you please guide on language

Copy link
Contributor

@laurensdeb laurensdeb Feb 16, 2026

Choose a reason for hiding this comment

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

ID Tokens are only meaningful terms in the context of OIDC, in the context of the client credentials grant of OAuth2 one should use "Access Tokens" as the proper terminology.

Copy link
Member

@acoburn acoburn Feb 16, 2026

Choose a reason for hiding this comment

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

This also hints at some long-standing challenges with Solid-OIDC. In Solid-OIDC, an OpenID provider generates ID tokens for use with Solid Clients and Servers, but these ID tokens are used as Access Tokens. Arguably, this is incorrect.

Furthermore, DPoP is defined as a mechanism to protect Access Tokens. Using DPoP with ID Tokens is not defined. Insofar as Solid-OIDC is about defining ID Tokens, it is incorrect to use DPoP, and insofar as Solid-OIDC is a about defining Access Tokens, it is correct to use DPoP but incorrect to use OpenID Connect.

with the token request.

The OP MUST advertise `client_credentials` in its `grant_types_supported`
metadata property in its OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] document.
Copy link
Contributor

@laurensdeb laurensdeb Feb 16, 2026

Choose a reason for hiding this comment

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

Note that the grant_types_supported metadata field of OpenID connect is optional. I don't think it makes sense to introduce a MUST therefore, in particular given that this is an OAuth grant type.


# Token Instantiation # {#tokens}

Assuming one of the following options
- Client ID and Secret, and valid DPoP Proof (for dynamic and static registration)
- Client ID and Secret, and valid DPoP Proof, using either the Authorization Code Grant or the Client Credentials Grant
- Dereferencable Client Identifier with a proper Client ID Document and valid DPoP Proof (for a Solid client identifier)

the OP MUST return A DPoP-bound OIDC ID Token.
the OP MUST return a DPoP-bound OIDC ID Token.

## DPoP-bound OIDC ID Token ## {#tokens-id}

Expand Down Expand Up @@ -401,10 +423,15 @@ requested resource.
An OpenID Provider that conforms to the Solid-OIDC specification MUST advertise it in the OpenID Connect
Discovery 1.0 [[!OIDC-DISCOVERY]] resource by including `webid` in its `scopes_supported` metadata property.

Additionally, the OP MUST include `client_credentials` in its `grant_types_supported`
metadata property to indicate support for non-interactive authentication
via the Client Credentials Grant (see [[#client-credentials]]).
Comment on lines +426 to +428
Copy link

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

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

This requirement duplicates the one already stated in the Client Credentials Grant section (lines 310-311). The same requirement appears twice: once in the Client Credentials Grant section and once here in the Conformance Discovery section. Consider removing the duplication by keeping only one of these statements, or if both are intentional, clarify why the requirement is repeated. Typically, the discovery/conformance section would be the natural place for such metadata requirements, making lines 310-311 potentially redundant.

Suggested change
Additionally, the OP MUST include `client_credentials` in its `grant_types_supported`
metadata property to indicate support for non-interactive authentication
via the Client Credentials Grant (see [[#client-credentials]]).
Additionally, an OP that supports non-interactive authentication
via the Client Credentials Grant (see [[#client-credentials]]) indicates this support by including
`client_credentials` in its `grant_types_supported` metadata property.

Copilot uses AI. Check for mistakes.
Copy link
Member Author

@jeswr jeswr Feb 15, 2026

Choose a reason for hiding this comment

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

Only to implement this change if we go with MAY wording over MUST.


<div class="example">
<pre highlight="json">
{
"scopes_supported": ["openid", "offline_access", "webid"]
"scopes_supported": ["openid", "offline_access", "webid"],
"grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"]
}
</pre>
</div>
Expand Down