MigrateLegacyCredentialStore runs on every cold start and overwrites the Amplify session when the app also uses aws-sdk-ios's AWSCognitoCredentialsProvider #4279

Describe the bug

MigrateLegacyCredentialStore is intended as a one-time migration of pre-Amplify (aws-sdk-ios) credentials, but it actually runs before the first credential-store operation of every process: the CredentialStoreState machine is in-memory and starts at .notConfigured on each launch, and Resolver.resolveNotConfigured maps both .migrateLegacyCredentialStore and .loadCredentialStore to the MigrateLegacyCredentialStore action.

The migration reads the aws-sdk-ios AWSCognitoCredentialsProvider keychain (service "<bundleId>.AWSCognitoCredentialsProvider.<identityPoolId>", keys accessKey/secretKey/sessionKey/expiration/identityId). If all five are present it unconditionally calls amplifyCredentialStore.saveCredential(...), overwriting whatever the Amplify store currently holds — there is no check that the Amplify store is empty (i.e. that this is actually a first-run migration). With no legacy user-pool tokens present, the signed-in userPoolAndIdentityPool blob is replaced by identityPoolOnly(legacyIdentityId, staleLegacyCredentials), silently destroying the signed-in session. The migration then wipes the legacy keychain (_removeAll()), but the coexisting SDK re-populates it on its next credential fetch, re-arming the problem for the following launch.

This breaks any app that legitimately uses aws-sdk-ios's AWSCognitoCredentialsProvider side by side with Amplify Auth — the standard pattern for AWSS3TransferUtility (background uploads, which aws-sdk-swift does not cover), with the provider's AWSIdentityProviderManager bridged to Amplify.Auth.fetchAuthSession() tokens. That provider persists its identity id and temp credentials in exactly the keychain the migration consumes, on every credential fetch.

Consequences we observed in production (amplify-swift 2.53.3 + aws-sdk-ios 2.41.0 AWSS3/AWSCore):

• Users are silently signed out on the cold start after any S3 upload (their user-pool tokens are erased by the overwrite).
• Worse, after an account switch the resurrected identityPoolOnly blob carries the previous account's identity id; presenting it yields NotAuthorizedException "Access to Identity … is forbidden" — and per Cached identity pool id is never evicted after "Access to Identity is forbidden" (NotAuthorizedException from GetCredentialsForIdentity) — session wedges permanently #4278 that error is never evicted, so the device wedges.

Issue #3225 appears to be an earlier symptom-level report of the same coexistence problem ("Getting logged out of Amplify when providing Credentials to [aws-sdk client] and restarting application").

Our app-side workaround is to call AWSCognitoCredentialsProvider.clearKeychain() before Amplify.configure() on every launch so the migration finds nothing — which works, but costs the legacy provider its credential cache and should not be necessary.

Steps To Reproduce

1. App with Amplify Auth (user pool + identity pool), signed in.
2. Also create an aws-sdk-ios AWSCognitoCredentialsProvider for the same identity pool (e.g. for AWSS3TransferUtility), with a custom AWSIdentityProviderManager returning the Amplify session's id token, and perform any operation that makes it fetch credentials (an upload). Its keychain service <bundleId>.AWSCognitoCredentialsProvider.<poolId> now holds identityId + temp credentials.
3. Kill and relaunch the app; call Amplify.Auth.fetchAuthSession().

Observed: MigrateLegacyCredentialStore runs, finds the "legacy" data written in step 2, and overwrites the signed-in Amplify credential blob with identityPoolOnly(identityId, staleCredentials). fetchAuthSession().isSignedIn is now false; the user is signed out. If the cached identity id belonged to a previously signed-in account, subsequent refreshes fail with "Access to Identity … is forbidden" instead.

Expected behavior

The migration should be a true one-time operation — e.g. guarded by a persisted "migration completed" marker, and/or skipped whenever the Amplify credential store already contains credentials. Data written by a coexisting aws-sdk-ios credentials provider must never overwrite an established Amplify session.

Amplify Framework Version

2.53.3

Amplify Categories

Auth

Dependency manager

Swift PM (amplify-swift); CocoaPods for aws-sdk-ios AWSS3/AWSCore 2.41.0

Xcode version

26

Relevant log output

Credential Store state change: CredentialStoreState.notConfigured -> migratingLegacyStore (every cold start)
After a launch following an S3 upload: fetchAuthSession().isSignedIn == false (user silently signed out)
or: AuthError: notAuthorized "Access to Identity 'us-east-1:…' is forbidden."

Is this a regression?

No — the every-launch migrate-then-load flow is long-standing behavior of the credential store state machine.