Select to view content in your preferred language

IdentityManager Refresh Token Nullified after App Suspension (iOS/Chrome) - Is this intended?

55
0
yesterday
MattStayner
Frequent Contributor

Hello everyone,

I’m seeking some clarification on the internal behavior of IdentityManager regarding token renewal, specifically in mobile and field environments. We are seeing a high frequency of re-authentication prompts from our field users, and I’ve managed to capture some specific behavior in the browser storage that seems to be the culprit.

The Environment:

  • ArcGIS Maps SDK for JavaScript (4.x)

  • ArcGIS Enterprise (Portal) 11.x AND ArcGIS Online

  • Devices: iPad (Safari/Chrome) and Windows Laptops (Chrome)

The Behavior Observed:

  1. User signs in successfully. The esriJSAPIOAuth object is created in storage.

  2. We’ve noticed the data is often defaulting to Session Storage rather than Local Storage.

  3. While the app is active, silent renewal works perfectly.

  4. The Issue: If a user minimizes the app (or locks the device) for a period longer than the Access Token's lifespan (e.g., 60 minutes), upon returning to the app, the esriJSAPIOAuth object still exists, but the refreshToken and expires properties have been explicitly set to null.

Technical Evidence: Initially, I thought the session was just being cleared, but the key esriJSAPIOAuth remains in storage—it's just the specific token values that are wiped. This suggests the Identity Manager is actively nullifying the Refresh Token, likely due to a failed renewal attempt during the wake-up/resumption process.

My Questions:

  1. Is this expected behavior? Does the Identity Manager proactively nullify a Refresh Token if a renewal request fails due to a transient network drop during app resumption?

  2. Persistence: Is there a way to force the Identity Manager to use localStorage instead of sessionStorage more reliably? I've seen mentions of portalUrl in OAuthInfo triggering this, but is there a definitive way to ensure the refresh token survives an OS-level app suspension?

  3. Best Practices: Aside from building a completely custom OAuth flow and using registerToken(), are there recommended settings in OAuthInfo to make the SDK more resilient to field connectivity issues so that users don't have to sign in every time they drive through a dead zone?

I've confirmed via manual fetch calls that both our Enterprise Portal and ArcGIS Online /oauth2/token endpoints are working correctly and returning valid tokens. It seems to be a client-side logic decision to clear the credentials.

Any insights would be greatly appreciated!

0 Kudos
0 Replies