Introduction

In current Amplify JavaScript apps, the reliable way to check whether a user is signed in is to ask Amplify Auth directly rather than trusting a UI flag. The two most useful APIs are getCurrentUser(), which tells you whether an authenticated user is available, and fetchAuthSession(), which tells you whether the current session has usable tokens.

Use getCurrentUser() for a Simple Signed-In Check

If your application just needs to know whether a user is currently authenticated, getCurrentUser() is the direct check. It returns user information when the session is present and throws if the user is not authenticated.

1import { getCurrentUser } from "aws-amplify/auth";
2
3export async function isLoggedIn() {
4  try {
5    const { username, userId } = await getCurrentUser();
6    console.log("Signed in as", username, userId);
7    return true;
8  } catch {
9    return false;
10  }
11}

This is a good fit for route guards, app bootstrap logic, or any UI decision that only depends on whether a signed-in user exists.

Use fetchAuthSession() When Session Details Matter

Sometimes user presence is not enough. You may need to know whether the current session contains valid tokens for API calls. In that case, fetchAuthSession() is the more informative check.

1import { fetchAuthSession } from "aws-amplify/auth";
2
3export async function hasValidSession() {
4  const session = await fetchAuthSession();
5  return session.tokens != null;
6}

Amplify can also refresh an expired session automatically when a valid refresh token exists. That is why fetchAuthSession() is often the right call when your application is about to make an authenticated network request.

The two checks answer slightly different questions:

• 'getCurrentUser() asks whether Amplify can identify an authenticated user.'
• 'fetchAuthSession() asks whether the current session has the auth material needed for access.'

In many apps either one is enough, but it helps to be explicit about which question you are actually asking.

Run the Check After Amplify Is Ready

A common source of confusion is timing. If your app uses redirect-based sign-in or Hosted UI, you need to let Amplify finish restoring the session before checking auth state. Running the check too early can make the app briefly believe the user is signed out.

Here is a simple startup pattern:

1import { getCurrentUser } from "aws-amplify/auth";
2
3export async function bootstrapAuthState() {
4  try {
5    const user = await getCurrentUser();
6    return { signedIn: true, user };
7  } catch {
8    return { signedIn: false, user: null };
9  }
10}
11
12bootstrapAuthState().then((state) => {
13  if (state.signedIn) {
14    console.log("Render the protected app");
15  } else {
16    console.log("Show the sign-in flow");
17  }
18});

That is much safer than setting a boolean during sign-in and assuming it remains correct forever. Page reloads, token expiry, and external sign-out flows can all invalidate local UI assumptions.

Treat Amplify as the Source of Truth

The robust pattern is:

• Sign in and sign out through Amplify Auth
• On app load, ask Amplify for current user or session state
• Store that result in your application state
• Recheck when entering protected routes or before authenticated API calls if needed

That keeps the interface aligned with the actual authentication provider rather than a stale in-memory flag. The official session guidance also notes that getCurrentUser() can be used as a sign-in check and that fetchAuthSession() is the right place to inspect tokens and refresh behavior.

Common Pitfalls

The most common mistake is relying only on a local isLoggedIn flag set during sign-in. That flag does not automatically stay accurate across reloads or session changes.

Another issue is treating user presence and valid session tokens as the same thing. They are related, but fetchAuthSession() is the better check when token availability matters.

Redirect flows introduce timing bugs if you query auth state before Amplify has completed session restoration. In Hosted UI scenarios, be especially careful about initialization order.

Summary

• In current Amplify JavaScript code, getCurrentUser() is the simplest way to check whether a user is signed in.
• 'fetchAuthSession() is the better choice when you need to know whether valid tokens are available.'
• Do not trust a local UI boolean as the long-term source of truth for authentication.
• Run auth checks after Amplify initialization and redirect restoration are complete.
• Let Amplify Auth, not component state alone, define the signed-in state of the app.