feat: add client credentials as a MUST by jeswr · Pull Request #245 · solid/solid-oidc · GitHub

This PR makes client credentials a MUST as part of the solid-oidc specification. The CSS and ESS both currently implement client credentials. There respective documentation can be found as follows:

Questions:

How long does this need to remain open after editor approval to be merged?
What is the versioning policy here / how should the version be changed.

cc @acoburn @joachimvh @elf-pavlik @thhck @uvdsl @dmitrizagidulin

Pull request overview

This PR adds mandatory support for the OAuth 2.0 Client Credentials Grant to the Solid-OIDC specification to enable non-interactive authentication for scripts, automated agents, and server-to-server communication. Both major implementations (Community Solid Server and Enterprise Solid Server) already support this feature.

Changes:

Added Client Credentials Grant as a MUST requirement for OpenID Providers
Updated Core Concepts section to clarify support for both interactive (Authorization Code + PKCE) and non-interactive (Client Credentials) authentication flows
Updated discovery requirements to mandate advertising client_credentials in grant_types_supported metadata
Updated Token Instantiation section to explicitly cover both Authorization Code Grant and Client Credentials Grant

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

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.

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

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.

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

@laurensdeb could you please also review it?
I recall you mentioning come certification issues before writing https://github.com/solid/solid-oidc/blob/main/alternative-flows.md

I think we should add a note about limitation around Client IDs that are URLs, I have PR to CSS that allows it

feat: URL client id for client credentials CommunitySolidServer/CommunitySolidServer#2041

Still only one user can use client with given Client ID URL. Since it is often used for scripts that aren't multi tenant it migth be fine. In case of multi tenant clients, I also made an early draft that uses another flow/grant

grant-type:jwt-bearer similar to client credentials but with proper support for URL client_id CommunitySolidServer/CommunitySolidServer#2053

@acoburn does ESS support client credentials with Client ID URL?

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

For example this draft PR to CSS uses RFC7523

grant-type:jwt-bearer similar to client credentials but with proper support for URL client_id CommunitySolidServer/CommunitySolidServer#2053

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

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.

I generally don't think it makes a lot of sense to introduce client_credentials grant as part of the Solid-OIDC specification. The general remarks I made previously on supporting additional grant types are still quite relevant here.

The main issue I see is that OIDC builds on top of the OAuth2 protocol, therefore it would make more sense to do a thorough refactoring here and extract aspects specific to OAuth in a Solid-OAuth specification, and have the Solid-OIDC specification extend that for the authorization_code grant.

The introduction of a Solid-OAuth specification would have the benefit of being able to e.g. drop the requirement of DPoP for client_credentials grant, as it makes very little sense for a confidential client (which would typically be the case for a client_credentials based flow).

The introduction of a Solid-OAuth specification would have the benefit of being able to e.g. drop the requirement of DPoP for client_credentials grant, as it makes very little sense for a confidential client (which would typically be the case for a client_credentials based flow).

@laurensdeb could you please clarify? Even with confidential clients, when aud is not restricted to a specific AS, DPoP is needed so the AS which receives the id token (authentication credential) can not reuse that token/credential elsewhere.

Rather than focus on particular line changes in this PR, there are some high level issues that would be good to clarify.

Use cases: this change seems to be motivated by a desire to support scripts and bots. As such, there are several different ways to address this, and client_credentials is just one approach. There is also the use of refresh tokens (already compatible with Solid-OIDC) and other mechanisms such as the jwt-bearer grant type from RFC 7523. Client Credentials (as typically implemented with a client_id/client_secret pair) has some notable security concerns (e.g. relying on a shared secret rather than on public key cryptography). Adding a hard requirement on this for Solid-OIDC may be misguided.
OAuth vs OpenID Connect: Solid-OIDC is clearly a mechanism to integrate Solid with OpenID Connect. As such, Solid-OIDC supports browser-based authentication flows (authorization_code flow), since that is the motivating use case for OpenID Connect. Adding a grant type from OAuth 2 is not the best fit for an OpenID Connect profile. Here, an authentication mechanism defined in a different specification (e.g., Solid-OAuth) may be a better approach
Identity binding: While the Inrupt ESS platform currently supports client credential flows via its OpenID Connect broker, one challenge is that any client_credential grant needs a pre-existing identity binding. Typically, a client_id value is an opaque UUID and scoped to a particular OP. The only way to ensure that this client_id value is bound to a WebID identity is to do so at registration time. Note that, functionally, this is nearly identical to using a refresh token. And specifically, this does not address the case of authenticating autonomous bots.
Alternatives: I would highly recommend considering alternatives, such as the use of Client Id Metadata documents, which largely derives from Solid-OIDC and adds features that are needed for autonomous bots, such as authentication.

The introduction of a Solid-OAuth specification would have the benefit of being able to e.g. drop the requirement of DPoP for client_credentials grant, as it makes very little sense for a confidential client (which would typically be the case for a client_credentials based flow).

@laurensdeb could you please clarify? Even with confidential clients, when aud is not restricted to a specific AS, DPoP is needed so the AS which receives the id token (authentication credential) can not reuse that token/credential elsewhere.

If there were some Solid-OAuth specification, I would highly recommend requiring an audience constraint via the aud claim. With that requirement in place, DPoP becomes largely unnecessary as a requirement. (Certain deployment scenarios may still wish to require DPoP for other reasons, but the motivating use case for DPoP was the concern about having a malicious Solid server replay a token at some other Solid server, and this would be addressed with audience constraints).

In this sketch https://elf-pavlik.github.io/lws-auth/view/oidc/?dynamic=sequence
I don't use DPoP, instead there is a token exchange with both User AS and Resource AS to keep audiences set to specific parties.

@elf-pavlik As Aaron mentioned, in a more general Solid-OAuth scenario an audience constrained access token would make more sense than a sender constrained access token using DPoP. I agree that there still is a risk of a malicious RS or AS intercepting a token, so a mechanism still needs to be in place to constrain the token to a target.

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Rather than focus on particular line changes in this PR, there are some high level issues that would be good to clarify.

Use cases: this change seems to be motivated by a desire to support scripts and bots. As such, there are several different ways to address this, and client_credentials is just one approach. There is also the use of refresh tokens (already compatible with Solid-OIDC) and other mechanisms such as the jwt-bearer grant type from RFC 7523. Client Credentials (as typically implemented with a client_id/client_secret pair) has some notable security concerns (e.g. relying on a shared secret rather than on public key cryptography). Adding a hard requirement on this for Solid-OIDC may be misguided.

Yes, the goal is to enable support for scripts and bots.

More directly, it reflects how scripts and bots can currently authenticate into two of the predominant implementations of Solid (ESS and CSS). I would like to leave discussions of what could be done to the Linked Web Storage group -- where we are considering such alternative methods for script/bot authentication.

OAuth vs OpenID Connect: Solid-OIDC is clearly a mechanism to integrate Solid with OpenID Connect. As such, Solid-OIDC supports browser-based authentication flows (authorization_code flow), since that is the motivating use case for OpenID Connect. Adding a grant type from OAuth 2 is not the best fit for an OpenID Connect profile. Here, an authentication mechanism defined in a different specification (e.g., Solid-OAuth) may be a better approach

Yes - happy to split this out.

Identity binding: While the Inrupt ESS platform currently supports client credential flows via its OpenID Connect broker, one challenge is that any client_credential grant needs a pre-existing identity binding. Typically, a client_id value is an opaque UUID and scoped to a particular OP. The only way to ensure that this client_id value is bound to a WebID identity is to do so at registration time. Note that, functionally, this is nearly identical to using a refresh token. And specifically, this does not address the case of authenticating autonomous bots.

👍

Alternatives: I would highly recommend considering alternatives, such as the use of Client Id Metadata documents, which largely derives from Solid-OIDC and adds features that are needed for autonomous bots, such as authentication.

As responded to in (1) I would like to leave discussions of what could be done to the Linked Web Storage group -- where we are considering such alternative methods for script/bot authentication.

Use cases: this change seems to be motivated by a desire to support scripts and bots. As such, there are several different ways to address this, and client_credentials is just one approach. There is also the use of refresh tokens (already compatible with Solid-OIDC) and other mechanisms such as the jwt-bearer grant type from RFC 7523. Client Credentials (as typically implemented with a client_id/client_secret pair) has some notable security concerns (e.g. relying on a shared secret rather than on public key cryptography). Adding a hard requirement on this for Solid-OIDC may be misguided.

Yes, the goal is to enable support for scripts and bots.

It is important to note that scripts and bots can currently use Solid-OIDC without any changes via the refresh token flow.

The typical patterns here all involve some browser-based interaction and result in the script being given access to the resulting refresh token.

If the goal is to document how Inrupt's ESS implements client credentials, I would highly recommend not conflating OAuth-based flows with OpenID connect-based flows at the protocol level. Instead, a separate, Solid-OAuth CG document would be quite suitable.

@acoburn does it still result in client obtaining ID Token and the Client - AS + RS interaction stays the same?

@elf-pavlik

does it still result in client obtaining ID Token and the Client - AS + RS interaction stays the same?

By "it", I assume that you mean the refresh token flow. In that case, yes.

A client begins by interacting with the authorization_endpoint, requesting the following scopes: openid webid offline_access. Everything else follows normal OpenID Connect flows, resulting in an ID token and a refresh token that can later be exchanged for another ID token. All the other interactions with AS/RS stay the same.

The important discovery mechanism for this is the scopes_supported field in the OpenID Connect metadata: by including offline_access in that array, an OpenID Provider signals that it supports the refresh token flow.

I'm sorry I meant ESS client credentials flow

For the client_credentials flow in ESS, a user is able to create credentials via a web UI. This binds these opaque values to a particular WebID. The values can be used to authenticate the client at the token_endpoint with grant_type=client_credentials. A successful response will include an ID token that can be used normally within Solid.

Thanks!

I would highly recommend not conflating OAuth-based flows with OpenID connect-based flows at the protocol level.

Since client_credentials grant type results in DPoP bound ID Token, can we really cleanly separate OAuth-based and OIDC-based? If @jeswr extract this PR into a seprarate spec, it looks like it would still need Solid-OIDC as a normative reference 🤔

# Conflicts: # index.bs

Is there a reference we can provide for the refresh token flow?

0458856

Co-authored-by: Jesse Wright <63333554+jeswr@users.noreply.github.com>

I have extracted the changes here to a new section that could become a separate specification.

@acoburn @elf-pavlik @uvdsl could you please check whether this reflects your discussion with @jeswr.

I am ok with adding a requirement for the client_credentials grant type, and it is important to note the this grant flow requires authentication. However, client_id/client_secret is only one type of authentication that could be used in this flow, and it is (arguably) not the most secure. I would be much happier if the requirements here are limited to:

The client_credential grant type MUST be included in the grant_types_supported array of the .well-known/openid-configuration resource

RFC6749 section 4.4.2 and section 3.2.1 already include requirements for authentication, so there is no need to normatively reiterate that here. It is fine to use client_id/client_secret pairs as non-normative examples, but I would not require that as the lone authentication mechanism. RFC7523 presents another way to handle authentication using JWTs, and other mechanisms will emerge over time.

69ea20f makes example non-normative and notes RFC7523.

As already described, this section should emphasize the requirement for authentication, but not the particular mechanism for authentication.

For example, this would be a more suitable line:

During Token Instantiation, if the Client Credentials Grant is used, the OP MUST validate the client's authentication credentials.

(Note, though, that this requirement is already present via RFC 6749 and restating it is, strictly speaking, not necessary)

50e297d makes the authentication requirement generic.

I think we still miss clarification on how the OP should set those two claims

webid
azp (client_id)

If dynamic client registration is used I don't see how server would know the WebID of the user to set the webid claim. Even if one would want to use client_id as both webid and azp, WebID has to be URL and I haven't seen dynreg using URLs for client ids. Is there a single implementation that we know of using client credentials with dynreg?

In case of manual registration, which is implementation specific, OP should (must?) bind client_id to the user who registered it and use that user's WebID in ID token.
We might also want to mention that with this approach only one user will be able to use that client. Which might be interesting if ClientID is a URI and some service would want to act as multi tenant client. I explored a different solution in

grant-type:jwt-bearer similar to client credentials but with proper support for URL client_id CommunitySolidServer/CommunitySolidServer#2053

Would it make sense to specify that clients using client credentials MUST be single tenant?

…RFC7523 reference

I think we still miss clarification on how the OP should set those two claims

webid

azp (client_id)

If dynamic client registration is used I don't see how server would know the WebID of the user to set the webid claim. Even if one would want to use client_id as both webid and azp, WebID has to be URL and I haven't seen dynreg using URLs for client ids. Is there a single implementation that we know of using client credentials with dynreg?

In case of manual registration, which is implementation specific, OP should (must?) bind client_id to the user who registered it and use that user's WebID in ID token. We might also want to mention that with this approach only one user will be able to use that client. Which might be interesting if ClientID is a URI and some service would want to act as multi tenant client. I explored a different solution in

grant-type:jwt-bearer similar to client credentials but with proper support for URL client_id CommunitySolidServer/CommunitySolidServer#2053

Would it make sense to specify that clients using client credentials MUST be single tenant?

176406f clarifies the requirement to bind webid to client_id.

@acoburn @elf-pavlik @uvdsl could you please check whether most recent changes address your comments.

Co-authored-by: elf Pavlik <elf-pavlik@hackers4peace.net>

Thanks, @langsamu this looks good to me

Let's give @uvdsl a chance to review this PR, we could merge it during CG meeting on Wednesday.

I suggested a minor addition in the example to clarify that the client credentials pair is bound to a user.

I note that we are doubling the section on token instantiation, which we as editors should clean up one way or another at some point - but this is an editorial problem, not a problem of this PR in particular.

Co-authored-by: Christoph Braun <christoph.braun@protonmail.com>

feat: add client credentials as a MUST

2d67a84

Copilot AI review requested due to automatic review settings February 15, 2026 20:11

Copilot started reviewing on behalf of jeswr February 15, 2026 20:11 View session

Copilot AI reviewed Feb 15, 2026

View reviewed changes

jeswr mentioned this pull request Feb 15, 2026

feat: add guide for authenticating with a script solid/dev#14

Merged

laurensdeb reviewed Feb 16, 2026

View reviewed changes

Comment thread index.bs Outdated

laurensdeb reviewed Feb 16, 2026

View reviewed changes

laurensdeb suggested changes Feb 16, 2026

View reviewed changes

acoburn reviewed Feb 16, 2026

View reviewed changes

fix: Use Access token rather than OIDC ID token

f2fb705

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

jeswr commented Feb 17, 2026

View reviewed changes

Comment thread index.bs Outdated

fix: Refer to Authorization Server over OpenID Providers

6a5e05b

uvdsl mentioned this pull request Feb 18, 2026

Create 2026-02-18.md solid/specification#764

Merged

acoburn requested changes Feb 18, 2026

View reviewed changes

Copilot AI mentioned this pull request Feb 18, 2026

feat: add guide for authenticating with a script solid/dev#15

Merged

Merge branch 'main' into feat/client-credentials-grant

45ac134

# Conflicts: # index.bs

uvdsl mentioned this pull request Mar 4, 2026

add meeting minutes solid/specification#766

Merged

Merge branch 'refs/heads/main' into feat/client-credentials-grant

fd21bf6

langsamu force-pushed the feat/client-credentials-grant branch 2 times, most recently from 5c00498 to 56b3f11 Compare March 6, 2026 11:15

Extract changes to separate section

840ccef

langsamu force-pushed the feat/client-credentials-grant branch from 56b3f11 to 840ccef Compare March 6, 2026 11:18

jeswr commented Mar 6, 2026

View reviewed changes

langsamu and others added 2 commits March 6, 2026 14:31

Update index.bs

3b8d430

Co-authored-by: Jesse Wright <63333554+jeswr@users.noreply.github.com>

Add reference to refresh token flow

0458856

acoburn reviewed Mar 6, 2026

View reviewed changes

langsamu added 3 commits March 9, 2026 14:31

Make Client Credentials authentication example non-normative and add …

69ea20f

…RFC7523 reference

Generalize client authentication validation in Client Credentials grant

50e297d

Clarify WebID binding requirement for Client Credentials Grant

176406f

elf-pavlik reviewed Mar 9, 2026

View reviewed changes

Comment thread index.bs Outdated

elf-pavlik reviewed Mar 9, 2026

View reviewed changes

Comment thread index.bs

Update index.bs

9ea7a00

Co-authored-by: elf Pavlik <elf-pavlik@hackers4peace.net>

acoburn approved these changes Mar 9, 2026

View reviewed changes

elf-pavlik approved these changes Mar 9, 2026

View reviewed changes

elf-pavlik requested a review from laurensdeb March 9, 2026 23:34

uvdsl approved these changes Mar 10, 2026

View reviewed changes

Comment thread index.bs

Update index.bs

cb232b3

Co-authored-by: Christoph Braun <christoph.braun@protonmail.com>

elf-pavlik merged commit 149502d into main Mar 11, 2026
1 check passed

elf-pavlik deleted the feat/client-credentials-grant branch March 11, 2026 14:40

This was referenced Apr 21, 2026

Capture Solid-OIDC with Global Access Token #252

Closed

Relax client credentials grant requirement to SHOULD #253

Merged

+              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.

+              Authorization Servers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4) to enable
+              non-interactive authentication for scripts, automated agents, and server-to-server communication.
+              NOTE: Scripts and bots can also use Solid-OIDC without Client Credentials via the refresh token flow, when supported by

		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

+              During Token Instantiation [[#tokens]], if the [Client Credentials
+              Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) is used, the OP MUST validate the `client_id` and
+              `client_secret`. If valid, the OP MUST return a DPoP-bound OIDC ID Token.

feat: add client credentials as a MUST by jeswr · Pull Request #245 · solid/solid-oidc · GitHub

Uh oh!

feat: add client credentials as a MUST - #245

feat: add client credentials as a MUST#245elf-pavlik merged 13 commits intomainsolid/solid-oidc:mainfrom feat/client-credentials-grantsolid/solid-oidc:feat/client-credentials-grantCopy head branch name to clipboard

Conversation

jeswr commented Feb 15, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elf-pavlik commented Feb 15, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laurensdeb left a comment

Choose a reason for hiding this comment

Uh oh!

elf-pavlik commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

acoburn left a comment

Choose a reason for hiding this comment

Uh oh!

acoburn commented Feb 16, 2026

Uh oh!

elf-pavlik commented Feb 16, 2026

Uh oh!

laurensdeb commented Feb 16, 2026

Uh oh!

Uh oh!

jeswr commented Feb 17, 2026

Uh oh!

acoburn commented Feb 17, 2026

Uh oh!

acoburn left a comment

Choose a reason for hiding this comment

Uh oh!

elf-pavlik commented Feb 18, 2026

Uh oh!

acoburn commented Feb 18, 2026

Uh oh!

elf-pavlik commented Feb 18, 2026

Uh oh!

acoburn commented Feb 18, 2026

Uh oh!

elf-pavlik commented Feb 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

langsamu commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

feat: add client credentials as a MUST#245
elf-pavlik merged 13 commits into
mainfrom
feat/client-credentials-grant

elf-pavlik commented Feb 16, 2026 •
edited
Loading

langsamu commented Mar 6, 2026 •
edited
Loading

langsamu commented Mar 9, 2026 •
edited
Loading