このドキュメントでは、スマートフォン、タブレット、パソコンなどのデバイスにインストールされたアプリケーションが、Google の OAuth 2.0 エンドポイントを使用して YouTube アナリティクス API または YouTube レポート API へのアクセスを承認する方法について説明します。
OAuth 2.0 を使用すると、ユーザーはユーザー名、パスワード、その他の情報を非公開のまま、特定のデータをアプリケーションと共有できます。 たとえば、アプリケーションは OAuth 2.0 を使用して、チャンネルの YouTube アナリティクス データを取得する権限を取得できます。
インストールされたアプリは個々のデバイスに配布され、これらのアプリは秘密を保持できないものと想定されます。ユーザーがアプリを使用しているときや、アプリがバックグラウンドで実行されているときに、Google API にアクセスできます。
この承認フローは、ウェブサーバー アプリケーションで使用されるフローに似ています。主な違いは、インストールされたアプリはシステム ブラウザを開いて、Google の認証サーバーからの応答を処理するためにローカル リダイレクト URI を指定する必要があることです。
ライブラリとサンプル
iOS アプリの場合は、 Sign In With Google iOS SDK の最新バージョンを使用することをおすすめします。SDK はユーザー認証を処理し、このガイドで説明されている低レベルのプロトコルよりも実装が簡単です。
システム ブラウザをサポートしていないデバイスや、入力機能が制限されているデバイス（テレビ、ゲーム機、カメラ、プリンターなど）で実行されるアプリについては、テレビとデバイス向けの OAuth 2.0 または テレビや入力機能が制限されているデバイスでのログインをご覧ください。
前提条件
プロジェクトでAPI を有効にする
Google API を呼び出すアプリケーションは、 API Console。
プロジェクトで API を有効にするには:
- Open the API Library の中で Google API Console。
- If prompted, select a project, or create a new one.
- ライブラリ ページを使用して、YouTube アナリティクス API と YouTube レポート API を見つけて有効にします。YouTube アナリティクス データを取得する多くのアプリケーションは、YouTube Data API ともインターフェースします。アプリケーションが使用する他の API を見つけて、それらも有効にします。
承認認証情報を作成する
OAuth 2.0 を使用して Google API にアクセスするアプリケーションには、Google の OAuth 2.0 サーバーに対してアプリケーションを識別する認証資格情報が必要です。次の手順では、プロジェクトの資格情報を作成する方法について説明します。アプリケーションは、その資格情報を使用して、そのプロジェクトに対して有効にした API にアクセスできるようになります。
- Go to the Clients page.
- [クライアントの作成] をクリックします。
- 以降のセクションでは、Google の認可サーバーがサポートするクライアント タイプについて説明します。アプリケーションに推奨されるクライアント タイプを選択し、OAuth クライアントに名前を付け、フォームの他のフィールドを適宜設定します。
iOS
- アプリケーションの種類として [iOS] を選択します。
- OAuth クライアントの名前を入力します。この名前はプロジェクトの Clients page クライアントを識別します。
- アプリのバンドル ID を入力します。バンドル ID は、アプリの情報プロパティ リスト リソース ファイル（info.plist）の CFBundleIdentifier キーの値です。この値は、通常、Xcode プロジェクト エディタの [General] ペインまたは [Signing & Capabilities] ペインに表示されます。バンドル ID は、Apple の App Store Connect サイトのアプリの [App Information] ページの [General Information] セクションにも表示されます。
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 Developer Account のドキュメントのチーム ID を確認するをご覧ください。
注: クライアントで App Check を有効にする場合は、[チーム ID] フィールドが必要です。 - （省略可）
iOS アプリで App Check を有効にします。App Check を有効にすると、Apple の App Attest サービスが使用され、OAuth クライアントから送信された OAuth 2.0 リクエストが正規のものであり、アプリから送信されたものであることが確認されます。これにより、アプリのなりすましのリスクを軽減できます。iOS アプリで App Check を有効にする方法の詳細。
- [作成] をクリックします。
UWP
- [ユニバーサル Windows プラットフォーム] アプリケーションの種類を選択します。
- OAuth クライアントの名前を入力します。この名前は、クライアントを識別するためにプロジェクトの Clients page に表示されます。
- アプリの 12 文字の Microsoft Store ID を入力します。この値は、Microsoft パートナー センターの [アプリ管理] セクションにある [アプリ ID] ページで確認できます。
- [作成] をクリックします。
UWP アプリの場合、リダイレクト URI はアプリケーションの一意のパッケージ セキュリティ識別子 (SID) を使用して形成されます。アプリのPackage SIDの中でPackage.appxmanifestVisual Studio プロジェクト内のファイル。
Google Cloud コンソールでクライアント ID を作成するときは、パッケージ SID の小文字の値を使用して、次の形式でリダイレクト URI を指定する必要があります。
ms-app://YOUR_APP_PACKAGE_SID
UWP アプリの場合、カスタム URI スキームは Microsoft のドキュメントで指定されているように、39 文字以内でなければなりません。
アクセススコープを特定する
スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみを要求できるようになり、ユーザーはアプリケーションに付与するアクセスの量を制御できるようになります。したがって、要求されるスコープの数とユーザーの同意を得られる可能性との間には逆相関関係がある可能性があります。
OAuth 2.0 認証の実装を開始する前に、アプリがアクセス権限を必要とするスコープを設定しておくことをおすすめします。
<YouTube アナリティクス API では、次のスコープが使用されます。
| 範囲 | 説明 |
|---|---|
https://www. |
YouTube アカウントの管理 |
https://www. |
YouTube アカウントの表示 |
https://www. |
YouTube のアセットや関連するコンテンツの表示と管理 |
https://www. |
YouTube コンテンツに関する YouTube アナリティクスの収益レポートと非収益レポートの表示 |
https://www. |
YouTube コンテンツの YouTube アナリティクス レポートの表示 |
YouTube Reporting API では、次のスコープが使用されます。
| 範囲 | 説明 |
|---|---|
https://www. |
YouTube コンテンツに関する YouTube アナリティクスの収益レポートと非収益レポートの表示 |
https://www. |
YouTube コンテンツの YouTube アナリティクス レポートの表示 |
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（推奨） | コードチャレンジは、コード検証ツールの Base64URL（パディングなし）でエンコードされた SHA256 ハッシュです。
|
| plain | コードチャレンジは、上記で生成されたコード検証ツールと同じ値です。
|
ステップ 2: Google の OAuth 2.0 サーバーにリクエストを送信する
ユーザーの承認を取得するには、https://accounts.google.com/o/oauth2/v2/auth の Google 認可サーバーにリクエストを送信します。このエンドポイントは、アクティブなセッションのルックアップを処理し、ユーザーを認証して、ユーザーの同意を取得します。このエンドポイントは SSL 経由でのみアクセス可能で、HTTP（非 SSL）接続は拒否されます。
認証サーバーは、インストール済みアプリに対して次のクエリ文字列パラメータをサポートしています。
| パラメータ | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
必須
アプリケーションのクライアント ID。この値は、 Cloud Console Clients pageにあります。 |
||||||||||||||||||
redirect_uri |
必須
Google の認可サーバーがアプリにレスポンスを送信する方法を決定します。インストール済みアプリには複数のリダイレクト オプションがあり、特定のメソッドを念頭に置いて認可情報を設定する必要があります。 この値は、クライアントの Cloud Console
Clients pageで構成した OAuth 2.0 クライアントの承認済みリダイレクト URI のいずれかと完全に一致する必要があります。この値が承認済み URI と一致しない場合、 次の表に、各メソッドの適切な
|
||||||||||||||||||
response_type |
必須
Google OAuth 2.0 エンドポイントが認証コードを返すかどうかを決定します。 パラメータ値を |
||||||||||||||||||
scope |
必須
アプリケーションがユーザーに代わってアクセスできるリソースを識別する、スペースで区切られたスコープのリスト。これらの値は、Google がユーザーに対して表示する同意画面に反映されます。 スコープを使用すると、アプリケーションは必要なリソースへのアクセスのみを要求できるようになり、ユーザーはアプリケーションに付与するアクセスの量を制御できるようになります。したがって、要求されるスコープの数とユーザーの同意を得られる可能性との間には逆相関関係があります。 YouTube アナリティクス API は次のスコープを使用します。
YouTube Reporting API は次のスコープを使用します。
OAuth 2.0 API スコープのドキュメントには、Google API へのアクセスに使用できるスコープの完全なリストが記載されています。 |
||||||||||||||||||
code_challenge |
おすすめ
エンコードされた |
||||||||||||||||||
code_challenge_method |
おすすめ
エンコードに使用された方法を指定します |
||||||||||||||||||
state |
おすすめ
承認リクエストと承認サーバーの応答間の状態を維持するためにアプリケーションが使用する任意の文字列値を指定します。
サーバーは送信した値を正確に返します。 このパラメータは、ユーザーをアプリケーション内の正しいリソースに誘導したり、ナンスを送信したり、クロスサイトリクエストフォージェリを軽減したりするなど、さまざまな目的で使用できます。あなたの |
||||||||||||||||||
login_hint |
オプション
アプリケーションが認証しようとしているユーザーを認識している場合は、このパラメータを使用して Google 認証サーバーにヒントを提供できます。サーバーはヒントを使用して、サインイン フォームの電子メール フィールドを事前に入力するか、適切なマルチログイン セッションを選択することで、ログイン フローを簡素化します。 パラメータ値をメールアドレスに設定するか、 |
||||||||||||||||||
認証 URL の例
以下のタブには、さまざまなリダイレクト URI オプションの認証 URL の例が示されています。
各 URL は、ユーザーの YouTube アナリティクス レポートの取得を許可するスコープへのアクセスをリクエストします。redirect_uri パラメータの値を除いて、URL は同じです。URL には、必須の response_type パラメータと client_id パラメータ、オプションの state パラメータも含まれています。各 URL には、読みやすくするために改行とスペースが含まれています。
カスタム URI スキーム
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly& 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=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly& 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 アカウントの Google Workspace 管理者のポリシーにより、リクエストされた 1 つ以上のスコープを承認できません。管理者が OAuth クライアント ID に明示的にアクセス権を付与するまで、すべてのスコープまたは機密性の高い制限付きスコープへのアクセスを制限する方法について詳しくは、Google Workspace 管理者向けヘルプ記事の Google Workspace のデータにアクセスできるサードパーティ製アプリと内部アプリを制御するをご覧ください。
disallowed_useragent
認可エンドポイントは、Google の OAuth 2.0 ポリシーで禁止されている埋め込みユーザー エージェント内に表示されます。
iOS と macOS のデベロッパーは、WKWebView で承認リクエストを開くときにこのエラーが発生することがあります。代わりに、デベロッパーは Google Sign-In for iOS や OpenID Foundation の AppAuth for iOS などの iOS ライブラリを使用する必要があります。
ウェブ デベロッパーは、iOS または macOS アプリが埋め込みユーザー エージェントで一般的なウェブリンクを開き、ユーザーがサイトから Google の OAuth 2.0 認可エンドポイントに移動したときに、このエラーに遭遇する可能性があります。デベロッパーは、ユニバーサル リンク ハンドラまたはデフォルトのブラウザアプリを含む、オペレーティング システムのデフォルトのリンク ハンドラで一般的なリンクを開けるようにする必要があります。SFSafariViewController ライブラリもサポートされているオプションです。
org_internal
リクエストの OAuth クライアント ID は、特定の Google Cloud 組織内の Google アカウントへのアクセスを制限するプロジェクトの一部です。この構成オプションの詳細については、OAuth 同意画面の設定に関するヘルプ記事のユーザータイプのセクションをご覧ください。
deleted_client
リクエストの作成に使用されている OAuth クライアントが削除されました。削除は、手動で行うことも、未使用のクライアント の場合は自動で行うこともできます。削除したクライアントは、削除後 30 日以内であれば復元できます。詳細 。
invalid_grant
を使用している場合コード検証とチャレンジ、code_callengeパラメータが無効または見つかりません。確実にcode_challengeパラメータが正しく設定されています。
アクセス トークンを更新する際、トークンの有効期限が切れているか、無効になっている可能性があります。 ユーザーを再度認証し、新しいトークンを取得するためにユーザーの同意を求めます。このエラーが引き続き発生する場合は、アプリケーションが正しく構成され、リクエストで正しいトークンとパラメータを使用していることを確認してください。それ以外の場合、ユーザー アカウントが削除または無効化されている可能性があります。
redirect_uri_mismatch
そのredirect_uri承認リクエストで渡された値が、OAuth クライアント ID の承認済みリダイレクト URI と一致しません。承認されたリダイレクト URI を確認する Google Cloud Console
Clients page。
亡くなったredirect_uriクライアントタイプに対して無効である可能性があります。
そのredirect_uriパラメータは、非推奨となりサポートされなくなった OAuth アウトオブバンド (OOB) フローを参照している可能性があります。統合を更新するには、移行ガイドを参照してください。
invalid_request
リクエストに問題がありました。これにはいくつかの理由が考えられます:
- リクエストの形式が正しくありません
- リクエストに必要なパラメータがありませんでした
- リクエストでは、Google がサポートしていない認証方法が使用されています。OAuth 統合で推奨される統合方法が使用されていることを確認します
- リダイレクト URI にサポートされていないカスタム スキームが使用されました。「 カスタム URI スキームは Android アプリまたは Chrome アプリではサポートされていません」というエラー メッセージが表示される場合は、カスタム URI スキームの代替手段について詳細をご確認ください。
ステップ 4: OAuth 2.0 サーバーの応答を処理する
アプリケーションが承認レスポンスを受信する方法は、使用するリダイレクト URI スキームによって異なります。スキームに関係なく、レスポンスには認証コード（code ) またはエラー (error ）。 例えば、error=access_deniedユーザーがリクエストを拒否したことを示します。
ユーザーがアプリケーションへのアクセスを許可する場合は、次の手順で説明するように、認証コードをアクセス トークンとリフレッシュ トークンに交換できます。
ステップ 5: 認証コードをリフレッシュトークンとアクセストークンと交換する
認可コードをアクセス トークンと交換するには、https://oauth2.googleapis.com/token エンドポイントを呼び出して次のパラメータを設定します。
| フィールド | |
|---|---|
client_id |
クライアント ID は、 Cloud Console Clients page。 |
client_secret |
オプション
クライアントシークレットは、 Cloud Console Clients page。 |
code |
最初のリクエストから返された認証コード。 |
code_verifier |
ステップ 1 で作成したコード検証ツール。 |
grant_type |
OAuth 2.0 仕様で定義されているように、このフィールドの値は次のように設定する必要がありますauthorization_code。 |
redirect_uri |
プロジェクトのリダイレクト URI の 1 つが Cloud Console
Clients page 与えられたclient_id。 |
次のスニペットはサンプルのリクエストを示しています。
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& 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 |
新しいアクセス トークンを取得するために使用できるトークン。リフレッシュ トークンは、ユーザーがアクセスを取り消すか、リフレッシュ トークンの有効期限が切れるまで有効です。 インストールされたアプリケーションの場合、リフレッシュ トークンは常に返されることに注意してください。 |
refresh_token_expires_in |
リフレッシュ トークンの残りの有効期間 (秒)。この値は、ユーザーが時間ベースのアクセスを許可した場合にのみ設定されます。 |
scope |
許可されたアクセスの範囲は、access_tokenスペースで区切られた大文字と小文字を区別する文字列のリストとして表現されます。 |
token_type |
返されるトークンのタイプ。現時点では、このフィールドの値は常にBearer。 |
次のスニペットはサンプルの応答を示しています。
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
ステップ 6: ユーザーが付与したスコープを確認する
複数の権限（スコープ）をリクエストする場合、ユーザーはアプリにそれらすべてへのアクセスを許可しない可能性があります。アプリは、実際にどのスコープが許可されたかを確認し、一部の権限が拒否された状況を適切に処理する必要があります。通常は、拒否されたスコープに依存する機能を無効にすることで対応します。
ただし、例外もあります。ドメイン全体の権限委任が適用された Google Workspace Enterprise アプリ、または 信頼済みとしてマークされたアプリは、詳細な権限の同意画面をバイパスします。これらのアプリでは、詳細な権限の同意画面はユーザーに表示されません。代わりに、アプリは要求されたすべてのスコープを受信するか、まったく受信しないかのいずれかになります。
詳細については、詳細な権限の処理方法をご覧ください。
ユーザーがアプリケーションに特定のスコープへのアクセスを許可したかどうかを確認するには、scopeアクセス トークン応答のフィールド。access_token によって許可されるアクセスの範囲。スペースで区切られ、大文字と小文字が区別される文字列のリストとして表現されます。
たとえば、次のサンプル アクセス トークン レスポンスは、ユーザーがアプリケーションに読み取り専用のドライブ アクティビティとカレンダー イベントの権限へのアクセスを許可したことを示します。
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/yt-analytics.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 への呼び出しを設定できます（たとえば、YouTube アナリティクス API を呼び出す場合など）。
YouTube アナリティクス API はサービス アカウント フローをサポートしていません。YouTube Reporting API は、レコード レーベルや映画制作会社など、複数の YouTube チャンネルを所有して管理している YouTube コンテンツ所有者のみを対象にサービス アカウントをサポートしています。
OAuth 2.0 Playground では、すべての Google API を試して、そのスコープを確認できます。
HTTP GET の例
Authorization: Bearer HTTP ヘッダーを使用した
reports.query エンドポイント（YouTube アナリティクス API）への呼び出しは、次のようになります。独自のアクセス トークンを指定する必要があります。
GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
以下は、access_token クエリ文字列パラメータを使用して認証済みユーザーに対して同じ API を呼び出す例です。
GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
curl の例
これらのコマンドは、curl コマンドライン アプリケーションでテストできます。HTTP ヘッダー オプション（推奨）を使用する例を次に示します。
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
または、クエリ文字列パラメータ オプションを使用します。
curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
アクセス トークンを更新する
アクセス トークンは定期的に期限が切れ、関連する API リクエストに対して無効な認証情報になります。トークンに関連付けられたスコープへのオフライン アクセスをリクエストした場合は、ユーザーに権限を求めることなく（ユーザーが不在の場合を含めて）アクセス トークンを更新できます。
アクセス トークンを更新するには、アプリケーションが次のパラメータを含む HTTPS POST リクエストを Google の認証サーバー（https://oauth2.googleapis.com/token）に送信します。
| フィールド | |
|---|---|
client_id |
API Consoleから取得したクライアント ID。 |
client_secret |
省略可
API Consoleから取得したクライアント シークレット。（ |
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& 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 スキーム
カスタム URI スキームは、カスタム定義のスキームを使用してアプリを開くディープリンクの一種です。
Chrome アプリでカスタム URI スキームを使用する代替手段
OAuth 2.0 レスポンスをアプリに直接配信する Chrome Identity API を使用すると、リダイレクト URI が不要になります。
ループバック IP アドレス（macOS、Linux、Windows デスクトップ）
この URL を使用して認証コードを受け取るには、アプリケーションがローカル ウェブサーバーでリッスンしている必要があります。これは多くのプラットフォームで可能ですが、すべてのプラットフォームで可能というわけではありません。ただし、プラットフォームがサポートしている場合は、これが認証コードを取得するための推奨メカニズムです。
アプリが承認応答を受信すると、最適なユーザビリティを実現するために、ブラウザを閉じてアプリに戻るようユーザーに指示する HTML ページを表示して応答する必要があります。
| 推奨される使用方法 | macOS、Linux、Windows デスクトップ（ユニバーサル Windows プラットフォームを除く）アプリ |
| フォームの値 | アプリケーション タイプを [デスクトップ アプリ] に設定します。 |
手動コピー/貼り付け（非推奨）
アプリを保護する
Chrome のアプリの所有権を確認する
アプリケーションの所有権を確認して、アプリのなりすましのリスクを軽減できます。
確認プロセスを完了するには、Chrome ウェブストア デベロッパー アカウントを使用します。 検証を成功させるには、次の要件を満たす必要があります。
- 検証を完了する Chrome 拡張機能 OAuth クライアントと同じアイテム ID を持つアイテムが、Chrome ウェブストア デベロッパー ダッシュボードに登録されている必要があります。
- Chrome ウェブストアのアイテムの公開者である必要があります。 Chrome ウェブストア デベロッパー ダッシュボードでのアクセス管理について、詳細をご確認ください。
Chrome 拡張機能クライアントの [アプリの所有権を確認] セクションで、[所有権を確認] ボタンをクリックして確認プロセスを完了します。
注: アカウントへのアクセスを許可した後、確認プロセスを完了するまで数分間お待ちください。
検証が成功した場合、検証プロセスの成功を確認する通知が表示されます。それ以外の場合は、エラー プロンプトが表示されます。
失敗した検証を修正するには、次の操作を試してください。
- 検証を完了する Chrome 拡張機能 OAuth クライアントと同じアイテム ID を持つ登録済みアイテムが Chrome ウェブストア デベロッパー ダッシュボードに存在することを確認します。
- アプリの公開者であることを確認してください。つまり、アプリの個人公開者か、アプリのグループ公開者のメンバーである必要があります。Chrome ウェブストア デベロッパー ダッシュボードでのアクセス管理の詳細については、こちらをご覧ください。
- グループ パブリッシャー リストを更新した場合は、Chrome ウェブストア デベロッパー ダッシュボードでグループ パブリッシャーのメンバーシップ リストが同期されていることを確認してください。 パブリッシャー メンバーシップ リストの同期について詳しくは、こちらをご覧ください。
アプリチェック（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 分かかることがあります。
時間に基づくアクセス
時間ベースのアクセスでは、ユーザーはアクションを完了するために、アプリが期間限定でデータにアクセスすることを許可できます。時間ベースのアクセスは、同意フロー中に一部の Google サービスで利用できます。ユーザーは、限られた期間のみアクセスを許可するオプションを選択できます。たとえば、 Data Portability API を使用すると、データを 1 回だけ転送できます。
ユーザーがアプリに時間ベースのアクセス権を付与すると、更新トークンは指定された期間の経過後に期限切れになります。特定の状況下では、更新トークンが早期に無効になることがあります。詳しくは、こちらのケースをご覧ください。このような場合、認可コード交換レスポンスで返される refresh_token_expires_in フィールドは、更新トークンの有効期限が切れるまでの残り時間を表します。
関連情報
IETF の Best Current Practice OAuth 2.0 for Native Apps では、ここに記載されているベスト プラクティスの多くが確立されています。
クロスアカウント保護機能を実装する
ユーザーのアカウントを保護するために行うべき追加の手順として、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
クロスアカウント保護の実装方法と利用可能なイベントの完全なリストについては、 クロスアカウント保護でユーザー アカウントを保護する をご覧ください。