amplify-js: withSSRContext not updating auth information on server-side

For those who are using Next.js with SSR to authenticate if the user has access to a speciffic page. The solution is similar as @lifedup but without setting the credentials in each method.

In your _app.ts (if you are using typescript) configure the following aws credentials:

import Amplify, { withSSRContext } from 'aws-amplify';
// Imported from amplify pull
import awsconfig from '../aws-exports';

Amplify.configure({...awsconfig,ssr: true});

// Auth from SSR and not directly from aws-amplify
const { Auth } = withSSRContext();

Auth.configure({
  region: process.env.AUTH_REGION,
  userPoolId: process.env.AUTH_POOL,
  userPoolWebClientId: process.env.AUTH_POOL_CLIENT,
  mandatorySignIn: false,
  // Set this only if you wish to use cookies to storage otherwise ignore it
  cookieStorage: {
    domain: 'localhost',
    // Set true if is a domain with https. For localhost set it to false
    secure: false,
    path: '/',
    expires: 2,
  },
})

In your index.ts or any other page that you would like to verify authentication:

import { withSSRContext } from "aws-amplify";

// Function that handles redirect for the user. You can isolate it in a /utils folder to re-use it in all your pages.
export async function authenticatedUsers(context) {
  const { Auth } = withSSRContext(context);
  try {
    await Auth.currentAuthenticatedUser();
  } catch (error) {
    console.log(error)
    return true
  }
  return false
}

export const getServerSideProps: GetServerSideProps = async (ctx) => {
  let shouldRedirect = await authenticatedUsers(ctx);
  if (shouldRedirect) {
    return {
      redirect: {
        destination: '/login',
        permanent: false
      }
    }
  }
  return {
    props: {}
  }
}

I was able to reproduce this today. As of now redirecting client side should be the best work around for this. This is caused by the way Amplify loads cookies inside the browser, and how it can detect if a user is logged in or not.

Amplify must load at least once client side after being redirected from a federated login before getServerSideProps can detect if the user is logged in or not.

To make this faster, make sure the route is completely empty, and all it does is redirect.

@chrisbonifacio

The bug occurs because the username contains @ but in cookies the @ becomes %40, on the following line the username contains @ instead of %40 https://github.com/aws-amplify/amplify-js/blob/main/packages/amazon-cognito-identity-js/src/CognitoUser.js#L1388

I guess the encodeURIComponent solve the problem

@tobiastimm Are you or anyone else still blocked on this issue? The cause of the issue can be different for each person but there have been some comments noting proper usage of withSSRContext, some gotchas like when it comes to oauth that require Amplify to be able to finish the oauth flow which can be interrupted by server side redirects (workaround being client side redirect after signin is confirmed).

I believe I am also experiencing this issue, or a similar one. Our Cognito is configured to use two styles of login, a federated login through my company’s SSO, and Cognito defined users I can log in to directly. -With the users internal to Cognito using withSSRContext() works as expected -With federated users authenticated by our SSO withSSRContext() never recognizes the logged in user. currentAuthenticatedUser() always throws the unauthenticated exception.

Yup exactly, @bmkennedy-hcg you hit the nail on the head. This is the common scenario we are also encountering. For us, on initial sing-in redirect there is no authenticated user. So what we do is we fallback/redirect to a callback page route, which loads amplify client side, which then performs another client side redirect, and then and only then is the user authenticated.

It’s a lame workaround but it works. Since the initial sign-in redirect from cognito contains the code and state, I figured I could use the oAuthClient exported by the server, however the client the server uses, actually rely’s on window object. So go figure…

Thanks, @voigtito. Like you mentioned, I was able to get withSSRContext to work once I configured Auth inside of getServerSideProps. My code now looks like this:

export const getServerSideProps: GetServerSideProps<Props> = async ({
  params,
  req,
}) => {
  const { Auth } = withSSRContext({ req });
  Auth.configure({...config});

  try {
    const user = await Auth.currentAuthenticatedUser();
    ....
  } catch (error) {
    ....
  }
}

None of the docs mentioned that it is necessary to configure the Auth object returned by withSSRContext. Here is an example: https://aws.amazon.com/blogs/mobile/ssr-support-for-aws-amplify-javascript-libraries/

Hi 👋 Closing this as we have not heard back from you. If you are still experiencing this issue and in need of assistance, please feel free to open a new issue and fill out as much info in the bug report form as you can provide.

Thank you!

@bezreyhan if you configure the Amplify or Auth just once in your _app.tsx it should work! If you configure it only in your index.tsx it wont work properly.

In a next.js application if you create the _app.tsx file inside /pages folder your next.js will always look at first. So this is the file where you need to configure your Amplify.

Here is an example of the _app.tsx file:

import dotenv from 'dotenv';
import { AppProps } from 'next/app';
import Amplify from 'aws-amplify';
import awsconfig from '../aws-exports';
import '../styles/global.css';

dotenv.config();

Amplify.configure({...awsconfig,ssr: true});
// Auth from SSR and not directly from aws-amplify
const { Auth } = withSSRContext();

Auth.configure({
  region: process.env.AUTH_REGION,
  userPoolId: process.env.AUTH_POOL,
  userPoolWebClientId: process.env.AUTH_POOL_CLIENT,
  mandatorySignIn: false,
  // Set this only if you wish to use cookies to storage otherwise ignore it
  cookieStorage: {
    domain: 'localhost',
    // Set true if is a domain with https. For localhost set it to false
    secure: false,
    path: '/',
    expires: 2,
  },
})

const MyApp = ({ Component, pageProps }: AppProps) => {
  return (
     <Component {...pageProps} />
  )
}

export default MyApp

After setting this you can use Auth inside your getServerSideProps properly.