Cached identity pool id is never evicted after "Access to Identity is forbidden" (NotAuthorizedException from GetCredentialsForIdentity) — session wedges permanently #4278

Describe the bug

When GetCredentialsForIdentity rejects the cached identity pool id with NotAuthorizedException ("Access to Identity 'us-east-1:…' is forbidden."), the plugin never evicts the cached identity id. The authorization state machine lands in .error(.sessionError(.notAuthorized, credentials)) with the poisoned credentials retained inside the error state, and every subsequent fetchAuthSession re-presents the exact same cached identity id:

• FetchAuthSessionOperationHelper.fetch handles case .error(.sessionError(_, let credentials)) by calling refreshIfRequired(existingCredentials: credentials, …) — same blob, same identity id.
• InitializeRefreshSession always pairs the stored identityID with the stored/refreshed tokens (.refreshCognitoUserPoolWithIdentityId, .refreshAWSCredentialsWithUserPool); there is no path that falls back to a fresh GetId after the identity was rejected.

The error is terminal server-side (the identity is linked to a different login, disabled, or deleted), so the device retries forever and the session never recovers. For a signed-in user this surfaces as getUserSub() / getCognitoTokens() returning the forbidden error on every launch while isSignedIn stays true — a permanently wedged boot. The only recovery is app-side: call Amplify.Auth.signOut() (which deletes the whole credential blob) and force re-authentication.

This is the same defect class as aws-amplify/amplify-js#5696, which was fixed there by evicting the cached identity id when this error is received.

We verified this against production telemetry: affected devices (predominantly account switchers whose local state ended up holding an identity id from a previous account) hit the error on every boot, on multiple days, and never self-recover; devices on an app version that reacts to this error with an explicit signOut() recover immediately.

Steps To Reproduce

1. Configure Auth with user pool + identity pool.
2. Sign in; let the plugin store userPoolAndIdentityPool(signedInData, identityID, credentials).
3. Arrange for the stored identity id to be rejected by Cognito — e.g. delete the identity in the identity pool console, or reproduce a state where the stored identity id belongs to a different login than the stored tokens.
4. Call Amplify.Auth.fetchAuthSession() (or relaunch) repeatedly.

Observed: every call performs GetCredentialsForIdentity with the same rejected identity id and fails with NotAuthorizedException ("Access to Identity … is forbidden"). The cached identity id is never discarded; no GetId with the current logins map is ever attempted.

Expected behavior

On NotAuthorizedException from GetCredentialsForIdentity, the plugin should evict the cached identity id and retry with a fresh GetId using the current logins map (mirroring the amplify-js fix in aws-amplify/amplify-js#5696). At minimum for the signed-in case, the terminal error should not permanently retain the rejected identity id in the credential store.

Amplify Framework Version

2.53.3

Amplify Categories

Auth

Dependency manager

Swift PM

Xcode version

26

Relevant log output

AuthError: notAuthorized
"Access to Identity 'us-east-1:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' is forbidden."
(identical on every fetchAuthSession / launch; never recovers without an explicit Amplify.Auth.signOut())

Is this a regression?

No — reproduced on 2.53.3; the relevant code paths (FetchAuthSessionOperationHelper, InitializeRefreshSession, AuthorizationState.Resolver .error handling) have behaved this way for a long time.