Introduction

In Amplify, signing in and fetching tokens are related but not identical steps. The sign-in call tells you whether authentication succeeded and whether more steps are required. The actual tokens are typically read from the current auth session after sign-in completes.

The Modern Pattern

In current Amplify JavaScript usage, the usual flow is:

1. call signIn
2. inspect the returned next-step state
3. if the user is fully signed in, call fetchAuthSession
4. read the tokens from the session

1import { signIn, fetchAuthSession } from 'aws-amplify/auth';
2
3async function login(username, password) {
4  const result = await signIn({ username, password });
5
6  if (!result.isSignedIn) {
7    console.log('Next step:', result.nextStep);
8    return;
9  }
10
11  const session = await fetchAuthSession();
12  const accessToken = session.tokens?.accessToken?.toString();
13  const idToken = session.tokens?.idToken?.toString();
14
15  console.log(accessToken);
16  console.log(idToken);
17}

The key idea is that the sign-in result describes auth flow state, while the session object exposes the actual token set.

Why Tokens Are Not Always Returned Directly From Sign-In

Amplify auth flows can include more than one step:

• normal username and password sign-in
• password change challenge
• MFA confirmation
• new-password-required flow
• custom challenge flow

Because of that, the sign-in call cannot always just hand you final tokens immediately. Sometimes the user is not fully authenticated yet.

That is why the sign-in result includes state such as isSignedIn and nextStep. Tokens are meaningful only once the sign-in flow has actually finished.

Legacy Auth.signIn Code

Older Amplify examples often used the Auth namespace directly and then called Auth.currentSession() after a successful sign-in.

1import { Auth } from 'aws-amplify';
2
3async function loginLegacy(username, password) {
4  await Auth.signIn(username, password);
5  const session = await Auth.currentSession();
6
7  console.log(session.getAccessToken().getJwtToken());
8  console.log(session.getIdToken().getJwtToken());
9}

That pattern belongs to older Amplify APIs. If you are maintaining legacy code, it can still explain the examples you see online. For newer code, signIn plus fetchAuthSession is the clearer mental model.

Which Token Do You Actually Need

Amplify sessions can expose several token-related values. The most common ones are:

• access token for authorizing API calls
• ID token for identity claims
• refresh token handling managed by the auth session lifecycle

Do not treat them as interchangeable. If your backend expects a bearer token for an API request, that is usually the access token, not the ID token.

A Practical Usage Example

After sign-in, you might attach the access token to a request.

1const session = await fetchAuthSession();
2const accessToken = session.tokens?.accessToken?.toString();
3
4const response = await fetch('https://api.example.com/profile', {
5  headers: {
6    Authorization: `Bearer ${accessToken}`,
7  },
8});

This is a good example of why session access is a separate step. You often need the auth state in one place and the token later in another place.

Common Pitfalls

The most common mistake is assuming a successful signIn call always means tokens are ready immediately, even when the auth flow still has a next step.

Another mistake is mixing modern Amplify modular APIs with older Auth.currentSession() examples without realizing they are from different API styles.

A third pitfall is using the ID token when the backend really expects the access token.

Summary

• In Amplify, sign-in success and token retrieval are usually separate steps.
• For modern modular APIs, call signIn, then fetchAuthSession once isSignedIn is true.
• Legacy code often used Auth.signIn followed by Auth.currentSession().
• Tokens are available from the auth session, not always from the sign-in return value itself.
• Make sure you use the correct token type for the backend you are calling.