Persisting Token Refresh

[longden]

Describe the feature request?

Currently, there is no mechanism for the refresh token network call to outlive the suspend function(s) that call it. This can be observed in the sample by performing a token refresh, navigating away, then back, and clicking refresh. Instead of listening to the ongoing token refresh, a new request is made.

A common pattern for apps is to make a network request and, within an interceptor, fetch an access token if expired and attach it to the request. This approach can lead to any network call that is cancelled (due to timeout e.g. a short rx .timeout or navigating away from the app, especially if these calls are viewModelScoped) potentially cancelling the ongoing token exchange. This seems counterintuitive when refresh tokens are one-time use and require synchronization to ensure only one call is made. While the CoalescingOrchestrator helps in some cases it doesn't help with the scenario above. (While a grace period can be set up on the Okta side, it increases the chance of a replay attack and may not be suitable for all use cases.)

Although each client can implement a wrapper around this feels common enough with enough 'gotchas' that it might be better solved through the library. Maybe through a publish/subscribe solution, having the refresh work kick off in a separate longer-lived scope, or even a service might be more appropriate given the requirements.

This brings me to two questions:
1. Should the library provide some assistance around this?
2. Is there a suggested way of handling this with respect to this library for those who use the interceptor pattern described above?

New or Affected Resource(s)

Token Refresh

Provide a documentation link

No response

Additional Information?

No response

[rajdeepnanua-okta]

@longden, thanks for filing this suggestion. There is an accessTokenInterceptor in Credential class that can be attached to an OkHttpClient, which is not tied to any coroutine scope. The interceptor attaches an accessToken to your request, and if it's expired, refreshes automatically. The SDK internally takes care of ensuring only one refresh request is made at any time. This should address your use case if I understand correctly.