[GitHub] [pulsar] lhotari commented on pull request #13951: [OAuth2] Enable configurable early token refresh in Java Client

[GitBox <gi...@apache.org>]

lhotari commented on pull request #13951:
URL: https://github.com/apache/pulsar/pull/13951#issuecomment-1033953294


   > > I think that the way to specify the refresh interval by using the "early_token_refresh_percent" configuration parameter is not well suited for all use cases.
   > 
   > Would you mind clarifying this use case with an example? On one hand, I accept that percent may be slightly less straight forward, but on the other hand, I think it handles certain edge cases really well. For example, each retrieved token can have a unique `expires_in` value. A percentage naturally handles this variability. Further, there is no guarantee that the min and max refresh interval that you described will fall within the `expires_in` value. Let me know what you think.
   
   The use case would be that you want to maximize the time that a token is active at all times. The reason to do this is that if the identity provider becomes unavailable, there is less risk the whole system becomes unavailable because of the identity provider being unavailable. The system will tolerate a long downtime when the tokens are always active for the maximum period of time. The tradeoff is that there will be more token refreshes made towards the identity provider. 
   
   You might want to refresh the token every 10 minutes regardless of the validity of the token, given that the token is valid for more than 10 minutes. The solution I proposed wasn't probably the best way to address this use case. 
   
   Another person might want to refresh the token 10 minutes before the validity of the token expires, regardless of how long the token is valid. 
   
   For the above usecases, I would assume that configuring the solution would be possible with  2 parameters (naming is hard, so the names are still bad):
   "refresh before expiration duration"
   "minimum token usage duration"
   
   The problem with the 10 minutes before token expires example is the case where the token is valid for less than 10 minutes. That's why it is necessary to have a second parameter to define how long the token is kept used until a refresh is made.
   
   Let's say that the user has set "refresh before expiration duration" to 10 minutes and "minimum token usage duration" to 2 minutes. If the returned token is valid for 10 minutes, it would start the refresh after 2 minutes.
   
   I simply don't see a use case for the earlyTokenRefreshPercent way of configuring the refresh scheduling. In the requirement we have, it's about exact times instead of percentages. I think that percentages would be confusing for users. "refresh before expiration duration"
   and "minimum token usage duration" parameters would be easier to understand.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org