Best for
Founders who want a one-click Google OAuth login UI ready to wire to Supabase, Clerk, or Auth.js in 30 minutes
Stack
A ready-made Sign in with Google UI you can fork, run, and customize with the prompt pack below.
What's actually inside
The honest engineer's breakdown — what the Sign in with Googletemplate does, how it's wired, and where it's opinionated.
The Sign in with Google template is a single-purpose auth UI: an Auth Card centered on the page that puts the Google Sign-In Button front and center. The button uses shadcn/ui Button variant="outline" with an inline Google SVG icon and "Continue with Google" label, plus a loading spinner while the OAuth redirect is in progress. Below it sits an optional email/password form separated by a horizontal "or" divider — useful when you want Google as the primary path but a fallback for users who prefer email.
The Logo Slot in the card header is just an img or SVG element, making it trivially easy to drop in your brand without touching any component logic. Terms/Privacy Links render as small-print text below the button — legally necessary and already in place. What's good: the component is refreshingly minimal. There is almost no logic to unpick before wiring real auth.
The honest caveat: this template ships zero backend. The Google Sign-In Button has no onClick wired — it renders correctly but does nothing until you connect an auth provider. The OAuth callback route (app/auth/callback/route.ts) also does not exist in the template and must be added via prompt or manually. Plan for one focused session to go from fork to working OAuth.
Key UI components
Google Sign-In Buttonshadcn/ui Button outline variant with Google SVG icon and loading spinner
Auth CardCentered shadcn/ui Card containing logo, headline, OAuth button, and optional email form
Logo Slotimg or SVG element in Card header for brand identity
Optional Email FormFallback email + password fields below horizontal 'or' divider
Terms / Privacy LinksSmall-print anchor links to /terms and /privacy below the button
Loading StateSpinner shown on the Google Sign-In Button while OAuth redirect is in progress
Libraries it leans on
shadcn/uiButton, Card, and form components throughout the auth UI
lucide-reactIcons used in button and loading spinner states
Fork it and get it running
You can have this template forked, branded, and connected to a working OAuth flow in a single session. Follow these steps exactly and you will not need to touch any files manually.
Fork the template
Open https://v0.dev/chat/community/1m2t5fg3VWf in your browser. Click the "Fork" button in the top-right corner to copy the project into your own V0 account. You will land in a new V0 chat with the full template code already loaded and a live preview on the right.
Tip: Make sure you are signed in to v0.dev before clicking Fork — otherwise you will be redirected to the login page.
You should see: A new V0 project opens with the Auth Card visible in the preview panel.
Brand the Auth Card in Design Mode
Press Option+D to enter Design Mode. Click the Logo Slot in the Auth Card header and update it to point to your own logo URL. Change the Card headline text ("Sign in to Acme" or similar) to your product name. Adjust the Card border color to match your brand. All of this is free — Design Mode changes do not spend any V0 credits.
You should see: The preview shows your logo and product name in the Auth Card without any credits consumed.
Add auth provider credentials in the Vars panel
Click the Vars panel icon in the V0 toolbar. For Supabase, add NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY (both have the NEXT_PUBLIC_ prefix so they are safe for the browser). For Clerk, add NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and CLERK_SECRET_KEY. Never paste API keys directly into the chat — the Vars panel encrypts and injects them as environment variables.
Tip: You can copy NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY from your Supabase project's Settings → API page.
You should see: The Vars panel shows both environment variables saved and ready to inject into the build.
Wire the Google Sign-In Button
In the V0 chat, type the prompt: "Connect the 'Continue with Google' button to supabase.auth.signInWithOAuth({ provider: 'google', options: { redirectTo: process.env.NEXT_PUBLIC_SITE_URL + '/auth/callback' } })". V0 will add the onClick handler and import the Supabase client. Also add NEXT_PUBLIC_SITE_URL to the Vars panel pointing to your Vercel production domain (e.g. https://yourdomain.com) — this is the URL Google will redirect back to.
You should see: The Google Sign-In Button now has a working onClick that triggers the OAuth redirect when clicked in the deployed app.
Add the OAuth callback route
Prompt V0: "Add app/auth/callback/route.ts to handle the Supabase OAuth redirect and set the session cookie". V0 will generate a route handler that extracts the code from the URL, calls supabase.auth.exchangeCodeForSession(code), sets the session cookies on the response, then redirects to /dashboard. This route is required — without it, Google's redirect will land on a 404.
You should see: The file app/auth/callback/route.ts exists in the project and handles the OAuth code exchange.
Deploy and update Google Cloud Console
Click Share → Publish → "Publish to Production". Your app goes live on a Vercel subdomain in under 60 seconds. Then open Google Cloud Console → APIs & Services → Credentials → your OAuth 2.0 Client ID. Add the Vercel production domain to "Authorized Redirect URIs" as https://yourdomain.com/auth/callback. Without this step, Google will reject the OAuth flow with a "redirect_uri_mismatch" error.
Tip: Add a custom domain via Vercel Dashboard → Domains if you want a branded URL instead of the Vercel subdomain.
You should see: Users can sign in with Google on the live deployed URL and land on /dashboard after authentication.
The prompt pack
Copy-paste these straight into v0's chat to customize the Sign in with Googletemplate. Each one names this template's own components — no generic filler.
Add GitHub OAuth button below Google
Adds a GitHub OAuth option to the Auth Card that uses the same Supabase callback route already in place, so you get two social login options with minimal extra code.
Add a second shadcn/ui Button variant="outline" with a GitHub SVG icon below the existing Google Sign-In Button in the Auth Card. Label it "Continue with GitHub". Wire it to supabase.auth.signInWithOAuth({ provider: 'github', options: { redirectTo: process.env.NEXT_PUBLIC_SITE_URL + '/auth/callback' } }). The loading spinner behavior should match the Google button — show it while the OAuth redirect is in progress.Add brand logo and custom headline
Brands the Auth Card with your logo and product name using Design Mode approach in code, so the identity is baked in rather than just a visual overlay.
Replace the Logo Slot placeholder in the Auth Card header with an img tag pointing to /logo.svg, sized h-8 w-auto. Update the Card headline to '[Your Product Name]' and add a subtitle line 'Sign in to continue' in text-muted-foreground. Keep the Terms / Privacy Links at the bottom of the card pointing to /terms and /privacy respectively.
Add email fallback form
Activates the Optional Email Form section already scaffolded in the template, giving users who don't have or want to use Google a password-based fallback.
Add a horizontal 'or continue with email' divider below the Google Sign-In Button in the Auth Card. Below the divider, add shadcn/ui Input fields for email and password with a 'Sign in with email' Button. Wire both the Google OAuth path and the email/password path to the same Supabase client — the Google button calls supabase.auth.signInWithOAuth and the email form calls supabase.auth.signInWithPassword. Show a single unified Error Alert below the form for both failure modes.
Wire to Clerk OAuth
Replaces the Supabase auth wiring with Clerk's OAuth flow, keeping the same Auth Card UI but delegating session management to Clerk.
Install @clerk/nextjs and add ClerkProvider to app/layout.tsx using NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY from the Vars panel. Replace the current Google Sign-In Button onClick with Clerk's useSignIn hook: call signIn.authenticateWithRedirect({ strategy: 'oauth_google', redirectUrl: '/sso-callback', redirectUrlComplete: '/dashboard' }). Add a /sso-callback page that renders AuthenticateWithRedirectCallback from Clerk to complete the OAuth handshake.Wire to Supabase with full callback handler
Builds the complete Supabase server-side auth plumbing — callback route, session cookies, and middleware protection — so the Google OAuth flow works end-to-end in production.
Install @supabase/supabase-js and @supabase/ssr. Create app/auth/callback/route.ts: extract the code param from the URL search params, call supabase.auth.exchangeCodeForSession(code) using a createServerClient from @supabase/ssr, write the resulting session cookies to the Response object, then redirect to /dashboard. Create middleware.ts using createServerClient to check supabase.auth.getUser() on every request — redirect to /login if no session is found on protected routes. Add NEXT_PUBLIC_SITE_URL to Vars pointing to the production Vercel domain.
Add post-login user profile creation
Automatically creates a profiles row for every new Google sign-up, seeding display name and avatar from Google's user metadata without any extra form step.
After the Google OAuth callback completes in app/auth/callback/route.ts, check if the user already has a profile in Supabase: call supabase.from('profiles').select('id').eq('id', user.id).single(). If the profile does not exist (error.code === 'PGRST116'), insert a new row using the service role key (SUPABASE_SERVICE_ROLE_KEY — server-only, no NEXT_PUBLIC_ prefix): insert display_name from user.user_metadata.full_name and avatar_url from user.user_metadata.avatar_url into the profiles table. Add an RLS policy: CREATE POLICY 'users see own profile' ON profiles FOR ALL USING (auth.uid() = id).Gotchas when you extend it
The failures people actually hit when they push this template past its defaults — and the exact fix for each.
Google OAuth redirect fails on Vercel preview deployments — redirect_uri_mismatchWhy: Preview URLs are dynamic (e.g. project-abc123.vercel.app) and change per branch. Google Cloud Console requires exact static redirect URI matches, so any preview URL not explicitly added will be rejected.
Fix: Register only the production domain in Google Cloud Console → APIs → Credentials → OAuth 2.0 Client IDs → Authorized Redirect URIs. For testing on a preview, temporarily add that specific preview URL to the allowed list.
Add your Vercel production domain to Google Cloud Console → APIs → Credentials → OAuth 2.0 Client IDs → Authorized Redirect URIs; never use the preview URL as a permanent entry
`Import Error | Failed to load "@supabase/ssr" from "blob..."` in V0 previewWhy: @supabase/ssr fails to resolve through V0's esm.sh preview sandbox module resolution system. The package uses server-specific Node.js APIs that esm.sh cannot bundle for the browser-based preview.
Fix: The app will work correctly after deployment to Vercel. Dismiss the preview error and test the full OAuth flow via the deployed URL instead.
This error only occurs in V0's preview sandbox due to esm.sh resolution; click Share → Publish to Production and test the actual OAuth flow on Vercel
Button stays loading if OAuth popup is blocked by browserWhy: Some browsers block redirects triggered outside a direct user gesture context, or the OAuth popup is blocked by a popup blocker. When the navigation doesn't happen, the Loading State spinner in the Google Sign-In Button never resets.
Fix: Add a setTimeout fallback: if the page hasn't navigated within 5 seconds, reset the loading state and show a message in the Auth Card: 'Redirect blocked — please try again'.
Add a 5-second timeout that resets the loading state if the OAuth redirect hasn't navigated the page, then show a 'Redirect blocked by browser, please try again' message in the Auth Card
User lands on /auth/callback but session is not set — cookies missingWhy: exchangeCodeForSession works but cookies are not written because the createServerClient in the callback route is not configured with cookie write handlers. The session exists in memory but is lost on redirect.
Fix: Use createServerClient from @supabase/ssr and pass the response cookies write handler: cookies option must include both getAll and setAll methods pointing to the Response object.
Check that the Supabase callback route uses createServerClient from @supabase/ssr with the cookies handler that writes to the Response object using setAll
Template vs. custom — the honest call
A forked template gets you far, fast. Here's where it holds up, and where you'll outgrow it.
The template is enough when
- Consumer app where Google login covers 90%+ of your target users
- Early MVP with zero existing users who need password management
- B2C product targeting Google Workspace users or teams
- Prototype to test the auth flow and UX before purchasing a Clerk subscription
Go custom when
- You need a password-based fallback for users without a Google account (some enterprise users avoid Google login)
- Enterprise SAML or Microsoft Entra login is required by procurement
- Multi-tenant product with workspace-scoped identity where Google email domain matters
- Phone OTP auth for markets with low Google account penetration
RapidDev wires this V0 Google Sign-In to Supabase or Clerk, adds protected routes and user profile creation, and ships it production-ready in 1–2 days.
Frequently asked questions
Is the Sign in with Google template free to use?
Yes. Community templates on v0.dev are free to fork. You pay only for V0 credits when you send prompts to customize the template. Forking itself and using Design Mode cost nothing.
Can I use this template commercially?
Yes. V0 community templates are available for commercial use. The generated code is yours to use in any product, including paid SaaS applications. Review v0.dev's terms of service for the complete licensing details.
Why does my fork show a blank screen or import error in the V0 preview?
The most common cause is the `@supabase/ssr` import failing in V0's esm.sh preview sandbox. This is a known limitation of the preview environment — the package uses Node.js APIs that can't run in the browser-based sandbox. Click Share → Publish to Production and test the OAuth flow on the live Vercel URL instead. The deployed app will work correctly.
Do I need a Google Cloud Console account to use this template?
Yes, to enable real Google OAuth you need to create an OAuth 2.0 Client ID in Google Cloud Console and add your Vercel domain to Authorized Redirect URIs. This is a one-time setup that takes about 10 minutes. Both Supabase and Clerk have documentation walking you through the Google Cloud Console steps.
Does this template work with Clerk or just Supabase?
It works with either. The Auth Card UI is auth-provider-agnostic. The prompt pack includes steps for both Supabase signInWithOAuth and Clerk's authenticateWithRedirect OAuth flow. Choose your provider and follow the corresponding prompt.
Can I add more OAuth providers like GitHub or Apple?
Yes. The same Auth Card pattern supports any provider your auth library supports. The 'Add GitHub OAuth button' prompt in this playbook shows exactly how to add a second provider button below the Google Sign-In Button, reusing the same Supabase callback route.
Can RapidDev customize this template for my product?
Yes. RapidDev wires V0 Google Sign-In to Supabase or Clerk, adds protected routes, user profile creation, and production OAuth configuration — typically delivered in 1–2 days.
Outgrowing the template?
RapidDev turns v0 prototypes into production apps — real auth, database, and payments — at $13K–$25K.
Book a free consultation30-min call. No commitment.