-
Notifications
You must be signed in to change notification settings - Fork 546
Description
Is your feature request related to a problem? Please describe.
Based on the analysis of the ClientOAuthProvider.cs, my understanding is -
Storage Mechanism
- Refresh tokens are stored in-memory within the ClientOAuthProvider instance
- They're held in a
TokenContainerassigned to the private field_token
Management Patterns
-
Automatic Refresh: The
GetCredentialAsyncmethod checks access token validity and automatically uses the stored refresh token to obtain a new access token when needed -
Refresh Process: The
RefreshTokenAsyncmethod sends a request to the OAuth server using the refresh_token grant type. On success, it receives a newTokenContainer(with potentially a new refresh token) which replaces the old _token object -
In-Memory Only: This is explicitly a "generic implementation" that holds tokens in memory without giving ability to persist.
-
Lifecycle: The refresh token's lifecycle is tied to the ClientOAuthProvider instance - if the instance is garbage collected or the application restarts, the refresh token is lost.
Describe the solution you'd like
If user gives offline_access, I want to implement persistent storage for refresh tokens. So that it can be -
- Sent persisted
refresh_tokenthroughSseClientTransportand SDK handles gettingaccess_tokenand also ability to persist the new refresh token - Manually get the new
access_tokenand send it throughSseClientTransport
Or, some sort of Token Store Abstraction with default implementation and inject this store into ClientOAuthProvider.
Describe alternatives you've considered
May be fork and make the things work, but issue will be with maintainability.