Expose authParamsMap in the connection options block

[mdoelle]

Checklist

• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

Currently, when using the Auth0 Terraform provider to manage social identity provider connections, we are unable to directly define dynamic parameters (authParamsMap) within the connection configuration. After each Terraform update, the authParamsMap is lost, and we are required to manually patch the connection using a script. This leads to short periods of broken connection configurations, causing instability and additional overhead.

Describe the ideal solution

The ideal solution would be to expose the authParamsMap directly in the connection options block for a configuration. This would allow users to define dynamic parameters in a seamless manner, ensuring that the parameters persist across updates without requiring manual intervention or additional scripts.

Alternatives and current workarounds

Currently, the workaround is to apply a script after every update to re-apply the authParamsMap. However, this solution introduces temporary connection failures, as the dynamic parameters are lost during the update process.

Additional context

Auth0 allows users to pass dynamic parameters to the authorization endpoint via authParamsMap for social identity provider connections. Documentation on how this works is available here.

[duedares-rvj]

@mdoelle Hello 👋
Thanks for taking the time out and opening this issue with such detail.

I can see that authParamsMap is not mentioned under options block in Management API Docs but the usage is described here

I'm creating a task for myself on this and shall revert back soon.
Regards.

[duedares-rvj]

Hello again,

We’ve started an internal discussion, and the key step here is getting the most up-to-date schema for connection options reflected in the API documentation and the OpenAPI Spec. Once that’s in place, missing attributes like authParamsMap should be supported automatically, without requiring piecemeal fixes.

Our goal is to resolve this holistically by ensuring the options schema is fully updated so no fields are left out, including in the Terraform provider. Until then, I’ll keep this item in discussion so it isn’t lost, and we welcome any further input from the community in the meantime.

To be clear, we are already exploring multiple approaches to attain a defined schema for options.
Once the schema is finalised and the docs are updated, I shall drop in further updates here.

For transparency:
ESD-50501 tracks this specific request.
PDOPPS-6359 covers the broader work on connection options.

Thanks again for the input.
You feedback helps us improve the provider.