このドキュメントでは、スマートフォン、タブレット、パソコンなどのデバイスにインストールされたアプリケーションが、Google の OAuth 2.0 エンドポイントを使用して Google API へのアクセスを承認する方法について説明します。
OAuth 2.0 では、ユーザー名やパスワードなどの情報を秘密にしたまま、ユーザーが特定のデータをアプリケーションと共有できます。たとえば、アプリケーションで OAuth 2.0 を使い、Google ドライブにファイルを保存する許可をユーザーから取得できます。
インストールされたアプリは個々のデバイスに配布され、これらのアプリは秘密を保持できないと想定されます。ユーザーがアプリを使用している間や、アプリがバックグラウンドで実行されているときに、Google API にアクセスできます。
この認可フローは、ウェブサーバー アプリケーションで使用されるものに似ています。主な違いは、インストール済みのアプリは、Google の認可サーバーからのレスポンスを処理するために、システム ブラウザを開き、ローカル リダイレクト URI を指定しなければならない点です。
代替手段
モバイルアプリの場合は、Android または iOS 用の Google ログインを使用することをおすすめします。Google ログイン クライアント ライブラリは認証とユーザー認可を処理します。ここで説明する下位レベルのプロトコルよりも実装が簡単な場合があります。
システム ブラウザをサポートしていないデバイスや、入力機能が制限されているデバイス（テレビ、ゲーム コンソール、カメラ、プリンタなど）で実行されるアプリについては、TV とデバイス向け OAuth 2.0 または TV と入力機能が限られたデバイスでのログインをご覧ください。
ライブラリとサンプル
このドキュメントで説明する OAuth 2.0 フローを実装するには、次のライブラリとサンプルを使用することをおすすめします。
前提条件
プロジェクトでAPI を有効にする
Google API を呼び出すアプリケーションは、 でこれらの API を有効にする必要があります。
プロジェクトで API を有効にするには:
- の 。
- には、利用可能なすべての API がプロダクト ファミリーと人気度に応じて分類されて表示されます。有効にする API がリストで見当たらない場合は、検索して見つけるか、その API が属するプロダクト ファミリーの [すべて表示] をクリックします。
- 有効にする API を選択し、[有効にする] ボタンをクリックします。
承認認証情報を作成する
OAuth 2.0 を使用して Google API にアクセスするアプリケーションは、Google の OAuth 2.0 サーバーに対して自身の身元を示す認証情報を持つ必要があります。次の手順では、プロジェクトの認証情報を作成する方法について説明します。アプリケーションは、その認証情報を使用して、そのプロジェクトで有効にした API にアクセスできます。
- [認証情報を作成] > [OAuth クライアント ID] をクリックします。
- 以降のセクションでは、Google の認可サーバーがサポートするクライアント タイプについて説明します。アプリケーションに推奨されるクライアント タイプを選択し、OAuth クライアントに名前を付け、フォームの他のフィールドを適宜設定します。
Android
- アプリケーションの種類として [Android] を選択します。
- OAuth クライアントの名前を入力します。この名前は、クライアントを識別するためにプロジェクトの に表示されます。
- Android アプリのパッケージ名を入力します。この値は、アプリのマニフェスト ファイルの
<manifest>要素のpackage属性で定義されます。 - アプリ配信の SHA-1 署名証明書フィンガープリントを入力します。
- アプリが Google Play によるアプリ署名を使用している場合は、Google Play Console のアプリ署名ページから SHA-1 フィンガープリントをコピーします。
- 独自のキーストアと署名鍵を管理している場合は、Java に付属の keytool ユーティリティを使用して、証明書情報を人間が判読できる形式で出力します。keytool の出力の
Certificate fingerprintsセクションにあるSHA1の値をコピーします。詳しくは、Google APIs for Android ドキュメントのクライアントの認証をご覧ください。
- （省略可）Android アプリの所有権を確認します。
- [作成] をクリックします。
iOS
- アプリケーションの種類として [iOS] を選択します。
- OAuth クライアントの名前を入力します。この名前は、クライアントを識別するためにプロジェクトの に表示されます。
- アプリのバンドル ID を入力します。バンドル ID は、アプリの情報プロパティ リスト リソース ファイル（info.plist）の CFBundleIdentifier キーの値です。この値は、通常、Xcode プロジェクト エディタの [一般] ペインまたは [署名と機能] ペインに表示されます。バンドル ID は、Apple の App Store Connect サイトのアプリの [アプリ情報] ページの [全般情報] セクションにも表示されます。
App Check 機能を使用している場合、バンドル ID を変更できないため、アプリに正しいバンドル ID を使用していることを確認してください。
- （省略可）
アプリが Apple の App Store で公開されている場合は、アプリの App Store ID を入力します。ストア ID は、すべての Apple App Store の URL に含まれる数字の文字列です。
- iOS デバイスまたは iPadOS デバイスで Apple App Store アプリを開きます。
- 自分のアプリを探します。
- 共有ボタン（四角形と上矢印の記号）を選択します。
- [リンクをコピー] を選択します。
- リンクをテキスト エディタに貼り付けます。App Store ID は URL の末尾部分です。
例:
https://apps.apple.com/app/google/id284815942
- （省略可）
チーム ID を入力します。詳しくは、Apple デベロッパー アカウントのドキュメントのチーム ID を確認するをご覧ください。
注: クライアントで App Check を有効にする場合は、[チーム ID] フィールドが必要です。 - （省略可）
iOS アプリで App Check を有効にします。App Check を有効にすると、Apple の App Attest サービスを使用して、OAuth クライアントから送信された OAuth 2.0 リクエストが正規のものであり、アプリから送信されたものであることを確認します。これにより、アプリのなりすましのリスクを軽減できます。詳しくは、iOS アプリで App Check を有効にする方法をご覧ください。
- [作成] をクリックします。
UWP
- アプリケーションの種類として [ユニバーサル Windows プラットフォーム] を選択します。
- OAuth クライアントの名前を入力します。この名前は、クライアントを識別するためにプロジェクトの に表示されます。
- アプリの 12 文字の Microsoft Store ID を入力します。この値は、Microsoft Partner Center の [アプリ ID] ページの [アプリ管理] セクションで確認できます。
- [作成] をクリックします。
UWP アプリの場合、カスタム URI スキームは 39 文字以内にする必要があります。
アクセス スコープを特定する
スコープを指定すると、アプリケーションからのアクセス要求は必要なリソースのみに限定されるようになり、ユーザーはアプリケーションに付与するアクセスレベルを制御できます。そのため、リクエストするスコープの数とユーザーの同意を得られる可能性との間には逆相関関係がある可能性があります。
OAuth 2.0 認証の実装を開始する前に、アプリがアクセス権限を必要とするスコープを設定しておくことをおすすめします。
OAuth 2.0 API スコープのドキュメントには、Google API へのアクセスに使用できるスコープの完全なリストが記載されています。
OAuth 2.0 アクセス トークンの取得
次の手順は、アプリケーションが Google の OAuth 2.0 サーバーとやり取りして、ユーザーに代わって API リクエストを実行するためのユーザーの同意を得る方法を示しています。ユーザーの承認が必要な Google API リクエストを実行するには、アプリがその同意を得ている必要があります。
ステップ 1: コード検証ツールとチャレンジを生成する
Google は、インストールされたアプリフローのセキュリティを強化するために、Proof Key for Code Exchange（PKCE）プロトコルをサポートしています。認可リクエストごとに一意のコード ベリファイアが作成され、その変換された値（code_challenge）が認可サーバーに送信されて認可コードが取得されます。
コード検証ツールを作成する
code_verifier は、予約されていない文字 [A-Z] / [a-z] / [0-9] / 「-」/ 「.」/ 「_」/ 「~」を使用して、高エントロピーの暗号ランダム文字列です。最小長は 43 文字、最大長は 128 文字です。
コード検証ツールには、値を推測できないほど十分なエントロピーが必要です。
コード チャレンジを作成する
コード チャレンジの作成方法は 2 つあります。
| コードチャレンジの生成方法 | |
|---|---|
| S256（推奨） | コードチャレンジは、コード検証ツールの SHA256 ハッシュを Base64URL でエンコードしたものです（パディングなし）。
|
| plain | コードチャレンジは、上記で生成したコード検証ツールと同じ値です。
|
ステップ 2: Google の OAuth 2.0 サーバーにリクエストを送信する
ユーザーの承認を取得するには、https://accounts.google.com/o/oauth2/v2/auth の Google 認可サーバーにリクエストを送信します。このエンドポイントは、アクティブなセッションの検索、ユーザーの認証、ユーザーの同意の取得を処理します。エンドポイントには SSL 経由でのみアクセスでき、HTTP（SSL 以外）接続は拒否されます。
認可サーバーは、インストール済みアプリケーションの次のクエリ文字列パラメータをサポートしています。
| パラメータ | |||||||
|---|---|---|---|---|---|---|---|
client_id |
必須
アプリケーションのクライアント ID。この値は、 にあります。 |
||||||
redirect_uri |
必須
Google の認可サーバーがアプリにレスポンスを送信する方法を決定します。インストール済みのアプリで使用できるリダイレクト オプションはいくつかあり、特定のリダイレクト方法を念頭に置いて認可認証情報を設定します。 この値は、クライアントの
で構成した OAuth 2.0 クライアントの承認済みリダイレクト URI のいずれかと完全に一致している必要があります。この値が承認済みの URI と一致しない場合、 次の表に、各メソッドに適した
|
||||||
response_type |
必須
Google OAuth 2.0 エンドポイントが認可コードを返すかどうかを決定します。 インストール済みのアプリの場合は、パラメータ値を |
||||||
scope |
必須
アプリケーションがユーザーに代わってアクセスできるリソースを識別するスコープのスペース区切りリスト。これらの値は、Google がユーザーに表示する同意画面に通知されます。 スコープを指定すると、アプリケーションからのアクセス要求は必要なリソースのみに限定されるようになり、ユーザーはアプリケーションに付与するアクセスレベルを制御できます。したがって、リクエストするスコープの数とユーザーの同意を得られる可能性との間には逆相関関係があります。 |
||||||
code_challenge |
推奨
認証コードの交換時にサーバーサイド チャレンジとして使用されるエンコードされた |
||||||
code_challenge_method |
推奨
認証コード交換で使用される |
||||||
state |
推奨
認可リクエストと認可サーバーのレスポンス間で状態を維持するために、アプリケーションが使用する文字列値を指定します。ユーザーがアプリのアクセス リクエストに同意または拒否すると、サーバーは このパラメータは、アプリケーション内の正しいリソースにユーザーを誘導する、ノンスを送信する、クロスサイト リクエストのなりすましを軽減するなど、さまざまな目的で使用できます。 |
||||||
login_hint |
省略可
アプリケーションが認証を試行しているユーザーを把握している場合は、このパラメータを使用して Google 認証サーバーにヒントを提供できます。サーバーは、ログイン フォームのメール フィールドに事前入力するか、適切なマルチログイン セッションを選択することで、ログインフローを簡素化するためにヒントを使用します。 パラメータ値をメールアドレスまたは |
||||||
認証 URL の例
以下のタブには、さまざまなリダイレクト URI オプションの承認 URL の例を示します。
URL は、redirect_uri パラメータの値を除いて同じです。URL には、必須の response_type パラメータと client_id パラメータ、オプションの state パラメータも含まれます。各 URL には、読みやすくするために改行とスペースが含まれています。
カスタム URI スキーム
https://accounts.google.com/o/oauth2/v2/auth? scope=email%20profile& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=com.example.app%3A/oauth2redirect& client_id=client_id
ループバック IP アドレス
https://accounts.google.com/o/oauth2/v2/auth? scope=email%20profile& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=http%3A//127.0.0.1%3A9004& client_id=client_id
ステップ 3: Google がユーザーに同意を求めるメッセージが表示される
このステップで、ユーザーはリクエストされたアクセスをアプリに許可するかどうかを決定します。この段階で、Google から同意ウィンドウが表示されます。このウィンドウには、アプリケーションの名前と、ユーザーの認証情報を使用してアクセス権限をリクエストしている Google API サービス、および付与されるアクセス スコープの概要が表示されます。ユーザーは、アプリがリクエストした 1 つ以上のスコープへのアクセス権の付与に同意するか、リクエストを拒否できます。
この段階では、アクセスが許可されたかどうかを示す Google の OAuth 2.0 サーバーからのレスポンスを待機するため、アプリケーションは何もする必要はありません。このレスポンスについては、次のステップで説明します。
エラー
Google の OAuth 2.0 認可エンドポイントへのリクエストで、想定される認証フローと認可フローの代わりに、ユーザー向けのエラー メッセージが表示されることがあります。一般的なエラーコードと推奨される解決策は次のとおりです。
admin_policy_enforced
Google Workspace 管理者のポリシーにより、リクエストされた 1 つ以上のスコープを Google アカウントが承認できません。OAuth クライアント ID にアクセス権が明示的に付与されるまで、管理者がすべてのスコープまたは機密性の高いスコープと制限付きスコープへのアクセスを制限する方法については、Google Workspace 管理者向けのヘルプ記事「 Google Workspace のデータにアクセスできるサードパーティ製アプリと内部アプリを制御する」をご覧ください。
disallowed_useragent
認可エンドポイントが、Google の OAuth 2.0 ポリシーで禁止されている埋め込みユーザー エージェントの内部に表示されている。
Android
Android デベロッパーが android.webkit.WebView で認可リクエストを開くと、このエラー メッセージが表示されることがあります。代わりに、Android 版 Google ログインや OpenID Foundation の Android 版 AppAuth などの Android ライブラリを使用してください。
ウェブ デベロッパーは、Android アプリが埋め込まれたユーザー エージェントで一般的なウェブリンクを開き、ユーザーがサイトから Google の OAuth 2.0 認可エンドポイントに移動したときに、このエラーが発生することがあります。デベロッパーは、一般的なリンクをオペレーティング システムのデフォルトのリンク ハンドラで開くようにする必要があります。これには、Android アプリリンク ハンドラとデフォルトのブラウザ アプリの両方が含まれます。Android カスタムタブ ライブラリもサポートされているオプションです。
iOS
iOS と macOS のデベロッパーは、WKWebView で承認リクエストを開いたときに、このエラーが発生することがあります。デベロッパーは、代わりに Google ログイン for iOS や OpenID Foundation の AppAuth for iOS などの iOS ライブラリを使用する必要があります。
ウェブ デベロッパーがこのエラーに遭遇するのは、iOS または macOS アプリが埋め込まれたユーザー エージェントで一般的なウェブリンクを開き、ユーザーがサイトから Google の OAuth 2.0 認可エンドポイントに移動した場合です。開発者は、一般的なリンクがオペレーティング システムのデフォルトのリンク ハンドラで開くようにする必要があります。これには、ユニバーサル リンク ハンドラとデフォルトのブラウザ アプリの両方が含まれます。SFSafariViewController ライブラリもサポートされているオプションです。
org_internal
リクエストの OAuth クライアント ID は、特定の Google Cloud 組織内の Google アカウントへのアクセスを制限するプロジェクトの一部です。この構成オプションの詳細については、OAuth 同意画面の設定に関するヘルプ記事のユーザーの種類をご覧ください。
invalid_grant
コード検証ツールとチャレンジを使用している場合、code_callenge パラメータが無効であるか、指定されていません。code_challenge パラメータが正しく設定されていることを確認します。
アクセス トークンを更新するときに、トークンの有効期限が切れているか、無効になっている可能性があります。 ユーザーを再度認証し、新しいトークンを取得するためのユーザーの同意を求めます。このエラーが引き続き表示される場合は、アプリケーションが正しく構成されていること、およびリクエストで正しいトークンとパラメータを使用していることを確認してください。そうでない場合は、ユーザー アカウントが削除または無効になっている可能性があります。
redirect_uri_mismatch
認可リクエストで渡された redirect_uri が、OAuth クライアント ID の承認済みリダイレクト URI と一致しません。 で承認済みのリダイレクト URI を確認します。
渡された redirect_uri がクライアント タイプに対して無効な可能性があります。
redirect_uri パラメータは、非推奨でサポートされていない OAuth 帯域外（OOB）フローを参照している可能性があります。統合を更新するには、移行ガイドをご覧ください。
invalid_request
リクエストに問題がありました。これには次のような理由が考えられます。
- リクエストの形式が正しくありません
- リクエストに必須のパラメータが指定されていません
- このリクエストで使用されている認証方法は Google でサポートされていません。OAuth 統合で推奨される統合方法が使用されていることを確認する
- リダイレクト URI にカスタム スキームが使用されている : カスタム URI スキームは Chrome アプリでサポートされていませんまたはカスタム URI スキームは Android クライアントで有効になっていませんというエラー メッセージが表示される場合は、Chrome アプリではサポートされていないカスタム URI スキームが使用されており、Android ではデフォルトで無効になっていることを意味します。カスタム URI スキームの代替方法の詳細
ステップ 4: OAuth 2.0 サーバー レスポンスを処理する
アプリが認可レスポンスを受信する方法は、使用するリダイレクト URI スキームによって異なります。スキームに関係なく、レスポンスには認証コード（code）またはエラー（error）が含まれます。たとえば、error=access_denied はユーザーがリクエストを拒否したことを示します。
ユーザーがアプリケーションへのアクセスを許可した場合は、次の手順で認可コードをアクセス トークンと更新トークンと交換できます。
ステップ 5: 認可コードを更新トークンとアクセス トークンと交換する
認証コードをアクセス トークンと交換するには、https://oauth2.googleapis.com/token エンドポイントを呼び出して、次のパラメータを設定します。
| フィールド | |
|---|---|
client_id |
から取得したクライアント ID。 |
client_secret |
から取得したクライアント シークレット。 |
code |
最初のリクエストから返された認証コード。 |
code_verifier |
ステップ 1 で作成したコード検証ツール。 |
grant_type |
OAuth 2.0 仕様で定義されているように、このフィールドの値は authorization_code に設定する必要があります。 |
redirect_uri |
指定された client_id の
に、プロジェクトにリストされているリダイレクト URI のいずれか。 |
次のスニペットは、サンプル リクエストを示しています。
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7& client_id=your_client_id& client_secret=your_client_secret& redirect_uri=http://127.0.0.1:9004& grant_type=authorization_code
Google は、このリクエストに応答して、有効期間の短いアクセス トークンと更新トークンを含む JSON オブジェクトを返します。
レスポンスには、次のフィールドが含まれます。
| フィールド | |
|---|---|
access_token |
アプリケーションが Google API リクエストを承認するために送信するトークン。 |
expires_in |
アクセス トークンの残り有効期間（秒単位）。 |
id_token |
注: このプロパティは、リクエストに ID スコープ（openid、profile、email など）が含まれている場合にのみ返されます。この値は、ユーザーに関するデジタル署名付き ID 情報を含む JSON Web Token（JWT）です。 |
refresh_token |
新しいアクセス トークンの取得に使用できるトークン。更新トークンは、ユーザーがアクセス権を取り消すまで有効です。インストール済みのアプリに対しては、常にリフレッシュ トークンが返されます。 |
scope |
access_token によって付与されるアクセス スコープ。スペース区切りの大文字と小文字を区別する文字列のリストとして表されます。 |
token_type |
返されるトークンのタイプ。現時点では、このフィールドの値は常に Bearer に設定されます。 |
次のスニペットは、サンプル レスポンスを示しています。
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
ステップ 6: ユーザーが付与したスコープを確認する
複数のスコープを一度にリクエストする場合、ユーザーがアプリがリクエストするすべてのスコープを許可しないことがあります。アプリは、ユーザーによって付与されたスコープを常に確認し、スコープの拒否が発生した場合は関連する機能を無効にして対処する必要があります。詳細については、きめ細かい権限を処理する方法をご覧ください。
ユーザーがアプリケーションに特定のスコープへのアクセス権を付与しているかどうかを確認するには、アクセス トークン レスポンスの scope フィールドを確認します。access_token によって付与されたアクセス権のスコープ。スペース区切りの大文字と小文字を区別する文字列のリストとして表されます。
たとえば、次のアクセス トークンのレスポンス サンプルは、ユーザーがアプリにドライブ アクティビティとカレンダー イベントの読み取り専用権限へのアクセスを許可したことを示しています。
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Google API の呼び出し
アプリケーションがアクセス トークンを取得すると、API で必要なアクセス権が付与されている場合は、そのトークンを使用して特定のユーザー アカウントの代わりに Google API を呼び出すことができます。これを行うには、access_token クエリ パラメータまたは Authorization HTTP ヘッダー Bearer 値のいずれかを含めて、API へのリクエストにアクセス トークンを含めます。クエリ文字列はサーバーログに表示されるため、可能であれば HTTP ヘッダーを使用することをおすすめします。ほとんどの場合、クライアント ライブラリを使用して Google API への呼び出しを設定できます（Drive Files API を呼び出す場合など）。
すべての Google API を試して、そのスコープを確認するには、OAuth 2.0 Playground をご覧ください。
HTTP GET の例
Authorization: Bearer HTTP ヘッダーを使用して
drive.files エンドポイント（Drive Files API）を呼び出す場合、呼び出しは次のようになります。独自のアクセス トークンを指定する必要があります。
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
以下は、access_token クエリ文字列パラメータを使用して、認証済みユーザーの同じ API を呼び出すコードです。
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl の例
これらのコマンドは、curl コマンドライン アプリケーションでテストできます。HTTP ヘッダー オプションを使用する例を次に示します（推奨）。
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
または、クエリ文字列パラメータ オプションを使用します。
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
アクセス トークンをリフレッシュする
アクセス トークンは定期的に期限が切れ、関連する API リクエストに対して無効な認証情報になります。トークンに関連付けられたスコープへのオフライン アクセスをリクエストした場合は、ユーザーに権限を求めることなくアクセス トークンを更新できます（ユーザーが不在の場合を含めて）。
アクセス トークンを更新するには、アプリケーションが Google の認可サーバーに HTTPS POST リクエストを送信します。このリクエストには、次のパラメータが含まれます。https://oauth2.googleapis.com/token
| フィールド | |
|---|---|
client_id |
から取得したクライアント ID。 |
client_secret |
から取得したクライアント シークレット。（client_secret は、Android、iOS、Chrome アプリとして登録されたクライアントからのリクエストには適用されません）。
|
grant_type |
OAuth 2.0 仕様で定義されているように、このフィールドの値は refresh_token に設定する必要があります。 |
refresh_token |
認証コード交換から返された更新トークン。 |
次のスニペットは、サンプル リクエストを示しています。
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=your_client_id& client_secret=your_client_secret& refresh_token=refresh_token& grant_type=refresh_token
ユーザーがアプリケーションに付与されたアクセス権を取り消していない限り、トークン サーバーは新しいアクセス トークンを含む JSON オブジェクトを返します。次のスニペットは、サンプル レスポンスを示しています。
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly", "token_type": "Bearer" }
発行される更新トークンの数には上限があります。クライアントとユーザーの組み合わせごとに 1 つ、すべてのクライアントのユーザーごとに 1 つです。更新トークンは長期ストレージに保存し、有効である限り引き続き使用する必要があります。アプリがリフレッシュ トークンを過度にリクエストすると、これらの上限に達することがあります。その場合、古いリフレッシュ トークンは機能しなくなります。
トークンの取り消し
ユーザーがアプリに付与したアクセス権を取り消す場合もあります。ユーザーは、[ アカウント設定] にアクセスしてアクセス権を取り消すことができます。詳しくは、アカウントにアクセスできるサードパーティのサイトやアプリのサポート ドキュメントの「サイトやアプリのアクセス権を削除する」をご覧ください。
アプリが、付与されたアクセス権をプログラムで取り消すことも可能です。プログラムによる取り消しは、ユーザーが定期購入を解約したり、アプリを削除したり、アプリに必要な API リソースが大幅に変更されたりした場合に重要です。つまり、削除プロセスの一部として、アプリに以前付与された権限が確実に削除されるように API リクエストを含めることができます。
プログラムでトークンを取り消すには、アプリが https://oauth2.googleapis.com/revoke にリクエストを行い、トークンをパラメータとして含めます。
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}トークンは、アクセス トークンまたは更新トークンです。トークンがアクセス トークンで、対応する更新トークンがある場合、更新トークンも取り消されます。
取り消しが正常に処理されると、レスポンスの HTTP ステータス コードは 200 になります。エラー状態の場合、エラーコードとともに HTTP ステータス コード 400 が返されます。
アプリのリダイレクト方法
カスタム URI スキーム（Android、iOS、UWP）
カスタム URI スキームは、カスタム定義スキームを使用してアプリを開くディープリンクの一種です。
Android でカスタム URI スキームを使用する方法の代替手段
Google ログイン for Android SDK を使用すると、OAuth 2.0 レスポンスがアプリに直接配信されるため、リダイレクト URI は不要になります。
Google ログイン for Android SDK に移行する方法
Android で OAuth 統合にカスタム スキームを使用している場合は、推奨される Google ログイン for Android SDK の使用に完全に移行するために、次の操作を行う必要があります。
- Google Sign-In SDK を使用するようにコードを更新します。
- Google API Console でカスタム スキームのサポートを無効にする。
Google ログイン Android SDK に移行する手順は次のとおりです。
-
Google ログイン Android SDK を使用するようにコードを更新します。
-
コードを調べて、Google の OAuth 2.0 サーバーにリクエストを送信している場所を特定します。カスタム スキームを使用している場合、リクエストは次のようになります。
https://accounts.google.com/o/oauth2/v2/auth? scope=<SCOPES>& response_type=code& &state=<STATE>& redirect_uri=com.example.app:/oauth2redirect& client_id=<CLIENT_ID>
com.example.app:/oauth2redirectは、上記の例のカスタム スキームのリダイレクト URI です。カスタム URI スキーム値の形式の詳細については、redirect_uriパラメータ定義をご覧ください。 -
Google ログイン SDK の構成に必要な
scopeリクエスト パラメータとclient_idリクエスト パラメータをメモします。 -
Android アプリへの Google ログインの統合を開始するの手順に沿って SDK を設定します。前の手順で取得した
client_idを再利用するため、バックエンド サーバーの OAuth 2.0 クライアント ID を取得する手順はスキップできます。 -
サーバーサイド API アクセスの有効化の手順に沿って操作します。このフローには次の手順が含まれます。
-
getServerAuthCodeメソッドを使用して、権限をリクエストするスコープの認証コードを取得します。 - 認証コードをアプリのバックエンドに送信し、アクセス トークンと更新トークンと交換します。
- 取得したアクセス トークンを使用して、ユーザーに代わって Google API を呼び出します。
-
-
コードを調べて、Google の OAuth 2.0 サーバーにリクエストを送信している場所を特定します。カスタム スキームを使用している場合、リクエストは次のようになります。
-
Google API Console でカスタム スキームのサポートを無効にします。
- [OAuth 2.0 認証情報] リストに移動し、Android クライアントを選択します。
- [詳細設定] セクションに移動し、[カスタム URI スキームを有効にする] チェックボックスをオフにして [保存] をクリックし、カスタム URI スキームのサポートを無効にします。
カスタム URI スキームを有効にする
推奨される代替方法が機能しない場合は、以下の手順に沿って Android クライアントのカスタム URI スキームを有効にできます。- [OAuth 2.0 認証情報] リストに移動し、Android クライアントを選択します。
- [詳細設定] セクションに移動し、[カスタム URI スキームを有効にする] チェックボックスをオンにして、[保存] をクリックして、カスタム URI スキームのサポートを有効にします。
Chrome アプリでカスタム URI スキームを使用する方法の代替手段
Chrome Identity API を使用する。OAuth 2.0 レスポンスがアプリに直接配信されるため、リダイレクト URI は不要です。
ループバック IP アドレス（macOS、Linux、Windows デスクトップ）
この URL を使用して認可コードを受け取るには、アプリケーションがローカル ウェブサーバーをリッスンしている必要があります。これは多くのプラットフォームで可能ですが、すべてのプラットフォームで可能なわけではありません。ただし、プラットフォームがサポートしている場合は、認証コードを取得するための推奨メカニズムです。
アプリが認可レスポンスを受け取ったら、ブラウザを閉じてアプリに戻るようユーザーに指示する HTML ページを表示して、使い勝手を最適化する必要があります。
| 推奨される使用方法 | macOS、Linux、Windows のデスクトップ アプリ（ユニバーサル Windows プラットフォーム アプリは除く） |
| フォームの値 | アプリケーション タイプを [デスクトップ アプリ] に設定します。 |
手動コピー/貼り付け（非推奨）
アプリを保護する
アプリの所有権を確認する（Android、Chrome）
アプリの所有権を確認することで、アプリのなりすましのリスクを軽減できます。
Android
確認プロセスを完了するには、Google Play デベロッパー アカウント（アプリが Google Play Console に登録されている場合）を使用できます。確認を完了するには、次の要件を満たす必要があります。
- 確認を行う Android OAuth クライアントと同じパッケージ名と SHA-1 署名証明書フィンガープリントを持つアプリが Google Play Console に登録されている必要があります。
- Google Play Console でアプリの管理者権限が必要です。Google Play Console でのアクセス管理の詳細については、こちらをご覧ください。
Android クライアントの [アプリの所有権を確認] セクションで、[所有権を確認] ボタンをクリックして確認プロセスを完了します。
確認が成功すると、確認プロセスの成功を確認する通知が表示されます。一致しない場合、エラー メッセージが表示されます。
所有権の確認に失敗した場合は、次の手順をお試しください。
- 確認するアプリが Google Play Console に登録されているアプリであることを確認します。
- Google Play Console で、アプリの管理者権限があることを確認します。
Chrome
確認プロセスを完了するには、Chrome ウェブストア デベロッパー アカウントを使用します。 確認を完了するには、次の要件を満たす必要があります。
- Chrome ウェブストア デベロッパー ダッシュボードに、確認を完了する Chrome 拡張機能の OAuth クライアントと同じアイテム ID を持つアイテムが登録されている必要があります。
- Chrome ウェブストア アイテムのパブリッシャーである必要があります。 Chrome ウェブストア デベロッパー ダッシュボードでのアクセス管理の詳細については、こちらをご覧ください。
Chrome 拡張機能クライアントの [アプリの所有権を確認] セクションで、[所有権を確認] ボタンをクリックして確認プロセスを完了します。
注: アカウントへのアクセス権を付与した後、検証プロセスを完了するまで数分待ちます。
確認が成功すると、確認プロセスの成功を確認する通知が表示されます。一致しない場合、エラー メッセージが表示されます。
所有権の確認に失敗した場合は、次の手順をお試しください。
- Chrome ウェブストア デベロッパー ダッシュボードに、確認を完了する Chrome 拡張機能の OAuth クライアントと同じアイテム ID のアイテムが登録されていることを確認します。
- アプリのパブリッシャーであること。つまり、アプリの個別パブリッシャーまたはアプリのグループ パブリッシャーのメンバーであること。 アクセス管理について詳しくは、Chrome ウェブストア デベロッパー ダッシュボードの詳細をご覧ください。
- グループ パブリッシャーのリストを更新したばかりの場合は、Chrome ウェブストア デベロッパー ダッシュボードで、グループ パブリッシャーのメンバーシップ リストが同期されていることを確認します。パブリッシャー メンバーシップ リストの同期について詳しくは、こちらをご覧ください。
App Check（iOS のみ）
App Check 機能は、Apple の App Attest サービスを使用して、Google OAuth 2.0 エンドポイントに対して行われたリクエストが正規のアプリから発信されていることを確認することで、iOS アプリの不正使用を防ぐのに役立ちます。これにより、アプリの権限の不正使用のリスクを軽減できます。
iOS クライアントで App Check を有効にする
iOS クライアントで App Check を正常に有効にするには、次の要件を満たす必要があります。- iOS クライアントのチーム ID を指定する必要があります。
- バンドル ID にワイルドカードを使用することはできません。ワイルドカードは複数のアプリに解決される可能性があるためです。つまり、バンドル ID にアスタリスク（*）記号を含めることはできません。
App Check を有効にすると、OAuth クライアントの編集ビューに、クライアントからの OAuth リクエストに関連する指標が表示されます。App Check を適用するまで、未確認のソースからのリクエストはブロックされません。指標モニタリング ページの情報は、適用を開始するタイミングを判断するのに役立ちます。
iOS アプリで App Check を有効にすると、App Check 機能に関連するエラーが表示されることがあります。このようなエラーを解決するには、次の手順を試してください。
- 指定したバンドル ID とチーム ID が有効であることを確認します。
- バンドル ID にワイルドカードを使用していないことを確認します。
iOS クライアントに App Check を適用する
アプリで App Check を有効にしても、認識されないリクエストが自動的にブロックされることはありません。この保護を適用するには、iOS クライアントの編集ビューに移動します。ページの右側にある [Google Identity for iOS] セクションに、App Check の指標が表示されます。指標には次の情報が含まれます。- 確認済みリクエストの数 - 有効な App Check トークンを含むリクエストの数。App Check の適用を有効にすると、このカテゴリのリクエストのみが成功します。
- 未検証のリクエスト数: 古いクライアント リクエストの可能性 - App Check トークンのないリクエスト。これらのリクエストは、App Check の実装が含まれていない古いバージョンのアプリからのものである可能性があります。
- 未確認リクエストの数: 送信元が不明なリクエスト - App Check トークンのないリクエストで、アプリから送信されていない可能性があります。
- 未検証のリクエスト数: 無効なリクエスト - 無効な App Check トークンを含むリクエスト。お客様のアプリになりすまそうと試みている偽のクライアント、またはエミュレートされた環境からのものである可能性があります。
App Check を適用するには、[ENFORCE] ボタンをクリックして選択内容を確定します。適用が有効になると、クライアントからの未検証のリクエストはすべて拒否されます。
注: 適用を有効にした後、変更が有効になるまでに最大で 15 分ほどかかります。
iOS クライアントの App Check の適用を解除する
アプリの App Check の適用を解除すると、適用が停止し、未検証のリクエストを含む、クライアントから Google OAuth 2.0 エンドポイントへのすべてのリクエストが許可されます。
iOS クライアントの App Check の適用を解除するには、iOS クライアントの編集ビューに移動し、[適用を解除] ボタンをクリックして選択内容を確認します。
注: App Check の適用を解除した後、変更が有効になるまでに最長で 15 分ほどかかることがあります。
iOS クライアントの App Check を無効にする
アプリで App Check を無効にすると、App Check のすべてのモニタリングと適用が停止します。代わりに App Check を適用しないことを検討し、クライアントの指標のモニタリングを継続してください。
iOS クライアントで App Check を無効にするには、iOS クライアントの編集ビューに移動し、[Firebase App Check を使用して、OAuth クライアントを不正行為から保護します] 切り替えボタンをオフにします。
注: App Check を無効にした後、変更が有効になるまでに最長で 15 分ほどかかることがあります。
関連情報
IETF の現在のベスト プラクティスである ネイティブ アプリ向けの OAuth 2.0 では、ここで説明するベスト プラクティスの多くが定められています。
クロスアカウント保護機能の実装
ユーザーのアカウントを保護するために、Google のクロスアカウント保護サービスを利用したクロスアカウント保護を実装することもおすすめします。このサービスを使用すると、セキュリティ イベント通知を定期購読して、ユーザー アカウントの大きな変更に関する情報をアプリに提供できます。その後、イベントへの対応方法に応じて、この情報に基づいてアクションを実行できます。
Google のクロスアカウント保護サービスからアプリに送信されるイベントの種類には、次のものがあります。
-
https://schemas.openid.net/secevent/risc/event-type/sessions-revoked -
https://schemas.openid.net/secevent/oauth/event-type/token-revoked -
https://schemas.openid.net/secevent/risc/event-type/account-disabled
クロスアカウント保護の実装方法と利用可能なイベントの一覧については、 クロスアカウント保護でユーザー アカウントを保護する をご覧ください。