certain users are getting auto logged out on production workloads

[asp3]

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

GraphQL API, Authentication

Amplify Version

v6

Amplify Categories

auth, api

Backend

Other

Environment information

  System:
    OS: macOS 15.4.1
    CPU: (16) arm64 Apple M4 Max
    Memory: 12.90 GB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.14.0 - ~/.nvm/versions/node/v22.14.0/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 10.9.2 - ~/.nvm/versions/node/v22.14.0/bin/npm
    Watchman: 2024.01.22.00 - /usr/local/bin/watchman
  Browsers:
    Brave Browser: 114.1.52.130
    Chrome: 135.0.7049.115
    Safari: 18.4
  npmPackages:
    @biomejs/biome: 1.9.4 => 1.9.4 
    @knowt/tsconfig: * => 0.0.0 
    dotenv-cli: latest => 8.0.0 
    husky: ^8.0.0 => 8.0.3 
    lint-staged: ^12.4.0 => 12.5.0 
    turbo: ^1.10.12 => 1.13.4 
  npmGlobalPackages:
    @aws-amplify/cli: 12.14.4
    corepack: 0.31.0
    eas-cli: 16.1.0
    npm: 10.9.2
    vercel: 41.5.0

Describe the bug

We have been long time users of amplify, and it is currently supporting our production workload of 2M+ MAU. Overall, this is a fantastic library and has saved us thousands of hours of writing our own implementation.

We've made our own patches to this for some of our use cases, but I can't seem to figure out why some issues have been happening recently. We have a massive spike in users in the last week, and these problems have started around this time.

To rule out some other things:
Our UserAuthentication requests utilization % is well below the quota, so its not that we are reaching the 120RPS.

From my understanding, I believe the root cause of this is that cognito-identity network call still made even when custom Authorization is passed in

Currently, our setup is as follows:

const getCognitoAuthToken = async () => {
    const cookieMap = Cookies.get();
    const cookies = Object.keys(cookieMap).map(key => ({
        name: key,
        value: cookieMap[key],
    }));

    let idToken = cookies.filter(
        cookie =>
            cookie.name.includes("CognitoIdentityServiceProvider") &&
            cookie.name.includes("idToken") &&
            // on dev, since we switch between dev and prod a lot, we need to make sure we're using the right token
            cookie.name.includes(USERPOOL_CLIENT_ID)
    )?.[0]?.value;

    if (!idToken) {
        return {};
    }

    const parsedToken = jwtDecode(idToken);
    const isExpired = parsedToken.exp && parsedToken.exp + TOKEN_BUFFER <= now();
    try {
        if (isExpired) {
            // get the new token
            idToken = (await fetchAuthSession()).tokens?.idToken?.toString();
        }

        return {
            Authorization: idToken,
        };
    } catch {
        return {};
    }
};

export const amplifyAuthOverride = {
    API: {
        GraphQL: {
            headers: async () => await getCognitoAuthToken(),
        },
    },
};

We noticed some slight differences needed in api-graphql/src/internals/InternalGraphQLAPI.ts, where we made the necessary changes to make sure the fetchAuthSession call here was not made either.

Line 236

if (typeof customHeaders === 'function') {
			customLibraryHeaders = await customHeaders(body) as Record<string, string>
		} else {
			customLibraryHeaders = {}
		}

		// if an authorization header is set, have the explicit authToken take precedence
		if (authToken) {
			additionalCustomHeaders = {
				...additionalCustomHeaders,
				Authorization: authToken,
			};
		}

		const authHeaders = await headerBasedAuth(
			amplify,
			authMode,
			apiKeyOverride ?? apiKey,
			{ ...additionalCustomHeaders, ...customLibraryHeaders },
		);

Along with the changes in headerBasedAuth:

case 'userPool': {
			if (additionalHeaders.Authorization) {
				break;
			}

			let token: string | undefined;

			try {
				token = (
					await amplify.Auth.fetchAuthSession()
				).tokens?.idToken?.toString();
			} catch (e) {
				// pass, call with no authorization header
			}
			if (token) {
				headers = {
					Authorization: token,
				};
			}

			break;
		}

Now, we would expect that the call to fetchAuthSession would be removed. However, we noticed in the network tab that the requests to https://cognito-identity.us-east-1.amazonaws.com are still made!

https://share.cleanshot.com/zQwxfV9n

Here you can see that there were 10 requests to cognito-identity, but 5 GraphQL API calls were made. I added console logs to make sure neither of the fetchAuthSession calls were made, but it seems like its getting called from somewhere else.

I don't expect this to be fixed in the main package, but if you could point me to where in the code this call is made from, that would help quite a bit as well!

I also guess that when the rate limit error happens, it automatically logs the user out and clears all the values from local storage. Is there a way to stop this behavior, and keep those values so that when the user reloads, they are still logged in? Some users are reporting that they are getting logged out every 5-10 minutes, which is not ideal.

We look forward to being able to patch these issues!

Expected behavior

When Authorization is explicitly passed, we should not be making calls to cognito-identify. Again, I'm not fully sure if this is what is causing it, but I assume this is the reason why they are getting logged out.

As per AWS Docs, there is a 10 request/user/second rate limit on these requests, and when making multiple API calls, this limit may get hit.

Reproduction steps

1. copy the snippet above, and configure amplify with custom overrides.
2. make a graphql call, and notice that cognito-identity calls are still made.

Code Snippet

// Put your code below this line.

Log output

// Put your logs below this line

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

[asp3]

commenting out

amplify-js/packages/core/src/singleton/Auth/index.ts

Line 57 in 5c85092

await this.authOptions?.credentialsProvider?.getCredentialsAndIdentityId(

and removing the return for credentials/identityId from this API still led to my app working properly, and no longer has the network calls.

Obviously not pushing that to production, but just wondering what the use case of that function is, especially if its not used downstream by us (or, anything useful to us in the amplify package, i guess)

[asp3]

Here is an example of one of the rate errors that users are running into.

Request URL:
https://cognito-identity.us-east-1.amazonaws.com/
Request Method:
POST
Status Code:
400 Bad Request
Remote Address:
[2600:1f10:469b:a102:5f14:40c4:72e0:9de8]:443
Referrer Policy:
strict-origin-when-cross-origin
access-control-allow-origin:
*
access-control-expose-headers:
x-amzn-RequestId,x-amzn-ErrorType,x-amzn-ErrorMessage,Date
content-length:
63
content-type:
application/x-amz-json-1.1
date:
Thu, 01 May 2025 01:06:38 GMT
strict-transport-security:
max-age=31536000; includeSubDomains
x-amzn-errormessage:
Rate exceeded
x-amzn-errortype:
TooManyRequestsException:
x-amzn-requestid:
535728e7-65c9-4df9-95de-905648c2e082
:authority:
cognito-identity.us-east-1.amazonaws.com
:method:
POST
:path:
/
:scheme:
https
accept:
*/*
accept-encoding:
gzip, deflate, br, zstd
accept-language:
en-US,en;q=0.9,es;q=0.8
cache-control:
no-store
content-length:
1786
content-type:
application/x-amz-json-1.1
origin:
-
priority:
u=1, i
referer:
-
sec-ch-ua:
"Google Chrome";v="135", "Not-A.Brand";v="8", "Chromium";v="135"
sec-ch-ua-mobile:
?0
sec-ch-ua-platform:
"macOS"
sec-fetch-dest:
empty
sec-fetch-mode:
cors
sec-fetch-site:
cross-site
user-agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
x-amz-target:
AWSCognitoIdentityService.GetId
x-amz-user-agent:
aws-amplify/6.13.2 framework/2

[ashika112]

Hi thanks for opening the issue and detailed information. We really appreciate it. There are 2 parts involved here,

• If you are not using identityPool for anything, you can go ahead and disable it but removing the identityPool from the configuration. This should help eliminate any getCredentialsAndIdentityId currently it is coupled together when our API calls are made. getCredentialsAndIdentityId are made to get credentials based on IAM auth roles set in cognito identity pool.
• With respect to the custom header, unfortunately amplify-data makes authorization calls despite the header and we have a ticket internally to decouple that. So the patch code you have for that makes sense and you can definitely do that.

[asp3]

@ashika112 Thanks for the reply!

I believe we do use identityPool for unauthenticated requests, since its made through AWS_IAM. So the identity pool is used when making guest requests to AppSync.

But there is no need to call this when we are using authMode: USERPOOL (which is 99% of our use case), so I was wondering if I could maybe add some patch code to remove those calls only in that scenario. Unfortunately, the getCredentialsAndIdentityId call is far downstream from the graphql() call from InternalGraphQLAPI.ts (since all the calls to fetchAuthSession have been removed from the graphql API with our patches, it seems to be making it from somewhere else), so from my understanding, I don't see a way only to disable it for authenticated requests that we send.

I know you said its coming from amplify-data package, do you know where in that file I could patch something to disable these calls only when the auth mode matches what we are looking for?

Do you have any guidance on what we can do there?

[ashika112]

@asp3 You have tracked an patched all fetchAuthSession calls already? Only way getCredentialsAndIdentityId can be called is from fetchAuthSession in our code base. It looks to me somewhere this is missed i would try to pinpoint that.