machine-to-machine client registration when using a custom ClientAssertionService

[cdschneider]

Should the ClientSecret property always be required when setting up a machine-to-machine client for use with the client_credentials grant type?

I am trying to leverage the jwt-bearer client assertion type by implementing my own ClientAssertionService, however there are a few places where it seems like it is expected that a ClientSecret is always present. Right now my requests (which use the AccessTokenRequestHandler) fail at these points that expect ClientSecret property to be configured:

https://github.com/DuendeSoftware/foss/blob/main/access-token-management/src/AccessTokenManagement/Internal/ClientCredentialsTokenClient.cs#L43-L46

https://github.com/DuendeSoftware/foss/blob/main/access-token-management/src/AccessTokenManagement/ClientCredentialsClient.cs#L98-L101

To my understanding, using the jwt-bearer client assertion type is a way to avoid using a static client_secret to request access tokens. I'm looking to see if this might be a bug in the library or I'm missing something with how to properly configure my setup for client_credentials + jwt-bearer client-assertion-type for requesting access tokens.

Note: this is encountered while using Duende.AccessTokenManagement/4.0.0-preview.2, after downgrading to latest stable (3.2.0) I no longer see this issue.

[wcabus]

No, the ClientSecret should indeed be optional, because this prevents you from using client assertions.

We're looking into this issue, thanks for raising it!

[Erwinvandervalk]

@cdschneider Thanks for bringing this to our attention.

This PR addresses this issue:DuendeSoftware/foss#221

We will do our best to release a new version of ATM as soon as possible.

[cdschneider]

Thank you! I'll keep an eye out for a release after this gets merged 👍

[Erwinvandervalk]

FYI, An updated preview package (preview 3) is released, with a Release Candidate coming soon.