search

auth0 / auth0-java

Java client library for the Auth0 platform
https://auth0.com
MIT License
286 stars 131 forks source link

Provide a custom TokenProvider to ManagementAPI.Builder instead of a static token #545

Closed clementdenis closed 1 year ago

clementdenis commented 1 year ago

Changes

This commit adds a new constructor to ManagementAPI.Builder, so a custom TokenProvider can be used. This is useful to implement auto-refresh for example, like https://github.com/auth0/auth0-java/compare/master...clementdenis:auth0-java:auto_refresh_token_provider (I can create another PR if this one is accepted).

An alternative would be to make the constructor at https://github.com/auth0/auth0-java/blob/master/src/main/java/com/auth0/client/mgmt/ManagementAPI.java#L70 public to pass a TokenProvider.

Checklist

jimmyjames commented 1 year ago

👋 hi @clementdenis, thanks for the PR! We definitely do want to support a TokenProvider that implements auto-refresh, or at least make it possible for customers to implement their own, which it appears is what this PR targets.

Did you try out using a custom TokenProvider with this change? I'd like to see your implementation and if you ran into any issues with the net client using it for both sync and async cases.

jimmyjames commented 1 year ago

Closing due to inactivity, but we are interested in providing a TokenProvider implementation that handles token refresh.

clementdenis commented 1 year ago

Hi @jimmyjames !

I don't use AutoRefreshTokenProvider directly, but I'm using something similar, that works perfectly fine for the sync use case at least.

I have to perform some reflection magic on the private constructor to inject my custom TokenProvider, that's why it would be great to have the current PR merged, regardless of the auto-refresh concern.

tsbatista commented 7 months ago

hey @jimmyjames,

Sorry about digging this up but would it make sense to merge this instead of closing it? It opens the door to alternative provider contributions even if they are not there right now.

I was about to create a similar MR, so that I could plug my private implementation that refreshes the tokens proactively according to a policy. Others may want to plug in an implementation that refreshes only when expired... Having the interface as a parameter, even if you only provide a single implementation does not seem to have a down side. It also reduces reflection abuses such as the one @clementdenis had to do to string in their implementation.