Google OAuth 登録手順 -- Google Auth Platform で Client ID / Secret を発行する
はじめに
Google OAuth の登録は、最初にやるとだいたい迷う。
弊社では、複数カレンダーを統合管理するサービス Missete で Google OAuth を利用し、Google Calendar と連携するカレンダーアプリを作った。
Client ID を発行するだけなら簡単そうに見えるのに、実際に Google Cloud Console を開くと、Branding、Audience、Data Access、Clients、Verification Center など似たような設定画面が並んでいる。
しかも、Google ログインだけなのか、Google Calendar や Gmail まで触るのかで、必要なスコープも審査の重さも変わる。リダイレクト URI の末尾に / が付いているだけで redirect_uri_mismatch になったりもする。
この記事では、Web アプリで Google OAuth を使うために、Google Auth Platform で OAuth クライアントを作成する手順をまとめる。
主に想定しているのは、次のようなケース。
- Google アカウントでログインしたい
- Google Calendar API を使いたい
- Google Drive や Gmail などの Google API と連携したい
- NextAuth.js、Auth.js、Laravel Socialite、Rails OmniAuth などに Google OAuth を設定したい
- 本番公開前に Google の審査が必要か確認したい
この記事は 2026年5月6日時点の Google Auth Platform の画面構成を前提にしている。Google Cloud Console は画面名や導線が変わることがあるので、実際の画面と少し違う場合は、近い名前のメニューを探してほしい。
まず何を作るのか
今回作るのは、Web アプリ用の OAuth クライアント。
最終的に、アプリ側で次の値を使える状態にする。
GOOGLE_CLIENT_ID=xxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=xxxxxxxxxxxxxxxx
GOOGLE_REDIRECT_URI=https://example.com/api/auth/callback/googleブラウザから Google の認可画面へ移動し、ユーザーが同意したあと、アプリ側の callback URL で認可コードを受け取る構成を想定している。
ざっくり言うと、作業は次の4つに分かれる。
| 作業 | やること |
|---|---|
| プロジェクト作成 | Google Cloud 上にアプリ用の入れ物を作る |
| 同意画面の設定 | ユーザーに表示されるアプリ名や連絡先を登録する |
| スコープの設定 | アプリが使う Google データの権限を登録する |
| OAuth クライアント作成 | Client ID / Client Secret と redirect URI を登録する |
Google ログインだけなら比較的シンプル。Google Calendar、Drive、Gmail などのユーザーデータにアクセスする場合は、スコープと審査まわりを丁寧に見る必要がある。
事前に決めておくもの
Google Cloud Console を開く前に、次の情報を用意しておくと作業が止まりにくい。
| 項目 | 例 | 使う場所 |
|---|---|---|
| アプリ名 | Example Calendar App | OAuth 同意画面 |
| サポートメール | support@example.com | Branding |
| 開発者連絡先 | developer@example.com | Branding |
| アプリのトップページ | https://example.com | Branding |
| プライバシーポリシー | https://example.com/privacy | Branding / 審査 |
| 利用規約 | https://example.com/terms | Branding |
| 本番 callback URL | https://example.com/api/auth/callback/google | Clients |
| ローカル callback URL | http://localhost:3000/api/auth/callback/google | Clients |
| 使う Google API | Google Calendar API など | API ライブラリ |
| 使うスコープ | openid email profile など | Data Access / アプリ側 |
プライバシーポリシーは後回しにしがちだが、外部ユーザーに公開するアプリではかなり重要になる。Google API でユーザーデータを扱うなら、どのデータを何のために使うのか、保存するのか、削除依頼をどう受けるのかを書いておく。
全体の流れ
手順は次の順番で進める。
- Google Cloud プロジェクトを作成する
- 必要な Google API を有効化する
- Google Auth Platform を初期設定する
- Branding でアプリ情報を設定する
- Audience で公開範囲とテストユーザーを設定する
- Data Access で OAuth スコープを登録する
- Clients で OAuth クライアントを作成する
- Authorized JavaScript origins を登録する
- Authorized redirect URIs を登録する
- Client ID / Client Secret をアプリに設定する
- テストユーザーで OAuth フローを確認する
- 本番公開前に Verification Center を確認する
最初から本番公開まで一気にやろうとすると、スコープや審査で詰まりやすい。まずはテストユーザーだけで OAuth フローを通し、アプリ側の実装が固まってから公開設定を進めるのが楽。
1. Google Cloud プロジェクトを作成する
まず、OAuth クライアントを置く Google Cloud プロジェクトを作成する。
- Google Cloud Console にアクセスする
- 画面上部のプロジェクトセレクターをクリックする
- 「新しいプロジェクト」をクリックする
- プロジェクト名を入力する
- 必要に応じて組織や請求先を選択する
- 「作成」をクリックする
- 作成したプロジェクトを選択する
プロジェクト名は、あとから見て分かる名前にしておく。
| 環境 | プロジェクト名の例 |
|---|---|
| 開発 | example-app-dev |
| ステージング | example-app-staging |
| 本番 | example-app-production |
本番用と開発用は分けておいた方がいい。開発中に redirect URI やスコープを何度も変えるなら、なおさら分けたい。本番プロジェクトでスコープを増やすと、審査やユーザー同意に影響することがある。
2. 必要な Google API を有効化する
Google Calendar、Google Drive、Gmail などの API を使う場合は、対象 API を有効化する。
Google ログインだけで、Google Calendar API などを呼び出さないなら、この手順が不要なケースもある。
- 左メニューから「API とサービス」を開く
- 「ライブラリ」を開く
- 使いたい API 名で検索する
- 対象の API を選択する
- 「有効にする」をクリックする
よく使う API は次のとおり。
| やりたいこと | 有効化する API |
|---|---|
| Google Calendar の予定を扱う | Google Calendar API |
| Google Drive のファイルを扱う | Google Drive API |
| Gmail のメールを扱う | Gmail API |
| Google Docs を扱う | Google Docs API |
| Google Sheets を扱う | Google Sheets API |
OAuth は通っているのに API 呼び出しだけ 403 Forbidden になる場合、API を有効化していないだけ、ということがある。認証まわりを疑う前に、API ライブラリの状態を確認する。
3. Google Auth Platform を初期設定する
OAuth 同意画面や OAuth クライアントは、Google Auth Platform から設定する。
- Google Cloud Console で対象プロジェクトを選択する
- 左メニューから「Google Auth Platform」を開く
- 「Branding」を開く
- 未設定の場合は「Get Started」をクリックする
- App name にアプリ名を入力する
- User support email を選択する
- Audience でアプリの対象ユーザーを選択する
- Contact Information に開発者連絡先を入力する
- Google API Services User Data Policy を確認する
- 「Create」をクリックする
ここで設定する App name は、ユーザーが Google の同意画面で見る名前になる。開発中の仮名をそのまま本番に出さないように注意する。
User support email はユーザー向けの問い合わせ先。Contact Information は Google からの通知先。どちらも、実際に確認できるメールアドレスを使う。
4. Branding でアプリ情報を設定する
Branding では、ユーザーに見えるアプリ情報を設定する。
確認する項目は次のとおり。
| 項目 | 内容 |
|---|---|
| App name | OAuth 同意画面に表示されるアプリ名 |
| User support email | ユーザー向けの問い合わせ先 |
| App logo | 同意画面などに表示されるロゴ |
| App domain | アプリ URL、プライバシーポリシー、利用規約 |
| Authorized domains | OAuth で利用するドメイン |
| Developer contact information | Google からの通知先 |
外部ユーザーに公開するなら、少なくとも次のページは用意しておきたい。
- アプリのトップページ
- プライバシーポリシー
- 利用規約
Authorized domains には、OAuth で使うドメインを登録する。
本番 URL が https://example.com なら、Authorized domains は example.com。https:// やパスは入れない。
| URL | Authorized domains に入れる値 |
|---|---|
https://example.com | example.com |
https://app.example.com | example.com |
https://staging.example.com | example.com |
ドメイン所有権の確認が必要になることもある。審査まで進めるなら、Google Search Console などでドメイン確認できる状態にしておく。
5. Audience で公開範囲を設定する
Audience では、この OAuth アプリを誰が使えるかを決める。
選択肢は主に2つ。
| User type | 用途 |
|---|---|
| Internal | Google Workspace 組織内のユーザーだけが使う |
| External | 任意の Google アカウントで使う |
個人の Gmail アカウントや社外ユーザーにも使ってもらうなら、通常は External を選ぶ。
Internal は Google Workspace 組織内向け。組織外のアカウントでログインすると org_internal エラーになる。一般公開サービスでは、ここを Internal にしてしまうと外部ユーザーが使えない。
External のアプリは、最初は Testing の状態で使う。Testing の状態では、登録したテストユーザーだけが OAuth フローを通過できる。
Testing は開発中には便利だが、本番運用向けではない。テストユーザー数や認可の有効期間に制限があるため、外部ユーザーに継続利用してもらうなら In production への移行と、必要に応じた OAuth Verification を考える。
6. テストユーザーを追加する
開発中は、OAuth を試す Google アカウントをテストユーザーに追加する。
- Google Auth Platform の「Audience」を開く
- Test users の「Add users」をクリックする
- テストに使う Google アカウントのメールアドレスを入力する
- 「Save」をクリックする
テストユーザーに追加していないアカウントでログインすると、未確認アプリの警告で止まったり、先に進めなかったりすることがある。
OAuth の動作確認で使うアカウントと、Test users に追加したメールアドレスが一致しているかをまず見る。会社アカウントと個人アカウントを切り替えながら試していると、ここで地味に迷う。
7. Data Access で OAuth スコープを登録する
Data Access では、アプリが要求する OAuth スコープを登録する。
スコープは、アプリがユーザーのどのデータにアクセスするかを表す権限。Google の審査では、必要以上に広いスコープを要求していないかが見られる。
- Google Auth Platform の「Data Access」を開く
- 「Add or Remove Scopes」をクリックする
- アプリで利用するスコープを選択する
- 必要なスコープが一覧にない場合は手動で追加する
- 追加したスコープを確認する
- 「Save」をクリックする
Google ログインだけなら、よく使うのはこのあたり。
| スコープ | 用途 |
|---|---|
openid | OpenID Connect を使う |
email | メールアドレスを取得する |
profile | 名前やプロフィール画像などの基本情報を取得する |
Google Calendar 連携では、たとえば次のスコープを使う。
| スコープ | 用途 |
|---|---|
https://www.googleapis.com/auth/calendar.freebusy | カレンダーの空き時間情報を見る |
https://www.googleapis.com/auth/calendar.events.freebusy | アクセス可能なカレンダーの空き時間情報を見る |
https://www.googleapis.com/auth/calendar.events.readonly | 予定を読み取る |
https://www.googleapis.com/auth/calendar.events | 予定を読み書きする |
https://www.googleapis.com/auth/calendar.readonly | カレンダー情報を読み取る |
https://www.googleapis.com/auth/calendar | カレンダー全体を読み書き、共有、削除する |
基本は、必要最小限のスコープを選ぶ。
予定の空き時間だけ分かればいいなら、いきなり https://www.googleapis.com/auth/calendar を要求しない。予定を作成、更新したいなら https://www.googleapis.com/auth/calendar.events を検討する。カレンダーの共有設定まで触らないなら、広いスコープは避ける。
アプリ側で OAuth リクエストに含めるスコープと、Data Access に登録するスコープはそろえておく。ここがずれると、審査時の説明と実際の挙動が合わなくなる。
8. Clients で OAuth クライアントを作成する
次に、Web アプリ用の OAuth クライアントを作成する。
- Google Auth Platform の「Clients」を開く
- 「Create Client」をクリックする
- Application type で「Web application」を選択する
- Name に管理用の名前を入力する
- Authorized JavaScript origins を入力する
- Authorized redirect URIs を入力する
- 「Create」をクリックする
Name は Google Cloud Console 上で管理するための名前。ユーザーには表示されない。
環境ごとに分けるなら、次のような名前にすると見分けやすい。
| 環境 | Name の例 |
|---|---|
| ローカル開発 | Example App Local |
| ステージング | Example App Staging |
| 本番 | Example App Production |
OAuth クライアントを環境ごとに分けると、ローカル用の localhost 設定を本番用 Client に混ぜなくて済む。
9. Authorized JavaScript origins を登録する
Authorized JavaScript origins には、ブラウザから OAuth 関連のリクエストを送るオリジンを登録する。
オリジンは、スキーム、ホスト、ポートまで。パスは含めない。
| 環境 | 例 |
|---|---|
| ローカル開発 | http://localhost:3000 |
| Vite などのローカル開発 | http://localhost:5173 |
| ステージング | https://staging.example.com |
| 本番 | https://example.com |
ここに callback URL を丸ごと入れない。
https://example.com/api/auth/callback/googleAuthorized JavaScript origins に入れるのは、次の形式。
https://example.comフロントエンドとバックエンドのドメインが違う場合は、実際にブラウザ側で使うオリジンを確認して登録する。
10. Authorized redirect URIs を登録する
Authorized redirect URIs には、Google の認可画面を通過したあとに戻ってくる callback URL を登録する。
| 環境 | 例 |
|---|---|
| ローカル開発 | http://localhost:3000/api/auth/callback/google |
| ステージング | https://staging.example.com/api/auth/callback/google |
| 本番 | https://example.com/api/auth/callback/google |
ここはかなり大事。アプリ側の redirect_uri と Google Cloud Console 側の Authorized redirect URIs は完全一致している必要がある。
次の違いは、すべて別物として扱われる。
| 見るところ | 例 |
|---|---|
| スキーム | http と https |
| ドメイン | example.com と www.example.com |
| ポート | localhost:3000 と localhost:5173 |
| パス | /callback/google と /api/auth/callback/google |
末尾の / | /google と /google/ |
| 大文字小文字 | /Google と /google |
たとえば、Google Cloud Console にこれを登録しているとする。
https://example.com/api/auth/callback/googleアプリ側が次のように末尾の / 付きで送ると、合わないことがある。
https://example.com/api/auth/callback/google/この場合は redirect_uri_mismatch になる。
認証ライブラリを使う場合は、ライブラリが期待する callback URL をそのまま登録する。
| ライブラリ / 構成 | callback URL の例 |
|---|---|
| NextAuth.js / Auth.js | https://example.com/api/auth/callback/google |
| Laravel Socialite | https://example.com/auth/google/callback |
| Rails OmniAuth | https://example.com/auth/google_oauth2/callback |
| 独自実装 | アプリ側で指定した redirect_uri |
11. Client ID / Client Secret を保存する
OAuth クライアントを作成すると、Client ID と Client Secret が発行される。
サーバー側で認可コードをアクセストークンに交換する Web アプリでは、通常この2つを環境変数に入れる。
GOOGLE_CLIENT_ID=xxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=xxxxxxxxxxxxxxxxClient Secret はサーバー側だけで扱う。フロントエンドの JavaScript に埋め込まない。公開リポジトリにもコミットしない。
作成直後の画面で Client Secret をコピーし忘れた場合や、漏えいした可能性がある場合は、新しい Secret を作成して差し替える。
ブラウザだけで完結する Google Identity Services の構成では、Client Secret を使わないことがある。Secret を安全に保持できない場所には置かない。
12. アプリ側に OAuth 設定を入れる
Google Cloud Console 側の登録が終わったら、アプリ側に値を設定する。
例としては次のようになる。
GOOGLE_CLIENT_ID=xxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=xxxxxxxxxxxxxxxx
GOOGLE_REDIRECT_URI=https://example.com/api/auth/callback/google
GOOGLE_OAUTH_SCOPES=openid email profile https://www.googleapis.com/auth/calendar.eventsOAuth リクエストでよく使うパラメータは次のとおり。
| パラメータ | 内容 |
|---|---|
client_id | Google Cloud Console で発行した Client ID |
redirect_uri | 登録済みの redirect URI |
response_type | Web サーバーアプリでは通常 code |
scope | 要求するスコープ |
state | CSRF 対策用のランダムな値 |
access_type | リフレッシュトークンが必要なら offline |
include_granted_scopes | 段階的な権限追加をするなら true |
prompt | 再同意が必要な場合に consent を指定することがある |
ユーザーがいない状態でも Google API を呼び続けたいなら、リフレッシュトークンが必要になる。その場合は access_type=offline を指定する。
ただし、リフレッシュトークンは毎回返るものではない。初回同意時だけ返るケースがあるため、再取得が必要な場合は再同意フローを用意しておく。
13. テストユーザーで動作確認する
設定が終わったら、Audience に追加したテストユーザーで OAuth フローを確認する。
見るポイントは次のとおり。
| 確認項目 | 見る内容 |
|---|---|
| アカウント選択 | Google のアカウント選択画面に遷移するか |
| 同意画面 | アプリ名とスコープが想定どおりか |
| callback | 登録した redirect URI に戻ってくるか |
| 認可コード | アプリ側で code を受け取れているか |
| トークン交換 | アクセストークンを取得できるか |
| API 呼び出し | 必要な Google API を呼べるか |
| リフレッシュ | 必要ならリフレッシュトークンを保存できるか |
ここで失敗した場合、いきなりコードを疑う前に次を見る。
| 症状 | まず見る場所 |
|---|---|
| テストユーザーなのに進めない | Audience の Test users |
| callback に戻らない | Authorized redirect URIs |
| API だけ失敗する | API の有効化とスコープ |
| アプリ名が変 | Branding |
| 未確認アプリ警告が出る | Verification Center |
14. 本番公開前に Verification Center を確認する
外部ユーザーに提供するアプリでは、本番公開前に Verification Center を確認する。
Google API のスコープには、非センシティブ、センシティブ、制限付きの分類がある。Calendar、Drive、Gmail などのユーザーデータにアクセスするスコープでは、OAuth Verification が必要になることがある。
- Google Auth Platform の「Verification Center」を開く
- Branding の確認状況を見る
- Data Access の確認状況を見る
- 必要なスコープの使用理由を書く
- プライバシーポリシーやアプリ URL を確認する
- 必要に応じてデモ動画を用意する
- 審査申請を送信する
センシティブスコープの審査では、次のようなものを求められることがある。
| 項目 | 内容 |
|---|---|
| アプリ概要 | 何をするアプリか |
| スコープの使用理由 | なぜその権限が必要か |
| ユーザー操作の説明 | ユーザーがどこで連携するか |
| デモ動画 | OAuth 同意から API 利用までの流れ |
| プライバシーポリシー | データの利用目的や削除方法 |
| ドメイン所有権 | アプリのドメインを管理している証明 |
審査は数営業日で終わることもあるが、説明不足、動画不足、プライバシーポリシーの不備があると追加対応で長引く。
申請方法が誤っていると、単に差し戻されるだけでは済まない。確認する側がアプリの用途やスコープの必要性を判断できず、やり取りが増え、結果として審査の優先度が下がったような状態になりやすい。急いでいるときほど、とりあえず申請するのではなく、スコープの理由、操作手順、デモ動画、公開ページをそろえてから出す。
制限付きスコープの場合は、さらに厳しい確認やセキュリティ評価が必要になることがある。Gmail や Drive の広い権限を扱う場合は、早めに確認しておく。
スコープ選びの考え方
Google OAuth では、できるだけ狭いスコープを選ぶ。
Google Calendar 連携を例にすると、だいたい次のように考える。
| 要件 | 候補スコープ |
|---|---|
| 空き時間だけ取得したい | https://www.googleapis.com/auth/calendar.freebusy |
| 予定の詳細ではなく空き時間だけ扱いたい | https://www.googleapis.com/auth/calendar.events.freebusy |
| 予定一覧を読みたい | https://www.googleapis.com/auth/calendar.events.readonly |
| 予定を作成、更新、削除したい | https://www.googleapis.com/auth/calendar.events |
| カレンダー一覧を読みたい | https://www.googleapis.com/auth/calendar.calendarlist.readonly |
| カレンダー自体の設定を変更したい | https://www.googleapis.com/auth/calendar.calendars |
| カレンダーの共有権限も扱いたい | https://www.googleapis.com/auth/calendar.acls |
単に予定を作成したいだけなら、カレンダー全体の共有や削除まで可能な https://www.googleapis.com/auth/calendar を要求しなくてよいことが多い。
ユーザーから見ても、必要以上に広い権限を求められると不安になる。審査のためだけでなく、ユーザーに納得して連携してもらうためにも、権限は絞る。
よくあるエラー
Google OAuth 登録でよく見るエラーをまとめる。
| 症状 | 原因と対処 |
|---|---|
redirect_uri_mismatch | アプリ側の redirect_uri と Authorized redirect URIs が完全一致していない。末尾の /、ポート、http / https を確認する |
org_internal | User type が Internal になっている。一般公開アプリなら External にする |
access_denied | ユーザーが同意をキャンセルした、または Workspace 管理者がスコープを制限している |
invalid_client | Client ID / Client Secret が間違っている、または削除済みの OAuth クライアントを使っている |
invalid_grant | 認可コードやリフレッシュトークンが期限切れ、使用済み、または無効になっている |
403 Forbidden | API が有効化されていない、スコープが不足している、Workspace 管理者に制限されている |
| 「このアプリは確認されていません」 | センシティブまたは制限付きスコープを使っており、OAuth Verification が未完了 |
| リフレッシュトークンが返らない | access_type=offline を指定していない、または過去に同意済み。再同意フローを確認する |
redirect_uri_mismatch は本当によく出る。Google Cloud Console 側とアプリ側の URL を、文字列としてそのまま見比べるのが一番早い。
セキュリティ上の注意
OAuth クライアントを運用するときは、次の点に注意する。
| 注意点 | 理由 |
|---|---|
| Client Secret をフロントエンドに置かない | ブラウザ上の値はユーザーから見える |
| Client Secret を Git にコミットしない | 公開リポジトリから漏えいする |
| 本番用と開発用の Client を分ける | 設定変更の影響範囲を分けられる |
| 不要な redirect URI を消す | 使わない戻り先を残さない |
| 不要なスコープを消す | ユーザー同意と審査の負担を減らせる |
state を使う | CSRF 対策になる |
| トークンを安全に保存する | Google API へのアクセス権そのものだから |
| 連携解除の導線を用意する | ユーザーが後から取り消せるようにする |
OAuth は「ログインできたら終わり」ではない。ユーザーの Google アカウントデータにアクセスするための仕組みなので、何を許可してもらい、どう扱い、どう解除できるのかまで設計する。
まとめ
Google OAuth 登録でやることは多いが、分解すると次の流れになる。
- Google Cloud プロジェクトを作る
- 必要な API を有効化する
- Google Auth Platform で Branding を設定する
- Audience で公開範囲とテストユーザーを設定する
- Data Access でスコープを登録する
- Clients で Web application の OAuth クライアントを作る
- Authorized JavaScript origins と Authorized redirect URIs を登録する
- Client ID / Client Secret をアプリ側に設定する
- テストユーザーで OAuth フローを確認する
- 本番公開前に Verification Center を確認する
特に大事なのは、redirect URI を完全一致させることと、必要最小限のスコープを選ぶこと。
Google ログインだけなら比較的軽いが、Calendar、Drive、Gmail などのユーザーデータを扱う場合は、プライバシーポリシー、スコープの利用理由、デモ動画、ドメイン所有権の確認まで早めに準備しておくと進めやすい。申請内容が雑だと確認に時間がかかり、リリース直前の作業ほど後回しになりやすい。
弊社の Missete でも、Google OAuth を使って Google Calendar と連携し、複数カレンダーを扱うカレンダーアプリを開発している。OAuth 登録や審査準備は一度通れば終わりではなく、スコープ変更や本番公開のタイミングでまた確認が必要になるため、最初から手順を整理しておく価値がある。
参考リンク
- Google Cloud Console
- Configure the OAuth consent screen and choose scopes
- Using OAuth 2.0 for Web Server Applications
- Choose Google Calendar API scopes
- Sensitive scope verification
- Get started with the Google Auth Platform
- Manage OAuth Clients
この記事に関連するサービス
TodoONada株式会社では、認証基盤・ID管理の設計から開発・移行までを支援しています。
- 認証基盤・ID管理の開発支援 — IDaaS導入・SSO・パスキー・会員基盤の移行をワンストップで
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
