Save this part
The short version
- Use your Supabase project URL and publishable key in the browser-never a secret or service-role key.
- Register the Supabase callback URL as an exact Google authorized redirect URI.
- Allow both local and production app callback URLs in Supabase URL Configuration.
- Test sign-in, sign-out, user data, errors, redirects, and session persistence before launch.
Google login has four moving parts: your app, Supabase Auth, Google OAuth, and the callback that returns the user to your app. Configure each boundary once, keep secrets out of frontend code, and Supabase handles the OAuth exchange and session for you.
Prefer the 60-second version?Watch the original Google login setup reel↗Before you start
Prepare the four things you need
- A Supabase project for authentication and sessions.
- A Google Cloud project where you can configure Google Auth Platform.
- Your website code running locally, plus its production domain if it is already deployed.
- An AI IDE such as Cursor, Windsurf, Claude Code, or VS Code with Copilot if you want to use the shared prompts.
Do not paste a Supabase secret key, legacy service_role key, or Google client secret into your frontend code, AI prompt, Git repository, or any variable exposed to the browser.
Step 01
Create a Supabase project and copy the public credentials
Create a project, then open the project Connect dialog or Settings → API Keys. Copy the Project URL and publishable key. New Supabase projects use a key beginning with sb_publishable_. Older projects may still show a legacy anon key.
The publishable key is designed for browser use, but it does not bypass database security. Enable Row Level Security and add policies before exposing application tables.
Step 02
Build the login interface with the first AI prompt
Copy the prompt below into your AI IDE and let it adapt the login screen to your existing project. Review every proposed file before accepting it, especially environment-variable names, routes, and dependencies.
Run the project after the UI work finishes. The Google button may not complete authentication yet; the provider and callback are configured in the next steps.
npm run devAct as a senior product designer and frontend UX designer.
Your task is to design and implement a dedicated Login page for my website.
The page should feel like a natural extension of the existing landing page. Do NOT introduce a new visual language. Reuse the existing typography, spacing, colors, gradients, shadows, glass effects, buttons, animations, and overall design system already used throughout the website. The login page should feel like it has always been part of the same product.
The layout should be a clean two-column split.
LEFT COLUMN
This side should reinforce what Offload is and why someone should join.
Its purpose is NOT to sell features.
Its purpose is to remind users what they're signing up for.
Content hierarchy:
• Small badge (optional)
• Large headline
• Supporting paragraph
• 3-5 concise benefit points
• Vision statement (optional)
• Trust indicator or social proof placeholder (optional)
The messaging should communicate:
Offload remembers things for you.
Stop trying to remember everything.
Save anything now.
Ask naturally later.
Free yourself from the mental burden of remembering.
Avoid talking about AI, embeddings, semantic search, or technical implementation.
Keep the messaging human and relief-focused.
RIGHT COLUMN
This side should contain a clean authentication card.
Keep it intentionally minimal.
Include:
• Offload logo
• Welcome back heading
• Short supporting text
• One prominent "Continue with Google" button
• Small text underneath: "By continuing, you agree to the Terms and Privacy Policy."
• Link to return to the landing page
Do NOT include:
Email/password login
GitHub login
Forgot password
Sign up form
Multiple authentication methods
The authentication card should remain visually simple and focused.
AUTHENTICATION STATE
The navigation bar should support two states.
Logged Out
Display a prominent "Login/Sign-in" button in the navigation bar.
Clicking it takes the user to the Login page.
Logged In
Replace the "Login/Sign-in" button with a compact user profile button positioned in the same location with profile name.
The profile button should display:
• Circular profile picture (Google avatar)
• Small dropdown indicator (optional)
Clicking the profile button opens a clean dropdown menu.
The dropdown should contain:
• Larger profile picture
• User's full name
• User's email address
• Divider
• Logout button
The dropdown should feel lightweight, polished, and consistent with the existing website's design language.
Use subtle open/close animations that match the rest of the site.
Clicking outside the dropdown should close it.
The profile button and dropdown should be fully responsive and accessible.
Do not introduce a separate account page for now.
Keep the interaction intentionally simple, since Google Sign-In is the only supported authentication method at this stage.
LAYOUT
Desktop:
Two-column layout.
Left side dedicated to product messaging.
Right side dedicated to authentication.
Both columns should feel balanced.
The authentication card should be vertically centered.
Mobile:
On mobile, stack vertically.
Product messaging first.
Authentication card below.
Maintain generous spacing.
ANIMATIONS
Use subtle animations that already fit the existing website.
Examples include:
Gentle fade-in on page load.
Slight upward entrance animation.
Soft hover interactions.
Smooth transitions.
Avoid flashy or distracting animations.
DESIGN REQUIREMENTS
Do NOT copy any external inspiration.
Do NOT recreate another website.
Instead, use the attached inspiration only as a reference for layout hierarchy and composition:
Product storytelling on the left.
Authentication card on the right.
The implementation should feel completely native to the existing Offload website.
GOAL
The page should communicate confidence, simplicity, and trust.
A visitor should immediately understand:
"I'm about to sign into the app that remembers things for me."
The experience should feel calm, polished, minimal, and consistent with the rest of the website.Step 03
Add the Supabase URL and publishable key to your environment
Use the prefix required by your framework so browser code can read these public values. Add the real values to your local environment file, keep the file out of Git, and configure the same names in your hosting provider for production.
NEXT_PUBLIC_SUPABASE_URL=https://YOUR_PROJECT_REF.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=YOUR_PUBLISHABLE_KEYVITE_SUPABASE_URL=https://YOUR_PROJECT_REF.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=YOUR_PUBLISHABLE_KEYIf an older tutorial says SUPABASE_ANON_KEY, it is referring to the legacy public key. Prefer the current publishable key for new projects. Never substitute a secret or service_role key.
Step 04
Connect the app to Supabase Auth
Copy the second prompt into your AI IDE to add the Supabase client, Google sign-in action, auth callback, signed-in user state, session handling, and sign-out action. Tell the AI IDE which framework and router your project uses before it edits anything.
For server-rendered apps, use the official Supabase SSR pattern and exchange the authorization code in the callback route. Avoid copying a client-only example into a server-rendered authentication flow without adapting it.
You are a senior full-stack engineer specializing in React and Supabase.
Your task is to implement Google Authentication using Supabase in my existing project.
OBJECTIVE
Connect my existing Login page to Supabase Auth using Google OAuth.
The UI is already complete.
Do NOT redesign, restyle, or modify any UI unless absolutely required for functionality.
I will configure everything inside the Supabase Dashboard myself (Google Provider, OAuth credentials, Redirect URLs, etc.). Your responsibility is ONLY the application code.
REQUIREMENTS
Analyze the existing project structure before making changes.
Reuse the existing Supabase client if one already exists.
Do not create duplicate clients.
If none exists, create one using best practices.
Connect the existing "Continue with Google" button (or equivalent) to:
supabase.auth.signInWithOAuth({
provider: "google"
})
Use a configurable redirect URL instead of hardcoding values.
Preserve the existing design.
Implement proper loading state during sign in.
Handle authentication errors gracefully.
Persist the user session.
On application startup:
Detect whether the user is already logged in.
Restore the existing session.
Prevent unnecessary login prompts.
Add an authentication context/provider if the project doesn't already have one.
The auth provider should expose:
user
session
loading
signInWithGoogle()
signOut()
Protect authenticated routes if routing already exists.
Redirect users appropriately:
Unauthenticated user → Login page
Authenticated user → Dashboard/Home
Create reusable hooks if appropriate (for example useAuth()).
Use TypeScript best practices.
Follow the existing project architecture.
Do not install unnecessary packages.
Remove dead code if any authentication logic becomes obsolete.
Make the implementation production-ready.
AFTER IMPLEMENTATION
Provide:
Every file you modified.
Every file you created.
A brief explanation of why each change was made.
Any environment variables I must add.
Any manual steps remaining inside the Supabase Dashboard.
Any security recommendations.
CONSTRAINTS
Do not change visual styling.
Do not rename unrelated files.
Do not refactor unrelated code.
Keep changes as small as possible.
Follow existing code conventions.
Ask before making architectural changes.
Begin by exploring the project structure and explaining your implementation plan before writing code.Step 05
Enable Google in Supabase and copy the callback URL
In Supabase, open Authentication → Sign In / Providers → Google. Enable the provider and copy the callback URL shown in the setup panel. It normally follows the format below, but use the exact value displayed for your project.
https://YOUR_PROJECT_REF.supabase.co/auth/v1/callbackThe Supabase callback URL belongs in Google as an authorized redirect URI. Your app callback URL belongs in Supabase URL Configuration. They are different URLs with different jobs.
Step 06
Create a Google OAuth web client
Open Google Auth Platform in Google Cloud Console. Configure Branding and Audience first if prompted, then open Clients and create an OAuth client with application type Web application.
- Add your app origins under Authorized JavaScript origins, such as http://localhost:3000 and https://yourdomain.com. Use origins only-no path or trailing slash.
- Paste the exact Supabase callback URL under Authorized redirect URIs. Scheme, hostname, path, case, and trailing slash must match.
- If the app is in Testing, add the Google accounts that should be allowed to sign in as test users.
- Copy the generated Client ID and Client Secret when Google shows them.
Step 07
Save the Google credentials and allowed app URLs in Supabase
Return to the Google provider in Supabase, paste the Client ID and Client Secret, then save. The client secret stays in Supabase provider configuration; it does not belong in your website environment file.
Next open Authentication → URL Configuration. Set Site URL to your production origin. Add the exact local and production callback URLs used by your app to Redirect URLs.
Site URL
https://yourdomain.com
Redirect URLs
http://localhost:3000/auth/callback
https://yourdomain.com/auth/callbackStep 08
Test the complete sign-in flow
Restart the development server after changing environment variables. Open a private browser window so an existing Google or application session does not hide a configuration problem.
- Click Continue with Google and complete consent with an allowed account.
- Confirm the app returns to the intended callback route without an open redirect.
- Verify the correct user name and email appear, then refresh the page to confirm the session persists.
- Sign out, refresh again, and confirm protected content is no longer accessible.
- Repeat on the production domain and inspect failure states for cancelled consent, blocked accounts, and expired sessions.
A redirect_uri_mismatch error means the URI sent in the OAuth request does not exactly match one registered in Google. Copy it again from Supabase instead of typing it manually.
Before launch
Complete the production security checklist
- Enable Row Level Security and test that users cannot read or change another user’s records.
- Restrict Supabase Redirect URLs to exact production paths instead of broad wildcards.
- Publish a clear homepage and privacy policy on your verified domain for Google’s production requirements.
- Request only the Google scopes your product needs; sensitive or restricted scopes can trigger additional verification.
- Rotate any credential that was committed, logged, shown on screen, or pasted into an untrusted tool.
Common questions
Google login with Supabase FAQ
Is Google login with Supabase free?
You can start on the free tiers offered by Supabase and Google Cloud, subject to their current quotas and terms. Check both providers before production because pricing and limits can change.
Should I use a Supabase publishable key or anon key?
Use the publishable key for a new project. The legacy anon key may still work in older projects, but Supabase is moving to publishable and secret keys. Neither a secret key nor a service_role key should ever be exposed in browser code.
Where should the Google client secret be stored?
Paste it only into the Google provider configuration in the Supabase dashboard. Do not put it in frontend environment variables, source control, screenshots, or prompts.
Why does Google show redirect_uri_mismatch?
The authorized redirect URI registered in Google does not exactly match the Supabase callback URL used by the request. Check the scheme, project hostname, path, case, and trailing slash.
Why can only my own Google account sign in?
Your Google OAuth app may still be in Testing. Add test users while developing, then configure the correct audience and complete any branding or verification requirements before public launch.
Found something worth remembering?
Save the useful idea in Offload with the context that made it matter. Ask for it naturally when you’re ready to use it.
Try Offload free