Add OIDC backchannel initiators

[bryanroute]

🔧 Changes

This PR adds support for configuring the oidc_logout block in the auth0_client resource. This enhancement enables more detailed configuration of OIDC backchannel logout, which was previously limited to setting the backchannel_logout_urls.

The oidc_logout block includes the following:

• backchannel_logout_urls: (Required) A set of URLs that Auth0 will call back for OIDC backchannel logout. Currently, only one URL is allowed.
• backchannel_logout_initiators: (Optional) Configures the OIDC logout initiators for the client. Includes:
  • mode: (Required) Determines how initiators are configured:
    • "all": Enables all current and future initiators.
    • "custom": Limits initiators to those explicitly listed in selected_initiators.
  • selected_initiators: (Optional) A list of specific initiators enabled for the client when mode is set to "custom".

These additions allow comprehensive OIDC backchannel logout functionality to be fully managed via Terraform.

⚠️ Note: This is my first PR working with a Terraform provider. I’ve aimed to adhere to Terraform SDK guidelines, but I welcome feedback or suggestions to improve the implementation.

📚 References

Addresses this open issue with the proposed design
#1030

Also addresses this support ticket: https://support.auth0.com/tickets/02368461

🔬 Testing

Test checks were added to the existing tests however http recordings need to be regenerated for the tests to pass and it appears from what I could figure that has to be done by someone that has access to the test tenant terraform-provider-auth0-dev.eu.auth0.com

I did run the e2e tests against my own test tenant and everything passed except for some tests related to features not enabled in my test tenant.

This was manually tested and verified by creating a client with none of the back channel properties set, one with the mode all and one with the mode custom. Everything appears to function as I expected.

I do have an open question whether the approach to handling the default mode/initiators is the correct one however I'm not sure of a better approach and the behavior seems to mirror similar behavior I've observed with other terraform providers I've worked with.

📝 Checklist

• All new/changed/fixed functionality is covered by tests (or N/A)
• I have added documentation for all new/changed functionality (or N/A)

[developerkunal]

Perhaps it would be better to create a nested OIDCLogout structure instead of the current approach, as oidc_backchannel_logout_urls already contains other values. We can deprecate oidc_backchannel_logout_urls and introduce OIDCLogout, with nested properties such as oidc_backchannel_logout_urls and BackChannelLogoutInitiators, similar to the implementation in the SDK.

[bryanroute]

@developerkunal I just updated with your suggestion of using a oidc_logout block with nested attributes. There are still some failing tests when I run E2E in my test tenant not related to features we don't have enabled.

The problem appears to be that the API returns the logout urls both in the OIDCBackchannelLogout object and the OIDCLogout object. I've tried a couple different approaches but rolled them back because they all had unintended side effects. The problem is we don't necessarily know which approach in the flatten to take, ignore the old setting or ignore the new one. The paths I've gone down have all caused another test to fail. I'm going to step away and then come back at it fresh. If you have any suggestions for handling it I'd appreciate them.

[Seha16]

@developerkunal I just updated with your suggestion of using a oidc_logout block with nested attributes. There are still some failing tests when I run E2E in my test tenant not related to features we don't have enabled.

The problem appears to be that the API returns the logout urls both in the OIDCBackchannelLogout object and the OIDCLogout object. I've tried a couple different approaches but rolled them back because they all had unintended side effects. The problem is we don't necessarily know which approach in the flatten to take, ignore the old setting or ignore the new one. The paths I've gone down have all caused another test to fail. I'm going to step away and then come back at it fresh. If you have any suggestions for handling it I'd appreciate them.

@bryanroute If I understand you correctly, I think, it's better to ignore old setting oidc_backchannel_logout_urls because if there is introduced a new block oidc_logout, it requires backchannel_logout_urls in it. Thus it guarantees that Backchannel Logout URL will be present in the execution plan.

[bryanroute]

@Seha16 I'm not sure I understand your suggestion. If I don't set the old oidc_backchannel_logout_urls then won't that generate a unexpected plan diff for someone using the old property and not implementing the new block?

I'm not sure if I'm understanding your suggestion.

[Seha16]

@bryanroute I just wanted to reply on your message

The problem is we don't necessarily know which approach in the flatten to take, ignore the old setting or ignore the new one.

And I want to say that I like you current implementation and agree with you to ignore oidc_backchannel_logout_urls if oidc_logout is introduced:

func flattenOIDCBackchannelURLs(backchannelLogout *management.OIDCBackchannelLogout, logout *management.OIDCLogout) []string {
  if logout != nil {
    return nil
  } else {
    return backchannelLogout.GetBackChannelLogoutURLs()
  }
}

...

data.Set("oidc_backchannel_logout_urls", flattenOIDCBackchannelURLs(client.GetOIDCBackchannelLogout(), client.GetOIDCLogout())),
data.Set("oidc_logout", flattenOIDCLogout(client.GetOIDCLogout())),

There was silence in this PR and no replies on your comments for a while. So I thought voting for your solution may bring some attention of the project contributors.

[bryanroute]

Ah @Seha16 I thought you were from Auth0. I got a message on my support ticket tracking the missing functionality. They are supposed to be reviewing my PR soon and figured that you were the one doing so. Appreciate drawing attention to it. I'm hoping I hear back from the team soon so we can get this functionality.

[developerkunal]

Hi @bryanroute ,
we need the commits to be signed. can you please sign the commits.