Switching Unauthenticated Users to Authenticated Users In V6

[thesnups]

Before opening, please confirm:

• I have searched for duplicate or closed issues and discussions.
• I have read the guide for submitting bug reports.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework

React

Amplify APIs

Authentication

Amplify Version

v6

Amplify Categories

Not applicable

Backend

CDK

Environment information

  System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i9-11900KF @ 3.50GHz
    Memory: 102.20 GB / 127.68 GB
  Binaries:
    Node: 20.17.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.8.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (132.0.2957.127)
    Internet Explorer: 11.0.26100.1882
  npmPackages:
    @apollo/client: ^3.12.8 => 3.12.9 
    @apollo/client/cache:  undefined ()
    @apollo/client/core:  undefined ()
    @apollo/client/dev:  undefined ()
    @apollo/client/errors:  undefined ()
    @apollo/client/link/batch:  undefined ()
    @apollo/client/link/batch-http:  undefined ()
    @apollo/client/link/context:  undefined ()
    @apollo/client/link/core:  undefined ()
    @apollo/client/link/error:  undefined ()
    @apollo/client/link/http:  undefined ()
    @apollo/client/link/persisted-queries:  undefined ()
    @apollo/client/link/remove-typename:  undefined ()
    @apollo/client/link/retry:  undefined ()
    @apollo/client/link/schema:  undefined ()
    @apollo/client/link/subscriptions:  undefined ()
    @apollo/client/link/utils:  undefined ()
    @apollo/client/link/ws:  undefined ()
    @apollo/client/masking:  undefined ()
    @apollo/client/react:  undefined ()
    @apollo/client/react/components:  undefined ()
    @apollo/client/react/context:  undefined ()
    @apollo/client/react/hoc:  undefined ()
    @apollo/client/react/hooks:  undefined ()
    @apollo/client/react/internal:  undefined ()
    @apollo/client/react/parser:  undefined ()
    @apollo/client/react/ssr:  undefined ()
    @apollo/client/testing:  undefined ()
    @apollo/client/testing/core:  undefined ()
    @apollo/client/testing/experimental:  undefined ()
    @apollo/client/utilities:  undefined ()
    @apollo/client/utilities/globals:  undefined ()
    @apollo/client/utilities/subscriptions/relay:  undefined ()
    @apollo/client/utilities/subscriptions/urql:  undefined ()
    @babel/plugin-proposal-private-property-in-object: ^7.21.11 => 7.21.11
    @chakra-ui/react: ^3.7.0 => 3.7.0
    @emotion/cache: ^11.14.0 => 11.14.0
    @emotion/react: ^11.14.0 => 11.14.0
    @fontsource/overpass: ^4.5.9 => 4.5.11
    @jsonforms/core: ^3.5.1 => 3.5.1
    @jsonforms/react: ^3.5.1 => 3.5.1
    @types/lodash-es: ^4.17.7 => 4.17.12
    @types/react: 19.0.0 => 19.0.0
    @types/react-dom: 19.0.0 => 19.0.0
    @types/uuid: ^9.0.2 => 9.0.8
    @typescript-eslint/eslint-plugin: ^5.60.1 => 5.62.0
    @vitejs/plugin-react: ^4.3.4 => 4.3.4
    ajv: ^8.12.0 => 8.17.1 (6.12.6)
    ajv-errors: ^3.0.0 => 3.0.0
    aws-amplify: ^6.12.3 => 6.12.3
    aws-amplify/adapter-core:  undefined ()
    aws-amplify/analytics:  undefined ()
    aws-amplify/analytics/kinesis:  undefined ()
    aws-amplify/analytics/kinesis-firehose:  undefined ()
    aws-amplify/analytics/personalize:  undefined ()
    aws-amplify/analytics/pinpoint:  undefined ()
    aws-amplify/api:  undefined ()
    aws-amplify/api/server:  undefined ()
    aws-amplify/auth:  undefined ()
    aws-amplify/auth/cognito:  undefined ()
    aws-amplify/auth/cognito/server:  undefined ()
    aws-amplify/auth/enable-oauth-listener:  undefined ()
    aws-amplify/auth/server:  undefined ()
    aws-amplify/data:  undefined ()
    aws-amplify/data/server:  undefined ()
    aws-amplify/datastore:  undefined ()
    aws-amplify/in-app-messaging:  undefined ()
    aws-amplify/in-app-messaging/pinpoint:  undefined ()
    aws-amplify/push-notifications:  undefined ()
    aws-amplify/push-notifications/pinpoint:  undefined ()
    aws-amplify/storage:  undefined ()
    aws-amplify/storage/s3:  undefined ()
    aws-amplify/storage/s3/server:  undefined ()
    aws-amplify/storage/server:  undefined ()
    aws-amplify/utils:  undefined ()
    aws-appsync-auth-link: ^3.0.7 => 3.0.7
    aws-rum-web: ^1.19.0 => 1.19.0
    babel-plugin-react-compiler: ^19.0.0-beta-27714ef-20250124 => 19.0.0-beta-714736e-20250131
    eslint: ^8.44.0 => 8.57.1
    eslint-plugin-react-compiler: ^19.0.0-beta-27714ef-20250124 => 19.0.0-beta-714736e-20250131
    eslint-plugin-react-refresh: ^0.4.1 => 0.4.18
    lodash-es: ^4.17.21 => 4.17.21
    moment: ^2.29.4 => 2.30.1
    next-themes: ^0.4.4 => 0.4.4
    react: 19.0.0 => 19.0.0
    react-dom: 19.0.0 => 19.0.0
    react-icons: ^4.12.0 => 4.12.0
    react-router: ^7.1.5 => 7.1.5
    react-use: ^17.6.0 => 17.6.0
    rollup-plugin-visualizer: ^5.9.2 => 5.14.0
    use-query-params: ^2.2.1 => 2.2.1
    use-query-params/adapters/reach:  undefined ()
    use-query-params/adapters/react-router-5:  undefined ()
    use-query-params/adapters/react-router-6:  undefined ()
    use-query-params/adapters/window:  undefined ()
    uuid: ^8.3.2 => 8.3.2 (9.0.1)
    vite: ^6.0.11 => 6.1.0
    vite-plugin-checker: ^0.8.0 => 0.8.0
    vite-plugin-node-polyfills: ^0.23.0 => 0.23.0
  npmGlobalPackages:
    corepack: 0.29.3
    npm: 10.8.2

Describe the bug

Context

In my React/Vite app I am using amplify-js to facilitate user authentication flows. I'm not using Amplify on the backend, but rather am configuring amplify-js to use my existing AWS resources with Amplify.configure. On the backend I have a Cognito user pool and identity pool. The identity pool has the user pool configured as an identity provider. These resources are deployed via CDK.

Issue

Cognito supports upgrading/switching identity pool identities from "unauthenticated" to "authenticated" when a user logs in with an identity provider linked to the identity pool (source). When doing so, the identity ID is stable and a new linked login is added to the identity. amplify-js@5 didn't initially support this feature, but a feature request was opened to track it, and eventually a PR was merged implementing the feature. When I began using amplify-js@5 in my project I recall manually testing and verifying that the feature worked as expected.

I am now in the process of upgrading to amplify-js@6, and it looks like the feature doesn't work anymore. When I visit my web app as an unauthenticated user, I am assigned an identityId. Then, after logging in, I am assigned a different identityId. Instead of adding a linked login to the existing identity, a new identity is created, which replaces the previous one in the client. When I check identity pool identity browser in the AWS Console, I can see both identities: the original "guest" identity with no linked logins, and a new "authenticated" identity with a linked login.

I spent some time reading the amplify-js@6 code, and it looks like the intention was to port this feature over from v5. Specifically, these lines of code appear to implement the feature. However, in practice the feature does not work. I think the issue is that this line of code, as it is written, can never produce the same identity ID as the guest identity. It will always return a new identity ID from Cognito:

const generatedIdentityId = await generateIdentityId(logins, authConfig); // always returns a new identity ID

if (identityId && identityId.id === generatedIdentityId) { // this will never be true
	logger.debug(
		`The guest identity ${identityId.id} has become the primary identity.`,
	);
}
identityId = {
	id: generatedIdentityId,
	type: 'primary',
};

Looking back at the v5 code, it appears the credential provider needs to make a GetCredentialsForIdentity call with the guest identity ID and the linked login in order to merge them and "upgrade" the identity.

Expected behavior

When visiting the app for the first time, a user is assigned a new "guest" identity ID with no linked logins. Then, if the user signs up and/or signs in with an identity provider, they keep the same identity and identity ID, but the new login info is added as a linked login to the identity.

Reproduction steps

1. Somewhere in your app, expose the fetchAuthSession function on the window, enabling you to call it from the dev tools console:

import { fetchAuthSession } from 'aws-amplify/auth';
(window as any).fetchAuthSession = fetchAuthSession;

2. Build and run the app.
3. Visit the app in the browser, open the dev tools and clear all site data. In Chrome, go to Application -> Storage -> Clear site data.
4. Refresh the page. At this time, amplify-js will generate a new identity for the unauthenticated session. Get the identity ID using fetchAuthSession in the dev tools console:

fetchAuthSession().then((session) => { console.log(session.identityId); });

5. Remember the identity ID. Next, use the app to sign in.
6. After signing in, use fetchAuthSession to get your identity ID:

fetchAuthSession().then((session) => { console.log(session.identityId); });

7. Expected behavior: the identity ID is the same, no new identity is created. Actual behavior: there is a new identity ID because a new identity was created.

Both identities can be seen in the AWS Console in Cognito's identity pool identity browser.

Log output

[INFO] 12:48.460 CognitoCredentialsProvider - returning stored credentials as they neither past TTL nor expired.
ConsoleLogger.ts:82 [INFO] 12:48.461 CognitoCredentialsProvider - returning stored credentials as they neither past TTL nor expired.
ConsoleLogger.ts:82 [INFO] 12:53.90 CognitoCredentialsProvider - returning stored credentials as they neither past TTL nor expired.
ConsoleLogger.ts:94 [DEBUG] 13:04.934 Hub - Dispatching to auth with  {event: 'signedIn', data: {…}}
ConsoleLogger.ts:82 [DEBUG] 13:05.130 CognitoCredentialsProvider - Clearing out in-memory credentials
ConsoleLogger.ts:82 [DEBUG] 13:15.571 CognitoCredentialsProvider - returning stored credentials as they neither past TTL nor expired.

aws-exports.js

No response

Manual configuration

No response

Additional configuration

No response

Mobile Device

No response

Mobile Operating System

No response

Mobile Browser

No response

Mobile Browser Version

No response

Additional information and screenshots

No response

[HuiSF]

Hi @thesnups Thanks for reporting this issue. IIRC, once an end user signs up for an account, it will be associated with an "authenticated user" identityId, and this identityId will be consistent when signing out and re-signing in. However, it has never been the case that re-assigning an "unauthenticated user" identityId to an existing user account while signing in.

Currently in v6, however, when an "unauthenticated user" signs up a new account, the "unauthenticated user" identityId is not assigned to the newly signed up account. Is this actually what you are observing, could you confirm? We do have a future improvement item in the backlog to fulfill this gap.

[thesnups]

Hi @HuiSF , thank you for the response. It makes sense that for existing user accounts the guest identity ID would not replace the authenticated identity ID. As you suggested, I am referring specifically to the case where the guest identity ID becomes the authenticated identity ID when a user first signs up and in. This feature was added to V5, but it is not fully implemented in V6. There is code in V6 that appears to implement the feature, but it is not complete. Any idea when the team might be able to address this?

[HuiSF]

Thanks for the confirmation @thesnups we will discuss internally and update the progress here.