bumping on this issue, @nadetastic would you know of any workaround in the meantime to allow idToken use from server side graphql API calls?

so far, my workaround has been:

const idToken = cookies()
    .getAll()
    .filter(
        cookie => cookie.name.includes("CognitoIdentityServiceProvider") && cookie.name.includes("idToken")
    )?.[0]?.value;

export const serverClient = generateServerClientUsingCookies({
    config: awsConfig,
    cookies,
    ...(idToken
        ? { authMode: GRAPHQL_AUTH_MODE.AMAZON_COGNITO_USER_POOLS, authToken: idToken }
        : {
              authMode: GRAPHQL_AUTH_MODE.AWS_IAM,
          }),
}) as V6ClientSSRCookies;

but this seems pretty messy :)

So my previous workaround didn't end up working, but I was able to just use a patch file to just switch the token thats passed from the graphql call to just use idToken.

diff --git a/node_modules/@aws-amplify/api-graphql/dist/esm/internals/InternalGraphQLAPI.mjs b/node_modules/@aws-amplify/api-graphql/dist/esm/internals/InternalGraphQLAPI.mjs
index 3f1a5f7..b676d26 100644
--- a/node_modules/@aws-amplify/api-graphql/dist/esm/internals/InternalGraphQLAPI.mjs
+++ b/node_modules/@aws-amplify/api-graphql/dist/esm/internals/InternalGraphQLAPI.mjs
@@ -58,7 +58,7 @@ class InternalGraphQLAPIClass {
             case 'userPool':
                 try {
                     let token;
-                    token = (await amplify.Auth.fetchAuthSession()).tokens?.accessToken.toString();
+                    token = (await amplify.Auth.fetchAuthSession()).tokens?.idToken.toString();
                     if (!token) {
                         throw new Error(GraphQLAuthError.NO_FEDERATED_JWT);
                     }
@@ -67,7 +67,7 @@ class InternalGraphQLAPIClass {
                     };
                 }
                 catch (e) {
-                    throw new Error(GraphQLAuthError.NO_CURRENT_USER);
+                    // pass, call with no authorization header
                 }
                 break;
             case 'lambda':

using patch-package for anyone who runs into the same issue. The second part of this code (removing the throw new Error...) allows it to fallback to IAM if the user is not set, while maintaing the default auth mode of userPool (#12931). @johnf I saw you commented there with this issue, so maybe doing this patch for now will be helpful.

Hi @asp3,

Thank you for opening this issue, and for your patience. I see you would like to set an Authorization header at the config level for to be used with your GraphQL requests. To achieve this, you should consider injecting the authorization token with each api call through client.graphql() instead since the server context is being injected on each API call. Here is an example:

await runWithAmplifyServerContext({
	nextServerContext: { cookies },
	operation: async (contextSpec) => {
		return client.graphql(
			contextSpec,
			{
				query: listTodos,
			},
			{
				// `Authorization` also works here
	            authToken: ( await fetchAuthSession(contextSpec) ).tokens?.idToken?.toString() as string, 
			}
		);
	},
});

Additionally, I saw your contribution at #12979 and are reviewing it with the team - I will follow up on that PR shortly. In the meantime, let me know if you have any additional questions regarding this issue.

Hi @nadetastic, thanks for the reply! Doing it this way also works, but I am now running into the issue of TooManyRequestsException (I assume from fetchAuthSession). Since this token is already available in cookies, it seems like overkill to fetch the full auth session each time (#12839). Any ideas on what I can do to be unblocked here? We need the id token from each server side call, and we definitely make a few hundred within 10-15 seconds regularly.

@nadetastic this is a p big blocking issue since it leads to 404s on certain pages. any workaround you would know of? Thanks in advance :)

Hi @asp3, after reading through #12839 it seems the options you have are:

1. offload some of your requests to the client side which can take advantage of caching the credentials
2. create a custom server action wrapper that can batch and run multiple operations in the same server context so credentials are only fetched once
3. create and use a custom graphql mutation that batches the DynamoDB operations

Have you explored these options?

I had the same issue, to solve it I started calling fetchAuthSession every time, but then I started receiving the TooManyRequestsException exception. So I started calling fetchAuthSession only when the token was expired.

import { cookies } from "next/headers";

import { createServerRunner } from "@aws-amplify/adapter-nextjs";
import { generateServerClientUsingCookies } from "@aws-amplify/adapter-nextjs/api";
import { getIdToken, getToken } from "@company/ui/lib";
import { fetchAuthSession } from "aws-amplify/auth/server";

import { awsConfig } from "../aws-exports";

export const { runWithAmplifyServerContext } = createServerRunner({
  config: awsConfig,
});

export const getServerClient = async () => {
  const idToken = cookies()
    .getAll()
    .filter(
        cookie => cookie.name.includes("CognitoIdentityServiceProvider") && cookie.name.includes("idToken")
    )?.[0]?.value;

  const token = await runWithAmplifyServerContext({
    nextServerContext: { cookies },
    operation: async (contextSpec) => {
      try {
        const parsedToken = jwtDecode(idToken);
        const isExpired =
          parsedToken?.exp && parsedToken.exp * 1000 < Date.now();

        if (!isExpired) return idToken;

        const session = await fetchAuthSession(contextSpec);
        return session.tokens.idToken.toString();
      } catch (error) {
        return false;
      }
    },
  });

  return generateServerClientUsingCookies({
    config: awsConfig,
    cookies,
    authMode: "userPool",
    authToken: token,
  });
};

@willianrod thanks for the idea, did something very similar!

const getServerAuth = async (): Promise<Pick<ServerClientWithCookies, "auth">> => {
    const cookieStore = cookies();

    let idToken = cookieStore
        .getAll()
        .filter(
            cookie => cookie.name.includes("CognitoIdentityServiceProvider") && cookie.name.includes("idToken")
        )?.[0]?.value;

    if (!idToken) {
        return {
            auth: {
                authMode: GRAPHQL_AUTH_MODE.AWS_IAM,
            },
        };
    }

    const parsedToken = jwtDecode(idToken);
    const isExpired = parsedToken.exp && parsedToken.exp + TOKEN_BUFFER <= now();

    if (isExpired) {
        // refresh the token
        const currentUser = await runWithAmplifyServerContext({
            nextServerContext: { cookies },
            operation: contextSpec =>
                fetchAuthSession(contextSpec, {
                    forceRefresh: true,
                }),
        });

        if (!currentUser.tokens?.idToken) {
            return {
                auth: {
                    authMode: GRAPHQL_AUTH_MODE.AWS_IAM,
                },
            };
        }

        idToken = currentUser.tokens.idToken.toString();
    }

    return {
        auth: {
            authMode: GRAPHQL_AUTH_MODE.AMAZON_COGNITO_USER_POOLS,
            authToken: idToken,
        },
    };
};

However, I do think that this is something that should be fixed from Amplify's side. Having to fetch the token on every call is very inefficient, especially in a world where more and more things are being rendered on the server.

Thank you for sharing your workaround, @willianrod, and helping to unblock @asp3.
Marking this as a feature request to discuss with the team.

hey @chrisbonifacio @willianrod, running into an interesting issue, even after setting up the propsed solution above.

From what I can see, there are still call made to Congito IDP each for every single request, even though all authenitcation information has been passed into the graphql call. any ideas on why this would be happening?

I verified that this was the path of a request where the id token is not expired, so before the graphql call, no calls to fetchAuthSession were made from my end!

@asp3 @chrisbonifacio

Not sure if that is what is happening for you but when I was migrating from v5 to v6 I couldn't find anywhere in the docs mentioning the headers for graphql calls, so my guess is you may not be explicitly passing the auth headers and graphql client is doing some requests under the hood to get a new token every time.

When using Amplify.configure you can pass a second parameter with some API configs, and I did the same thing there by checking if the token is expired and then try to get a new one if expired. (I found it by digging the source code)

Here's a sample code

Amplify.configure(awsConfig, {
  ssr: true,
  API: {
    GraphQL: {
      headers: async () => {
        return {
          Authorization: getAuthToken(),
        };
      },
    },
  },
});

export default function AmplifyProvider({
  children,
}: React.PropsWithChildren) {
  return <>{children}</>;
}