SupabaseであらゆるウェブサイトにGoogleログインを追加する

既存のSupabase認証にGoogleログインを追加し、OAuthを正しく設定して、ログインの流れ全体をテストします。

ロードマップと資料

Google OAuthクライアントを作成する

既存のSupabase認証

このガイドは、Supabase認証がすでに動作しているウェブサイトに、ログイン方法のひとつとしてGoogleを追加します — 新規登録、ログイン、セッション。まだ用意できていない場合は、先にそちらを完了してからここに戻ってください。

Supabaseであらゆるウェブサイトにユーザー認証を追加する

Supabaseで新規登録、ログイン、セッション、保護されたエリアを構築します。

/video/add-user-authentication-supabase

SupabaseのCallback URLをコピーする

Supabaseを開く

https://supabase.com/dashboard

Your project Authentication Sign In / Providers Google

Callback URL (for OAuth)をコピーします。これはウェブサイトのコードではなく、Google Cloudに入力します。

Google Auth Platformを設定する

Google Cloud Consoleを開く

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

Your project Google Auth Platform

Brandingでアプリ情報を追加し、Audienceとして「External」を選ぶ Audienceでアプリを公開する — または「Testing」のままにして、自分をテストユーザーとして追加する Data Accessで基本スコープを確認する

openid

.../auth/userinfo.email

.../auth/userinfo.profile

OAuthクライアントを作成する

Google Auth Platform Clients Create client

「Web application」を選ぶ Authorized JavaScript originsにウェブサイトを追加する Authorized redirect URIsにSupabaseのCallback URLを貼り付ける 「Create」をクリックする Client IDとClient Secretをコピーする — Googleがシークレットを表示するのは一度だけ

サイトのURL → Authorized JavaScript origins

SupabaseのCallback URL → Authorized redirect URIs

GoogleをSupabaseに接続する

GoogleクライアントをSupabaseに追加する

SupabaseのGoogleプロバイダーに戻ります — ステップ1と同じタブです。

Your project Authentication Sign In / Providers Google

Googleを有効にする

GoogleのClient IDを貼り付ける

GoogleのClient Secretを貼り付ける

保存する

Client Secretは非公開にする

Client SecretはSupabaseにだけ保存します。フロントエンドのコードや公開される環境変数には絶対に含めないでください。

Googleログインを追加する

Googleログインボタンを追加する

AIが、今あるログイン機能を作り直さずに、そこへGoogleを追加します。

「Continue with Google」を追加する

現在のログインの流れをそのまま保ちながら既存のSupabase認証にGoogleログインを追加し、Supabaseで必要なRedirect URLsを報告します。

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>

戻り先URLを追加する

上でAIが示したRedirect URLsだけを追加してください。

Your project Authentication URL Configuration Redirect URLs

これらはステップ1のCallback URLではありません — そちらはGoogle Cloudにだけ入力します。

Googleログインをテストする

Googleでログインできる

ウェブサイトを開き、「Continue with Google」をクリックして、Googleアカウントを選びます。ログインした状態でサイトに戻ることを確認してください。

必要に応じて、アカウントを以下で確認します:

Your project Authentication Users

再ログインできる

ログアウトしてから、もう一度Googleでログインします。Supabaseが重複したアカウントを作らずに、既存のアカウントを再利用することを確認してください。

既存の認証が引き続き動作する

Googleを追加しても、すでに動作していたものが何も変わっていないことを確認します。

ページを再読み込みしてもログインしたままになっている

保護されたページには引き続きログインが必要

メールアドレスとパスワードでのログインが引き続き動作する(アプリにある場合)

各ユーザーには引き続き自分の非公開データだけが表示される

Googleログインが動作しています

最後のステップでは、ユーザーがあなたのブランドだとわかるように、アプリ名とロゴの確認を受けます。表示されるsupabase.coの認証アドレスを置き換えるのは別の作業で、Supabaseのカスタムドメインが必要です。

Googleログインのブランドを確認・設定する

本番環境におすすめ

Googleログインはすでに動作しています。このステップでは、ユーザーがログインするときに確認済みのアプリ名とロゴが表示されるようにします。

Googleアプリのブランド情報を入力する

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(ある場合)

Authorized domain

Developer contact information

AIで作ったあらゆるウェブサイトにプライバシーポリシーと利用規約のページを追加する

プライバシーポリシーや利用規約のページがまだありませんか?先に作成してください。

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

ドメインとブランドを確認する

Google Search Consoleを開く

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

まだの場合は、Google Search Consoleでドメインを確認する Google Auth PlatformのBrandingページに戻る 「Verify Branding」をクリックする

Googleが自動で承認する場合と、審査が必要になる場合があります。

公開して再テストする

Googleに「Ready to publish」と表示されたら、「Publish branding」をクリックする ブラウザのプライベートウィンドウでウェブサイトを開く 「Continue with Google」をクリックする アプリ名とロゴが表示されることを確認する

任意:カスタム認証ドメインを使う

Supabaseの有料機能です — Googleログインには必須ではありません。ブランド入りの認証URLにしたい場合や、Googleの確認で自分が管理する認証ドメインが必要な場合に使います。

ブランドの確認で変わるのは、Googleが表示するアプリ名とロゴです。Supabaseのカスタムドメインを使うと、デフォルトの認証アドレスproject-ref.supabase.coを、auth.example.comのような独自のアドレスに置き換えられます。

有効にしたら、そのcallback URL(https://auth.example.com/auth/v1/callback)をGoogleクライアントのAuthorized redirect URIsに追加してください。

Supabaseのカスタムドメイン

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