Has Create Client management API behaviour changed re. grant types?

Help
1

We think we’ve seen a change in behaviour of the Create Client endpoint in the management API sometime over the last few days. We have a fix on our side but would like to check with you that our hypothesis about what’s happened are correct.

We’re creating Auth0 non-interactive clients which we expose to end-users as “API Clients” so they can access our public API. This was working fine, but sometime in the last few days new clients that were created didn’t have a client_credentials grant type. This resulted in the following error when users tried to do a client credentials exchange:
{
“error”: “unauthorized_client”,
“error_description”: “Grant type ‘client_credentials’ not allowed for the client.”
}

We’re using the Auth0 .net library to access the management API for creation of the clients. We were calling this with just the client name and type, like this:

var res = await auth0ApiClient.Clients.CreateAsync(new ClientCreateRequest
{
Name = apiClientName,
ApplicationType = ClientApplicationType.NonInteractive
});

From a combination of network tracing and code review, we discovered that the library is also setting this property: `token_endpoint_auth_method":“none”.

If we set that property to POST on the call above, using TokenEndpointAuthMethod = TokenEndpointAuthMethod.ClientSecretPost then we get the client_credentials grant type and the credentials exchange works fine.

We can’t see anything we’ve changed in this area, and have never had to set this property to create clients that can do successful credentials exchanges. Our hypothesis is that you’ve changed something to be stricter and not allow credentials exchanges if the create_credentials grant type is not present.

Please could you confirm whether this is true and whether we’re missing anything else we should be specifying so we don’t get caught out again?

Thanks
Mark Wightman
CTO, CloudHub360

2

You may check this answer to a somewhat related issue; it’s not the same root cause but it explains the overall context.

As you correctly discovered the issue is in the .NET library that is used to call the Management API; based on your analysis, the library should not be setting that property to a default of None because that value in this case actually represent a valid choice and not the lack of any choice. I haven’t look at the library code yet, but either it should not be explicitly setting that value or should be using a nullable property so that the .NET runtime also does not set any default value.

Again from your analysis, the Management API is then thinking you chose a token endpoint authentication method of none and is excluding client credentials from the grant types assigned to the client.

For now your workaround of setting the token endpoint authentication method property explicitly is the recommended one as that would then allow the Management API to include the client credentials grant. As mentioned in the linked answer, enforcement of the grant types is now being done and has impact on new clients because all existing clients were assigned all possible grant types in order to not break them.

In addition, I’ll set a note to review and report the situation in the .NET library; thanks for bringing this to our attention and for the detailed analysis.