Aggiungi l’accesso con Google a qualsiasi sito web con Supabase

Aggiungi l’accesso con Google alla tua autenticazione Supabase esistente, configura OAuth correttamente e testa l’intero flusso di accesso.

Roadmap e risorse

Crea il client OAuth di Google

Autenticazione Supabase esistente

Questa guida aggiunge Google come opzione di accesso a un sito web in cui l’autenticazione Supabase funziona già — registrazione, accesso e sessioni. Se il tuo non ce l’ha ancora, completala prima, poi torna qui.

Aggiungi l’autenticazione degli utenti a qualsiasi sito web con Supabase

Crea registrazione, accesso, sessioni e aree protette con Supabase.

/video/add-user-authentication-supabase

Copia il Callback URL di Supabase

Apri Supabase

https://supabase.com/dashboard

Your project Authentication Sign In / Providers Google

Copia il Callback URL (for OAuth). Va in Google Cloud, non nel codice del tuo sito web.

Configura Google Auth Platform

Apri Google Cloud Console

https://console.cloud.google.com/auth/branding

Your project Google Auth Platform

Aggiungi le informazioni della tua app in Branding — scegli "External" come Audience Pubblica l’app in Audience — oppure lasciala in "Testing" e aggiungiti come utente di test Conferma gli scope di base in Data Access

openid

.../auth/userinfo.email

.../auth/userinfo.profile

Crea il client OAuth

Google Auth Platform Clients Create client

Scegli "Web application" Aggiungi il tuo sito web in Authorized JavaScript origins Incolla il Callback URL di Supabase in Authorized redirect URIs Fai clic su "Create" Copia il Client ID e il Client Secret — Google mostra il secret una sola volta

URL del tuo sito → Authorized JavaScript origins

Callback URL di Supabase → Authorized redirect URIs

Collega Google a Supabase

Aggiungi il client Google a Supabase

Di nuovo nel provider Google di Supabase — la stessa scheda del Passaggio 1.

Your project Authentication Sign In / Providers Google

Attiva Google

Incolla il Client ID di Google

Incolla il Client Secret di Google

Salva

Mantieni privato il Client Secret

Il Client Secret va solo in Supabase. Non esporlo mai nel codice frontend o in una variabile d’ambiente pubblica.

Aggiungi l’accesso con Google

Aggiungi il pulsante di accesso con Google

La tua IA aggiunge Google all’accesso che hai già, senza ricostruirlo.

Aggiungi "Continue with Google"

Aggiunge l’accesso con Google alla tua autenticazione Supabase esistente mantenendo intatto il flusso di accesso attuale, poi indica i Redirect URLs che ti servono in Supabase.

Add "Continue with Google" to this project's existing Supabase Authentication. Google is already enabled as a provider in my Supabase project, and the Google Client ID and Client Secret are already saved there. Nothing about Google needs to be configured in code. Before changing anything, inspect the current project: - the existing Supabase client(s) and how they are configured - the sign-in page, and the sign-up page if there is one - any existing auth callback route - how protected pages are guarded - how the session is read, kept in sync, and signed out - whether a profile row is created for new users - whether any signed-in user has private data of their own (for example rows protected by Row Level Security) Preserve this project's existing authentication architecture. Make the smallest focused change that adds Google — do not refactor, rename or restyle unrelated code. WHAT TO DO - Add one "Continue with Google" button to the existing sign-in page, and to the sign-up page if there is one. Match the existing design and components. - Start sign-in with the project's existing Supabase client: supabase.auth.signInWithOAuth({ provider: 'google', options: { redirectTo } }). - Follow this project's own architecture instead of forcing one: - Browser-only app: make sure the page the user returns to picks up the new session through the existing session handling. - PKCE or server-rendered auth (for example @supabase/ssr or Next.js): return through a callback route that exchanges the code for a session with the existing server-side client. Reuse an existing callback route; add one only if none exists, following the project's routing conventions. - redirectTo is a page on THIS website. Build it at runtime from the current site origin, or from the project's existing site URL setting. Never hard-code localhost or a domain. - Never use the Supabase Callback URL (the one ending in /auth/v1/callback) as redirectTo — that URL belongs only in Google Cloud, not in this project's code. - After sign-in, send the user where email/password sign-in already sends them, and keep any existing "return to the page I came from" behavior. - Show a loading state while sign-in starts, and prevent repeated clicks. - If sign-in fails or is cancelled, show an error in the existing style and keep the page usable. - Returning users: the same Google account must reuse the same Supabase user, never create a duplicate. Make any profile creation safe to run more than once. - If a profile row is created for new users, make sure it works for Google users too — they have no password and no sign-up form fields; Google provides their name and picture in the user metadata. - If any signed-in user has private data of their own, preserve the existing data isolation exactly as it is (Row Level Security, policies, user id ownership, server-side checks) for a Google user too. Do not loosen, bypass or duplicate it. - Do not build custom account linking — Supabase already links a Google sign-in to an existing user with the same verified email. KEEP AS IT IS - the existing authentication UI and architecture - email/password sign-in and sign-up, if the project has them - protected routes and their guards - session handling and sign-out - Row Level Security and database policies - environment variables and the existing Supabase client configuration - unrelated pages and design NEVER - rebuild or replace the existing authentication - create a second Supabase client or a second authentication system - add a Google sign-in library or call Google APIs directly - put the Google Client Secret, a Supabase secret key or a service-role key in frontend code - deploy anything Run the production build and fix any errors you introduced. Finish with exactly this summary: GOOGLE LOGIN ADDED - Files changed: <each file, with what changed> - Sign-in flow: <browser / callback route at path> - Return URL: <the exact redirectTo path this code uses> - Supabase Redirect URLs to allow: <each full URL this code uses, one per line — the live site and local development; if the live domain is unknown, the path to add after it> - Private user data: <preserved / not applicable> - Still to do: <nothing, or a short list>

Aggiungi gli URL di ritorno

Aggiungi solo i Redirect URLs che la tua IA ha elencato sopra.

Your project Authentication URL Configuration Redirect URLs

Non sono il Callback URL del Passaggio 1 — quello va solo in Google Cloud.

Testa l’accesso con Google

L’accesso con Google funziona

Apri il tuo sito web, fai clic su "Continue with Google" e scegli un account Google. Conferma di tornare sul sito con l’accesso effettuato.

Se vuoi, verifica l’account in:

Your project Authentication Users

Accedere di nuovo funziona

Esci, poi accedi di nuovo con Google. Conferma che Supabase riutilizza il tuo account esistente invece di crearne un duplicato.

L’autenticazione esistente funziona ancora

Conferma che aggiungere Google non ha cambiato nulla di ciò che già funzionava.

Resti connesso dopo aver aggiornato la pagina

Le pagine protette richiedono ancora l’accesso

L’accesso con email e password funziona ancora, se la tua app lo prevede

Ogni utente vede ancora solo i propri dati privati

L’accesso con Google ora funziona

L’ultimo passaggio verifica il nome e il logo della tua app, così gli utenti riconoscono il tuo brand. Sostituire un indirizzo di autenticazione supabase.co visibile è un’altra cosa e richiede un dominio personalizzato Supabase.

Verifica e personalizza l’accesso con Google

Consigliato per la produzione

L’accesso con Google funziona già. Questo passaggio mostra il nome e il logo verificati della tua app quando gli utenti accedono.

Completa il branding della tua app Google

Apri Google Auth Platform

https://console.cloud.google.com/auth/branding

Google Auth Platform Branding

App name

App logo

Application home page

Application privacy policy link

Application terms of service link, se ne hai uno

Authorized domain

Developer contact information

Aggiungi le pagine di informativa sulla privacy e termini a qualsiasi sito web creato con l’IA

Non hai ancora un’informativa sulla privacy o una pagina dei termini? Creale prima.

/video/add-privacy-policy-and-terms-pages-to-any-ai-built-website

Verifica il tuo dominio e il tuo branding

Apri Google Search Console

https://search.google.com/search-console

Verifica il tuo dominio in Google Search Console, se non l’hai già fatto Torna alla pagina Branding in Google Auth Platform Fai clic su "Verify Branding"

Google può approvare automaticamente o richiedere una revisione.

Pubblica e ripeti il test

Quando Google mostra "Ready to publish", fai clic su "Publish branding" Apri il tuo sito web in una finestra di navigazione privata Fai clic su "Continue with Google" Conferma che compaiono il nome e il logo della tua app

Facoltativo: usa un dominio di autenticazione personalizzato

Funzione a pagamento di Supabase — non necessaria per l’accesso con Google. Usala per avere un URL di autenticazione con il tuo brand, o se la verifica di Google richiede un dominio di autenticazione che controlli tu.

La verifica del brand cambia il nome e il logo che Google mostra. Un dominio personalizzato Supabase sostituisce l’indirizzo di autenticazione predefinito project-ref.supabase.co con il tuo, come auth.example.com.

Dopo averlo attivato, aggiungi il suo callback URL (https://auth.example.com/auth/v1/callback) agli Authorized redirect URIs del tuo client Google.

Domini personalizzati Supabase

https://supabase.com/docs/guides/platform/custom-domains