- 
                Notifications
    You must be signed in to change notification settings 
- Fork 555
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.