fix(aws-amplify): refresh default Cognito auth config on DefaultAmplify reconfigure

[ShrutiPundir17]

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

Next.js

Amplify APIs

Authentication, Storage

Amplify Version

v6

Amplify Categories

auth, storage

Backend

Amplify Gen 2

Environment information

Details

# Put output below this line

System:
  OS: Windows 11 10.0.26200
  CPU: (8) x64 Intel(R) Core(TM) Ultra 7 256V
  Memory: 1.94 GB / 15.54 GB
Binaries:
  Node: 22.17.0
  npm: 10.9.2
Browsers:
  Edge: Chromium (140.0.3485.54)
npmPackages:
  aws-amplify: 6.x (latest on npm at time of report)

Describe the bug

When using Amplify.configure from the aws-amplify package (DefaultAmplify.configure in packages/aws-amplify/src/initSingleton.ts), subsequent configure calls can behave incorrectly in two ways:

1. Non-Auth libraryOptions are dropped on reconfigure
   @aws-amplify/core replaces libraryOptions when a new object is passed (no merge). DefaultAmplify is responsible for merging before calling core, but several reconfigure paths did not:

Passing libraryOptions.Auth alone replaced the whole options object and dropped keys such as Storage from an earlier configure.
Passing a partial object (e.g. only { ssr: true }) after Auth was already set up built { Auth: authLibraryOptions, ...libraryOptions } without ...Amplify.libraryOptions, so prior Storage (and other) options were omitted.

2. Default Cognito token provider keeps stale Auth config
   cognitoUserPoolsTokenProvider.setAuthConfig() was only called on the first Auth setup path. Later Amplify.configure calls that changed resourcesConfig.Auth (new user pool / client id, config-only reconfigure, or libraryOptions.Auth with the default provider) did not refresh the token provider.

TokenStore builds storage keys from authConfig.Cognito.userPoolClientId, so tokens can be read/written under old keys after the app reconfigures to a new pool.

Expected behavior

1. Each Amplify.configure from aws-amplify should merge new libraryOptions with existing Amplify.libraryOptions so category options (e.g. Storage) remain unless explicitly overridden.
2. When the default cognitoUserPoolsTokenProvider is in use, setAuthConfig should run whenever resourcesConfig.Auth changes on reconfigure, so token storage keys match the current Cognito client id.

Reproduction steps

Scenario - partial reconfigure drops Storage

-Install aws-amplify v6 and configure with Auth + Storage options: Amplify.configure(configA, { Storage: { S3: { defaultAccessLevel: 'private' } } }).
-Call Amplify.configure(configB, { ssr: true }) (or only { ssr: false }) with Auth still present in the resource config.
-Inspect Amplify.libraryOptions (or observe Storage using wrong/missing options).
-Actual: Storage is missing from singleton libraryOptions. Expected: Storage is preserved and ssr is applied.

Code Snippet

// Put your code below this line.
import { Amplify } from 'aws-amplify';

const poolA = {
  Auth: {
    Cognito: {
      userPoolId: 'us-east-1_poolA',
      userPoolClientId: 'client-a',
    },
  },
};

const poolB = {
  Auth: {
    Cognito: {
      userPoolId: 'us-east-1_poolB',
      userPoolClientId: 'client-b',
    },
  },
};

// 1) First configure with Storage
Amplify.configure(poolA, {
  Storage: {
    S3: { defaultAccessLevel: 'private' },
  },
});

// 2) Reconfigure — partial options (Scenario A)
Amplify.configure(poolB, { ssr: true });
// Bug: Amplify.libraryOptions.Storage may be undefined

// 3) Reconfigure — Auth options only (Scenario B)
Amplify.configure(poolB, {
  Auth: {
    // default cognitoUserPoolsTokenProvider from first configure
  },
});
// Bug: Storage dropped; setAuthConfig may not run for pool B (Scenario C)

Log output

Details

// Put your logs below this line
No runtime error or stack trace — incorrect singleton state (libraryOptions / token store keys).
Enable debug if needed: window.LOG_LEVEL = 'DEBUG';

aws-exports.js

No response

Manual configuration

import { Amplify } from 'aws-amplify';

const config = {
Auth: {
Cognito: {
userPoolId: 'us-east-1_XXXXXXX',
userPoolClientId: 'xxxxxxxxxxxxxxxxxxxxxxxxxx',
},
},
};

Amplify.configure(config, {
Storage: {
S3: {
bucket: 'my-bucket',
region: 'us-east-1',
},
},
});

// Later reconfigure (hot reload, env switch, SSR toggle)
Amplify.configure(updatedConfig, { ssr: true });

Additional configuration

{
"note": "Reproducible in Node/SSR (Next.js) and browser when configure runs more than once",
"affectedFile": "packages/aws-amplify/src/initSingleton.ts",
"coreBehavior": "@aws-amplify/core Amplify.configure replaces libraryOptions when a new object is passed"
}

Mobile Device

No response

Mobile Operating System

No response

Mobile Browser

No response

Mobile Browser Version

No response

Additional information and screenshots

--Pull request (fix + tests + changeset): #14819
--Related issues: #14816, #13707
--Related PR: #14815 (partial libraryOptions merge only)
--Labels suggestion: bug, Auth, Storage
--Screenshots: N/A (library/singleton behavior)

[ShrutiPundir17]

I have already worked on the solution for this issue
Please review below pr: #14819

[bobbor]

hey @ShrutiPundir17

thanks for reporting this issue. I think this is a bug too, but might not be possible to fix without a breaking change.

See this example:

// first configure
Amplify.configure({
  Auth: {
    Cognito: {
      userPoolId: 'us-east-1_poolA',
      userPoolClientId: 'client-a',
    },
  },
  API: {
    endpoint: "https://my-auth-website.com"
  }
}, {
  API: {
    REST: {
      headers: () => new Headers({ auth: `Bearer ${myToken}` })
    }
  }
});

// second configure
Amplify.configure({
  Auth: {
    Cognito: {
      userPoolId: 'us-east-1_poolB',
      userPoolClientId: 'client-b',
    },
  },
  API: {
    endpoint: "https://sketchy-anon-website-where-i-dont-want-tokens-to-leak.com"
  }
}, {
  Auth: {
    headers: () => new Headers({ `x-do-not-track`: true })
  }
})

the second configure - since it has Auth libraryOptions, would inherit the API libraryOptions (through Amplify.libraryOptions) from the first configure, potentially leaking sensitive information. sketchy-anon-website (which might not be that sketchy, but is used for e.g. weather information) would receive the JWT from the auth-API.

this is just an example and should not be considered to be applyable in the real-world. but the point stands, that currently reconfigures overwrite the libraryOptions, which is a design choice - maybe not the best - other users of the library expect to continue to work like this.

My question now:
I know it causes a bit of overhead, but you could track the libraryOptions in your application-code. is there a reason, you can not do this? or is it simply "nicer" if the libraryOptions get merged? - which I agree it is

[bobbor]

Let's discuss this in this issue. if we come to the conclusion that the PR makes sense, we can move forward with it.

[ShrutiPundir17]

Thanks @bobbor — that helps.

I want to keep #14820 / #14819 focused on one thing: refreshing the default Cognito token provider when resourcesConfig.Auth changes on reconfigure (cognitoUserPoolsTokenProvider.setAuthConfig()). TokenStore keys use userPoolClientId, so if that isn’t updated after a second configure, tokens can use stale keys (related to #13707).

Your JWT / API headers example is about merging libraryOptions across configure — I agree that’s risky and conflicts with core’s documented replace behavior. That’s not what I’m asking to land here; merge / partial options are tracked in #14815 / #14816.

On tracking in app code: apps can merge libraryOptions themselves before each configure, but they can’t call setAuthConfig on the default provider — that’s only wired inside initSingleton.

Proposal: I’ll update #14819 to be setAuthConfig on reconfigure only (remove ...Amplify.libraryOptions merge, retitle PR/changeset). Could you confirm if that scoped change is OK to merge on this issue?

[bobbor]

I want to keep #14820 / #14819 focused on one thing: refreshing the default Cognito token provider when resourcesConfig.Auth changes on reconfigure (cognitoUserPoolsTokenProvider.setAuthConfig()). TokenStore keys use userPoolClientId, so if that isn’t updated after a second configure, tokens can use stale keys (related to #13707).

I’ll update #14819 to be setAuthConfig on reconfigure only

sounds good, let's do this and I think we can be more radical.

let me explain what I mean:

// this is the current `Amplify.configure`
configure(
  resourceConfig: ResourcesConfig | LegacyConfig | AmplifyOutputsUnknown,
  libraryOptions?: LibraryOptions,
): void {
  const resolvedResourceConfig = parseAmplifyConfig(resourceConfig);
  const cookieBasedKeyValueStorage = new CookieStorage({ sameSite: 'lax' });

  /*
   * ssr specific configuration !!! this is important
   */
  const resolvedKeyValueStorage = libraryOptions?.ssr
      ? cookieBasedKeyValueStorage
      : defaultStorage;
  const resolvedCredentialsProvider = libraryOptions?.ssr
      ? new CognitoAWSCredentialsAndIdentityIdProvider(
          new DefaultIdentityIdStore(cookieBasedKeyValueStorage
        ),
      )
      : cognitoCredentialsProvider;

  // we don't care about configuration for anything apart from Auth
  // reconfigure is always set and destroy
  if (!resolvedResourceConfig.Auth || libraryOptions?.Auth) {
    Amplify.configure(resolvedResourceConfig, libraryOptions);
    return;
  }

  /*
   * let's always re-set the authConfig
   * no need to be smart about it. this enables reconfigure
   */
  // if (!Amplify.libraryOptions.Auth) {
    cognitoUserPoolsTokenProvider.setAuthConfig(resolvedResourceConfig.Auth);
    cognitoUserPoolsTokenProvider.setKeyValueStorage(
      // TODO: allow configure with a public interface
      resolvedKeyValueStorage,
    );

    Amplify.configure(resolvedResourceConfig, {
      ...libraryOptions,
      Auth: {
        tokenProvider: cognitoUserPoolsTokenProvider,
        credentialsProvider: resolvedCredentialsProvider,
      },
    });
    // }

    /*
     * here used to be logic, which reconfigured auth, but for SSR only.
     * someone noticed, that auth reconfiguration does not work properly
     * and SSR doesn't work with localStorage, so a fix was implemented.
     *
     * That is no longer needed, as we now always reconfigure Auth and
     * the resolvedKVStorage and resolvedCredentialsProvider are already SSR-aware
     */
}

so in the end, there is only few scenarios:

1. no auth config !resolvedResourceConfig.Auth || libraryOptions?.Auth // true
2. no auth config, but auth libOptions (why?) !resolvedResourceConfig.Auth || libraryOptions?.Auth // true
3. auth config, and auth libOptions !resolvedResourceConfig.Auth || libraryOptions?.Auth // true
4. auth config, but no auth libOptions !resolvedResourceConfig.Auth || libraryOptions?.Auth // false

so we only need to care about scenario no.4)

and for no 4 the singleton always gets a new ssr-aware authConfig for the providers. independent if it is the same or new provider(s).

---

It is very possible that I missed a scenario.
broader SSR scenarios / storage configuration / API headers etc.

But I think the biggest problem is to re-use existing token- and credentials provider.

let me know what you think.