Added ManagementAPI token provider customization

[krrrr38]

Changes

Please describe both what is changing and why this is important. Include:

• Classes and methods changed

ManagementAPI currently support only api token. Auth0 supports api auth with authenticate-with-private-key-jwt and so on. At that time, we need to change Token Provider.

References

N/A

Testing

Please describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

• This change adds test coverage

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors

[tanya732]

@krrrr38

I really appreciate the contribution. I’ll review it today and get back to you shortly.

[salbracco24]

@tanya732 please review, thanks!

[tanya732]

Hi @krrrr38, @salbracco24

Thanks so much for this contribution! I appreciate you taking the time to improve the SDK. The idea of using a TokenProvider interface is to introduce flexibility for managing tokens.

However, the current implementation has a small issue and API clarity. It forces users who want to use the new TokenProvider to still provide a redundant API token to the constructor, which can be confusing and error prone if not configured properly.

To make this a seamless and clean integration for all of our users, I would propose a different approach for the ManagementAPI.Builder:

• Keep the Existing Constructor: Retain the public Builder(String domain, String apiToken) constructor exactly as it is for backward compatibility. This ensures that all our existing users can update the SDK without having their code break.
• Add a New Constructor: I'll add a new constructor, public Builder(String domain), that does not require a token. This will be the new entry point for developers who want to use a custom TokenProvider.
• Ensure a Token Provider is Set: The build() method will be updated to throw an IllegalStateException if a TokenProvider has not been configured, which prevents the client from being created in an invalid state.

This approach offers Backward Compatibility, Flexibility and Clarity.

What do you think of this approach? I'm happy to discuss further.

Thank you

[krrrr38]

@tanya732 I guess this is the best which has no breaking changes and we can customize with any token providers.
01dd898

[tanya732]

Hi @krrrr38

Thanks again for the contribution!
Could you please fix the test cases and make sure all your commits are signed?

I believe this change will also require a small update to the README/Example docs so others can understand how to use this.

Thank you

[krrrr38]

@tanya732 oops. updated, thanks.

[salbracco24]

I'm fine with the approach described here:
#729 (comment)

[tanya732]

@krrrr38

Can you please help signing all your commits ?

Thank you

[krrrr38]

@tanya732 updated.

[tanya732]

We have to update the build method with tokenProvider

[tanya732]

@krrrr38

Thank you for the contribution !!

I have raised #748 with these changes. I'll publish in next release cycle.

[tanya732]

Hi @krrrr38

The changes have been successfully released and can be found here

Accordingly, I am closing the PR.

Thank you for your contribution!

[salbracco24]

Epic!