Google Sign In for React Native (via Supabase Auth): Overview
Cathy Lai

Cathy Lai @cathylai

About: React Native developer with a background in large-scale ecommerce systems. I write about practical, real-world mobile architecture — clean flows, offline-first patterns, and apps that feel good to use

Location:
Auckland, New Zealand
Joined:
Aug 6, 2022

Google Sign In for React Native (via Supabase Auth): Overview

Publish Date: Dec 8
2 0

If you're building an MVP with Supabase + React Native, choosing the right authentication flow is critical. The easiest path is to use Supabase Auth with Google / Apple OAuth, which reduces friction and avoids building your own password system.

🔑 Overview of the Supabase Auth Setup

Your MVP typically has 3 main components:

  • Mobile App (React Native / Expo)
  • Supabase Auth + Database (Postgres)
  • Optional : Your own backend server (used if you want custom business logic)

Supabase handles OAuth (Google/Apple/Facebook), issues JWTs, and applies Row Level Security (RLS).


🟦 Step-by-Step: How the Login Flow Works

1. App Starts → Check Existing Session

When the app launches:

const { data: session } = await supabase.auth.getSession();
Enter fullscreen mode Exit fullscreen mode
  • If session exists (with a valid JWT) → user goes straight in.
  • If not → show login screen.

2. User Taps “Sign in with Google/Apple”

await supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo: "your://callback" }
});
Enter fullscreen mode Exit fullscreen mode

This opens the provider’s login UI.


3. Provider Login

The user enters credentials with Google or Apple.


4. Provider Returns an Authorization Code

Important:

This code is not the JWT.

It is a temporary “ticket” that must be exchanged.


5. Supabase Exchanges That Code for a Session Object

Supabase securely calls Google/Apple:

POST https://oauth2.googleapis.com/token  
→ returns: id_token, access_token, refresh_token
Enter fullscreen mode Exit fullscreen mode

Supabase then creates a session object:

{
  "access_token": "<JWT>",
  "refresh_token": "<long-lived token>",
  "user": { "id": "uuid", "email": "..." }
}
Enter fullscreen mode Exit fullscreen mode

✔️ The access_token is the JWT.

✔️ This is what your app will use for all authenticated actions.


6. Session Is Returned to Your App

The Supabase client stores and manages it.


🔄 Token Refresh Flow (Handled Automatically)

  • The access_token (JWT) expires quickly.
  • The refresh_token silently fetches a new JWT.
  • Supabase handles this behind the scenes.

🖥️ Optional : Your Own Backend API

If your app calls a custom backend:

  1. The app sends requests with:
Authorization: Bearer <access_token>
Enter fullscreen mode Exit fullscreen mode
  1. Your backend verifies the Supabase JWT.
  2. Your backend runs custom logic and may call Supabase DB with a service role.

📡 ASCII Diagram of the Full Flow

              ┌────────────────────┐
              │   Mobile App (RN)  │
              │  MyNextHome / MVP  │
              └────────┬───────────┘
                       │
                       │ 1. App start: check existing session
                       │    
                       ▼
          ┌────────────────────────────┐
          │  No session? Show Login    │
          │  [Continue with Google]    │
          │  [Continue with Apple]     │
          └────────┬───────────────────┘
                   │
                   │ 2. User taps "Google"
                   │    
                   ▼
        ┌──────────────────────────────┐
        │        Supabase Auth         │
        └───────────┬──────────────────┘
                    │ 3. Redirect to provider
                    ▼
       ┌───────────────────────────────┐
       │   Google / Apple / Facebook   │
       └───────────┬───────────────────┘
                   │ 4. User authenticates
                   ▼
        ┌──────────────────────────────┐
        │        Supabase Auth         │
        │ 5. Exchange code → session   │
        │   Returns: access_token(JWT) │
        └───────────┬──────────────────┘
                    │ 6. Session back to app
                    ▼
              ┌────────────────────┐
              │   Mobile App (RN)  │
              │ Stores session     │
              └───────┬────────────┘
                      │
  ┌───────────────────┼─────────────────────────┐
  │                   │                         │
  │ 7a. Direct DB     │ 7b. Custom Backend      │
  │     queries       │     calls               │
  ▼                   ▼                         ▼
┌────────────────┐    ┌─────────────────┐  (optional)
│ Supabase DB    │    │ Your Backend    │─────────────┐
│ + RLS          │    │ API Server      │             │
└─────┬──────────┘    └──────┬──────────┘             │
      │ Uses JWT (auth.uid())│ Validates JWT          │
      ▼                      ▼                        ▼
 Only user's data        Business logic             External APIs
Enter fullscreen mode Exit fullscreen mode

✅ Summary

  • OAuth → Provider returns authorization code
  • Supabase exchanges the code → creates session (with JWT)
  • App stores session → uses JWT for DB and backend access
  • Token refresh is automatic

This flow is ideal for an MVP because it’s simple, secure, and frictionless.

Comments 0 total

    Add comment