Social Sign-In with AWS Amplify Gen 2 and React Native (Google, Facebook, Amazon)

Social sign-in lets people use an account they already have (Google, Facebook, Amazon, Apple) instead of creating a new password for your app. With AWS Amplify, the identity providers are wired into an Amazon Cognito user pool, and your React Native app starts the flow with a single function call. This guide walks through the current way to do it with Amplify Gen 2.

Updated October 2026: I rewrote this March 2024 post. It was built on the Amplify Gen 1 command-line workflow (amplify add auth, aws-exports.js) and on UI components (AmplifyAuthenticator, AmplifySignIn) that no longer exist in the current libraries. Amplify’s own maintenance notice says Gen 1 backends get only critical fixes and security patches from May 1, 2026 and reach end of life on May 1, 2027, so new projects should start on Gen 2. If you are on Gen 1, AWS has a migration guide.

How Social Sign-In Works With Amplify

1. Your app calls signInWithRedirect({ provider: 'Google' }).
2. Amplify opens the Cognito hosted sign-in endpoint in a secure in-app browser session, which sends the user to the provider (Google, for example).
3. The user signs in and approves access at the provider.
4. The provider redirects back to Cognito at https://<your-user-pool-domain>/oauth2/idpresponse.
5. Cognito creates or finds the user and redirects to your app’s deep link (for example myapp://callback/), and Amplify stores the session tokens.

Two addresses matter and are often confused. The provider-side redirect URI is always Cognito’s /oauth2/idpresponse address and is entered in the Google, Facebook or Amazon console. The app-side callback URL is your own deep link and is entered in your Amplify backend definition.

Prerequisites

• A React Native project (Expo with a development build, or the React Native CLI). Federated sign-in uses a native module, so it will not work in Expo Go.
• Node.js and an AWS account with credentials configured locally.
• A developer account with each provider you want to use. Apple’s Sign in with Apple requires a paid Apple Developer Program membership.
• A custom URL scheme for your app (for example myapp) registered on iOS and Android so the browser can hand control back to the app.

Step 1: Install the Packages

Per the Amplify React Native setup guide, install the Amplify libraries, the UI library and the supporting native packages. The last one is needed for federated sign-in:

npm add \
  aws-amplify \
  @aws-amplify/react-native \
  @aws-amplify/ui-react-native \
  @react-native-community/netinfo \
  @react-native-async-storage/async-storage \
  react-native-safe-area-context \
  react-native-get-random-values \
  @aws-amplify/rtn-web-browser

npm add -D @aws-amplify/backend @aws-amplify/backend-cli typescript

On iOS, run npx pod-install. With Expo, run npx expo prebuild to generate the native projects. The setup guide lists a specific version range for react-native-safe-area-context on React Native 0.74 and below, so check it against your React Native version.

Step 2: Define Authentication in Your Backend

In Gen 2 the backend is TypeScript code in your repository. Create amplify/auth/resource.ts:

import { defineAuth, secret } from '@aws-amplify/backend';

export const auth = defineAuth({
  loginWith: {
    email: true,
    externalProviders: {
      google: {
        clientId: secret('GOOGLE_CLIENT_ID'),
        clientSecret: secret('GOOGLE_CLIENT_SECRET'),
        scopes: ['email', 'profile'],
      },
      facebook: {
        clientId: secret('FACEBOOK_CLIENT_ID'),
        clientSecret: secret('FACEBOOK_CLIENT_SECRET'),
      },
      loginWithAmazon: {
        clientId: secret('LOGINWITHAMAZON_CLIENT_ID'),
        clientSecret: secret('LOGINWITHAMAZON_CLIENT_SECRET'),
      },
      callbackUrls: ['myapp://callback/'],
      logoutUrls: ['myapp://signout/'],
    },
  },
});

// amplify/backend.ts
import { defineBackend } from '@aws-amplify/backend';
import { auth } from './auth/resource';

defineBackend({ auth });

• secret() reads provider credentials from Amplify’s secret store instead of your source code. Never commit a client secret.
• callbackUrls and logoutUrls must match your app’s deep-link scheme exactly, including the trailing slash.
• You can leave out any provider you do not need. Sign in with Apple uses a different set of secrets (client ID, key ID, private key and team ID), listed in the Amplify external providers guide.
• I type-checked this file and backend.ts against @aws-amplify/backend 1.25.1. I did not deploy it, because that needs your AWS account and real provider credentials.

Step 3: Register Your App With Each Provider

The detailed screens in each console change often, so follow each provider’s current documentation: Google, Facebook and Login with Amazon. What stays constant, per the Amplify guide:

Provider	What to create	Where the Cognito address goes
Google	An OAuth client of type Web application	Authorized redirect URIs (and your user pool domain under authorized JavaScript origins)
Facebook	A Facebook app with Facebook Login enabled	Valid OAuth Redirect URIs
Login with Amazon	A security profile	Allowed Return URLs under Web Settings

In all three the address has the form https://<your-user-pool-domain>/oauth2/idpresponse. You get the real domain after your first deploy (it is the domain value under auth.oauth in the generated amplify_outputs.json), so the usual order is: deploy once, copy the domain, finish the provider setup, then store the secrets and redeploy. Request the minimum scopes you need (email and profile are enough for sign-in).

Store the secrets

For a personal cloud sandbox, set each secret from the command line; for a branch deployed through Amplify Hosting, set the same names in the Amplify console, as the external providers guide describes:

npx ampx sandbox secret set GOOGLE_CLIENT_ID
npx ampx sandbox secret set GOOGLE_CLIENT_SECRET
npx ampx sandbox secret set FACEBOOK_CLIENT_ID
npx ampx sandbox secret set FACEBOOK_CLIENT_SECRET
npx ampx sandbox secret set LOGINWITHAMAZON_CLIENT_ID
npx ampx sandbox secret set LOGINWITHAMAZON_CLIENT_SECRET

Deploy the sandbox

npx ampx sandbox

This deploys a personal backend and writes amplify_outputs.json to your project. That file contains the configuration your app needs, not your secrets.

Step 4: Register the Deep Link in Your App

The scheme in callbackUrls must be registered in the native app, or the user will finish signing in and never return to your app. In an Expo project, add a scheme to app.json:

{
  "expo": {
    "scheme": "myapp"
  }
}

Then run npx expo prebuild again. In a React Native CLI project, register the scheme in the iOS Info.plist and the Android manifest as described in React Native’s deep linking documentation. The Amplify docs add one iOS-specific rule: a redirect URL that does not start with http or https must be in your configured list, because iOS needs an app scheme to create the web session. That is why myapp://callback/ belongs in both callbackUrls and logoutUrls.

Step 5: Configure Amplify and Add Sign-In to the App

Configure Amplify once at the top of your entry file. The react-native-get-random-values import must come first, because Amplify’s crypto code relies on it:

import 'react-native-get-random-values';
import { Amplify } from 'aws-amplify';
import outputs from './amplify_outputs.json';

Amplify.configure(outputs);

Option A: The Authenticator component

The React Native Authenticator is a ready-made sign-in and sign-up flow. Its docs say federated sign-in is supported through the @aws-amplify/rtn-web-browser package you installed, and Amplify’s external-provider guide says social buttons work with the Authenticator without extra code. I could not run it on a device to confirm which buttons it renders, so if you need a particular layout, use Option B.

import { Authenticator } from '@aws-amplify/ui-react-native';

export default function App() {
  return (
    <Authenticator.Provider>
      <Authenticator>
        <YourApp />
      </Authenticator>
    </Authenticator.Provider>
  );
}

Option B: Your own buttons

For full control over the look of the sign-in screen, call signInWithRedirect yourself. This helper file type-checks against aws-amplify 6.22.1:

import { signInWithRedirect, signOut, getCurrentUser, fetchUserAttributes } from 'aws-amplify/auth';
import { Hub } from 'aws-amplify/utils';

export const signInWith = (provider: 'Google' | 'Facebook' | 'Amazon') =>
  signInWithRedirect({ provider });

export async function loadUser() {
  const { userId } = await getCurrentUser();
  const attrs = await fetchUserAttributes();
  return { userId, email: attrs.email };
}

export const listen = () => Hub.listen('auth', ({ payload }) => {
  if (payload.event === 'signInWithRedirect') console.log('signed in');
  if (payload.event === 'signInWithRedirect_failure') console.log('failed', payload.data);
});
export { signOut };

Wire signInWith('Google') to a button’s onPress. Note that the Amazon provider is named 'Amazon' in the client call even though the backend key is loginWithAmazon; the TypeScript compiler catches mistakes here, which is a good reason to use TypeScript. Apple uses 'Apple'. The Hub listener reports success and failure events so you can update your UI or show an error message when the user cancels.

Step 6: Test the Whole Flow

1. Run a development build on a real device or simulator (not Expo Go).
2. Tap a provider button, sign in, and confirm the app comes back with a signed-in user (getCurrentUser() returns an ID).
3. Check the Cognito console: the user appears in your user pool with an external-provider status, and the email attribute is filled in if you requested it.
4. Test sign-out, then sign in again, and test cancelling at the provider screen.
5. Test on both iOS and Android; deep-link problems often affect only one platform.

Common Problems

• “redirect_uri_mismatch” or similar at the provider. The Cognito /oauth2/idpresponse address in the provider console does not exactly match your user pool domain.
• The browser opens but never returns to the app. The deep-link scheme is not registered natively, or the callbackUrls entry differs from it (check the trailing slash).
• The sign-in button does nothing or crashes. The native module was not linked: run npx pod-install, rebuild the dev client, and make sure you are not in Expo Go.
• Facebook returns no email. The user may have no verified email on their Facebook account, or your app lacks the email permission; check the Facebook app’s permissions.
• Changes to the backend do not appear. Redeploy the sandbox and make sure the app uses the new amplify_outputs.json.

Production Notes

• Use separate environments and credentials for development and production, with each environment’s own callback URLs.
• Apple’s App Store rules: according to App Store Review Guideline 4.8, apps that use a third-party or social login for the user’s primary account must also offer an equivalent login option that limits data collection and lets users keep their email private. Sign in with Apple is the common way to meet this. Check the guideline text for the current exceptions before you submit.
• Add multi-factor authentication for email and password sign-in if the app holds sensitive data. Provider accounts bring their own protections.
• Account linking. A person who signs up with email and later uses Google gets separate identities unless you handle linking, so decide your policy for matching accounts by verified email before launch.
• Keep the SDKs updated, since both Amplify and the providers change their requirements.

Conclusion

With Amplify Gen 2, social sign-in is three parts: a backend definition with providers and callback URLs, provider consoles pointing at Cognito’s /oauth2/idpresponse address, and an app that registers a deep link and calls signInWithRedirect. Most failures come from a mismatched redirect address or an unregistered scheme, so check those first. If you are still on a Gen 1 project, plan your migration before the May 2027 end of life.