Next.js Amplify v6 Server side Authorization header issue

[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

Amplify Version

v6

Amplify Categories

auth, api

Backend

Amplify CLI

Environment information

  System:
    OS: macOS 14.0
    CPU: (12) arm64 Apple M2 Max
    Memory: 64.38 MB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.6.1 - ~/.nvm/versions/node/v20.6.1/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 9.8.1 - ~/.nvm/versions/node/v20.6.1/bin/npm
    Watchman: 2023.10.23.00 - /usr/local/bin/watchman
  Browsers:
    Brave Browser: 114.1.52.130
    Chrome: 121.0.6167.139
    Safari: 17.0
  npmPackages:
    @knowt/eslint-config: * => 0.0.0 
    dotenv-cli: latest => 7.3.0 
    husky: ^8.0.0 => 8.0.3 
    lint-staged: ^12.4.0 => 12.5.0 
    prettier: ^2.7.1 => 2.8.8 
    turbo: ^1.10.12 => 1.10.16 
  npmGlobalPackages:
    amplify: 0.0.11
    appcenter-cli: 2.14.0
    corepack: 0.19.0
    eas-cli: 5.4.0
    eslint: 8.56.0
    expo-cli: 6.3.10
    npm-check: 6.0.1
    npm: 9.8.1

Describe the bug

On client side, I am able to make all calls as expected, by passing an id token in the header.

Amplify.configure(awsConfig, {
    ssr: true,
    API: {
        GraphQL: {
            headers: async () => ({
                Authorization: (await fetchAuthSession()).tokens?.idToken?.toString(),
            }),
        },
    },
});

export const serverClient = generateServerClientUsingCookies({
    config: awsConfig,
    cookies,
});

however, on server side, we are not allowed to override the headers from this function, so there is no way to use the id token!

I saw a few threads (#12699) but it seems unnecessarily complex where we have to wrap every call in runWithAmplifyServerContextCore, rather than just use the idToken already readily available in the cookies. Wondering if there was any fix for that!

Expected behavior

Expected server side calls are also made with the proper ID token claims. Currently, it seems to be making it with the access token, with no way to override.

Reproduction steps

1. setup next.js app with client and server side, using id token claims override
2. observe that client calls work properly, but server calls do not.

Code Snippet

No response

Log output

No response

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]

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

[asp3]

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 :)

[asp3]

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.

[nadetastic]

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.