Identity Server breaking change from version 7.2.0 to 7.4.7

[pampua84]

Hello,

I upgraded Duende IdentityServer from version 7.2.0 to 7.4.7 and found what appears to be a breaking change.

Some clients are configured to use the Authorization Code Flow with PKCE enabled, so the RequirePkce property is set to true. However, they also have the Client Credentials grant type configured because they use different authentication flows for the frontend and backend components.

Before the upgrade, clients with this configuration worked correctly when using the Authorization Code Flow with PKCE. After the upgrade, they no longer work, and I see the following error in the logs:

{
"@t": "2026-08-04T08:44:56.3407207Z",
"@mt": "Invalid client configuration for client {clientId}: {errorMessage}",
"@l": "Error",
"clientId": "XXXXXXXX",
"errorMessage": "RequireClientSecret is false, but client is using client credentials grant type.",
"SourceContext": "Duende.IdentityServer.Stores.ValidatingClientStore",
"RequestId": "68991ef0-abe4-4a2b-a7ab-a91958bdf437",
"RequestPath": "/connect/authorize",
"ConnectionId": "0HNNHIE2IS2U2",
"MachineName": "test",
"level": "error"
}

I believe this is a breaking change, and the error message seems incorrect because the client is attempting to use the Authorization Code Flow with PKCE, not the Client Credentials grant type.

From my perspective, the presence of the Client Credentials grant type in the client configuration should not prevent the Authorization Code Flow with PKCE from working.

Could you please confirm whether this behavior is intentional?

Thanks

[wcabus]

This is indeed breaking change in behaviour, which was introduced in v7.3.0. In a previous thread, you may find a workaround to restore the old behaviour if needed, although we strongly advise to split up the public and confidential client into two separate client definitions for security reasons.

Previously, you could configure a client to be both public and confidential simultaneously:

• the public client uses the authorization code grant + PKCE without a client secret
• the confidential side uses the client credentials grant with a client secret

However, to make that work, you had to set RequireClientSecret to false. This meant that you could potentially try and use the publicly visible client ID to try and get an access token via the client credentials grant without specifying the secret, unless you have custom validation in place.