Refactor AccessTokenProvider to relieve some concerns to TokenRequestContext #24
Labels
type:breaking-change
An issue that will result in dependent client projects failing.
type:enhancement
Enhancement request targeting an existing experience
PhpLeagueAccessTokenProvider mixes two many concerns:
Because of that, and specialization with national endpoints, to expose the full API surface, we're leaking those concerns to derived classes, or required to add this setter.
And even with the latter approach, their does not seem to be a way for a consumer of the Graph Authentication Provider to set the token cache for the access token provider... Masking some of the customization abilities, or loosing the specialization for national clouds etc in the process.
Beyond the degraded developer experience, we risk introducing "experience bugs" where settings things one way doesn't flow all the way down, but does by using another API.
I believe the correct thing to do would be to move the concerns that should not be in PhPLeagueAccessTokenProvider to the token request context. I understand this is a significant undertaking and would be considered a breaking change.
further context: microsoft/kiota-authentication-phpleague-php#106
The text was updated successfully, but these errors were encountered: