Auth0 - Open ID Connect Dynamic Client Registration issues

Help
1

Guys,

I am needing to dynamically register a client application in Auth0 from the Anypoint (MuleSoft) Integration platform, based on the “CLIENT-CREDENTIALS” grant type.

However, I have encountered 2 issues,

  1. It appears that Auth0 does not define the "grant_types_supported " in the well-known doc.
    If “grant_types_supported” is not shown in the well-known doc, it indicates that Auth0 only support the default grant types (“authorization_code” and “implicit” grant type), which does not include the required “client credentials” grant type.

  2. It appears Auth0 does not support the “response_types” when the Anypoint Platform, sends the request to Auth0 to register the client application.
    For example, below is the request sent by the Anypoint Platform to Auth0 to register the client application.

curl -X POST
https://<YOUR_DOMAIN>.auth0.com/oidc/register
-H ‘Content-Type: application/json’
-H
…
no-cache’
-d ‘{
“redirect_uris”:["https://<YOUR_DOMAIN>.auth0.com/callback"],
“grant_types”:[“implicit”],
“token_endpoint_auth_method”:“client_secret_basic”,
“response_types”:[“token”,“id_token”],
“client_name”:“TestApp”
}’

response:

validation error: ‘Additional properties not allowed: response_types’.",“errorCode”:“invalid_body”}

In other words, the registration of the client application fails because of Auth0 non-support for the “response_types”.

Please note, the above 2 issues are found only with Auth0. These issues were not found when trialed with other providers such as Okta.

Please advise, when is this issue expected to be solved in Auth0.

Thanks.
Savio

1 Like
3

Hi @savio.a.mascarenhas!

Thanks for reporting this. Quite honestly, the Dynamic Client Registration feature is not used much, so I’m guessing no one encountered this problem before.
I agree that both cases should be covered and I’ve added an internal feature request to our Product team. I can’t promise any quick outcomes on this (it will depend on prioritization of other items in the roadmap), so hopefully you can provide some kind of override in Anypoint both to convince it that the server will accept client credentials, and not to send the response_types in the payload for now.

1 Like
4

Hi @nicolas_sabena!

Thanks for your response. I checked with MuleSoft and received the below response from MuleSoft support team,

"MuleSoft product team has raised this to Auth0 around 2 years ago however still no progress. Anypoint Platform is a vendor-neutral platform so we do not want to risk changing for one non-compliant IDP to break others. We have a few customers hitting the issue with the Dynamic Client Registration feature, due to “response_types” not supported by Auth0. Some customers tried to work around this by building a custom proxy, so when creating a client, the request is sent to the proxy and the proxy strips the “response_types” header from the request before forwarding it to Auth0. Some customers changed to use Auth0 as an OAuth server with JWT.

However, to get it properly fixed, we recommend escalating it to Auth0 and request the implementation to be compliant with the spec."

Thanks.
Savio

5

Hello @nicolas_sabena

We’re also a Mulesoft customer wishing to use dynamic client registration and are unable to for the same reason. I just want to add that this is the only reason we are not a paying customer. Get this fixed and you will have our money.

On a side note, having a supported introspection endpoint would be nice too, even if it’s for an extra cost.

Thanks,
Roger Borges

6

Apologies for not being very responsive lately. Would you mind reporting this at Auth0: Secure access for everyone. But not just anyone.? That reaches the Product Team directly, and this type of feedback helps them prioritize all the things they have in the pipeline.

Thanks in advance!

1 Like
7

We are also interested in this feature. Is there any progress? This is a blocker for us to select Auth0 as Idp.

8

Hi,

any progress on this?

It’s feasible creating dynamic applications allowing them to use client_credentials flow?

The use case is clear: letting partners and customers authenticate using their own devices/systems instead in behalf a user.

Thanks.