Google APIは、認証と承認にOAuth2.0プロトコルを使用します。 Googleは、ウェブサーバー、クライアント側、インストール済み、入力制限のあるデバイスアプリケーションなどの一般的なOAuth2.0シナリオをサポートしています。
まず、 Google API ConsoleからOAuth2.0クライアントの資格情報を取得します。次に、クライアントアプリケーションはGoogle認証サーバーにアクセストークンを要求し、応答からトークンを抽出して、アクセスするGoogleAPIにトークンを送信します。 GoogleでOAuth2.0を使用するインタラクティブなデモンストレーション（独自のクライアントクレデンシャルを使用するオプションを含む）については、 OAuth 2.0Playgroundを試してみてください。
このページでは、GoogleがサポートするOAuth 2.0認証シナリオの概要を示し、より詳細なコンテンツへのリンクを提供します。認証のためのOAuth 2.0を使用しての詳細については、参照OpenIDの接続を。
基本的な手順
OAuth2.0を使用してGoogleAPIにアクセスする場合、すべてのアプリケーションは基本的なパターンに従います。大まかに言うと、次の5つのステップに従います。
1.Google API ConsoleからOAuth2.0クレデンシャルを取得します。
Google API Consoleにアクセスして、Googleとアプリケーションの両方に認識されているクライアントIDやクライアントシークレットなどのOAuth2.0クレデンシャルを取得します。値のセットは、構築しているアプリケーションのタイプによって異なります。たとえば、JavaScriptアプリケーションはシークレットを必要としませんが、Webサーバーアプリケーションはシークレットを必要とします。
2.Google認証サーバーからアクセストークンを取得します。
アプリケーションがGoogleAPIを使用してプライベートデータにアクセスする前に、そのAPIへのアクセスを許可するアクセストークンを取得する必要があります。単一のアクセストークンで、複数のAPIにさまざまな程度のアクセスを許可できます。 scopeと呼ばれる可変パラメーターは、アクセストークンが許可するリソースと操作のセットを制御します。アクセストークン要求中に、アプリケーションはscopeパラメーターで1つ以上の値を送信します。
このリクエストを行うにはいくつかの方法があり、それらは構築しているアプリケーションのタイプによって異なります。たとえば、JavaScriptアプリケーションがGoogleへのブラウザリダイレクトを使用してアクセストークンを要求し、ブラウザがないデバイスにインストールされたアプリケーションがWebサービス要求を使用する場合があります。
一部のリクエストでは、ユーザーがGoogleアカウントでログインする認証手順が必要です。ログイン後、ユーザーは、アプリケーションが要求している1つ以上のアクセス許可を付与するかどうかを尋ねられます。このプロセスはユーザー同意と呼ばれます。
ユーザーが少なくとも1つの権限を付与すると、Google認証サーバーはアプリケーションにアクセストークン（またはアプリケーションがアクセストークンを取得するために使用できる認証コード）と、そのトークンによって付与されたアクセス範囲のリストを送信します。ユーザーが権限を付与しない場合、サーバーはエラーを返します。
一般に、事前にではなく、アクセスが必要なときにスコープを段階的に要求することがベストプラクティスです。たとえば、予定をカレンダーに保存することをサポートしたいアプリは、ユーザーが[カレンダーに追加]ボタンを押すまで、Googleカレンダーへのアクセスをリクエストしないでください。増分認証を参照してください。
3.ユーザーによって付与されたアクセスの範囲を調べます。
アクセストークンの応答に含まれるスコープを、関連するGoogleAPIへのアクセスに応じてアプリケーションの機能にアクセスするために必要なスコープと比較します。関連するAPIにアクセスしないと機能できないアプリの機能を無効にします。
ユーザーが要求されたすべてのスコープを許可した場合でも、要求に含まれるスコープが応答に含まれるスコープと一致しない場合があります。アクセスに必要なスコープについては、各GoogleAPIのドキュメントを参照してください。 APIは、複数のスコープ文字列値を単一のアクセススコープにマップし、リクエストで許可されているすべての値に対して同じスコープ文字列を返す場合があります。例：アプリがユーザーにhttps://www.google.com/m8/feeds/スコープの承認をリクエストした場合、Google PeopleAPIはhttps://www.googleapis.com/auth/contactsスコープを返す場合がありhttps://www.google.com/m8/feeds/ 。 Google People APIメソッドpeople.updateContactは、 https://www.googleapis.com/auth/contacts付与されたスコープが必要です。
4.アクセストークンをAPIに送信します。
アプリケーションはアクセストークンを取得した後、 HTTP認証リクエストヘッダーでトークンをGoogleAPIに送信します。トークンをURIクエリ文字列パラメーターとして送信することは可能ですが、URIパラメーターが完全に安全ではないログファイルになってしまう可能性があるため、お勧めしません。また、不要なURIパラメーター名を作成しないようにすることをお勧めします。クエリ文字列のサポートは、2021年6月1日に非推奨になることに注意してください。
アクセストークンは、トークンリクエストのscopeで説明されている一連の操作とリソースに対してのみ有効です。たとえば、Google Calendar APIに対してアクセストークンが発行された場合、GoogleコンタクトAPIへのアクセスは許可されません。ただし、同様の操作のために、そのアクセストークンをGoogle CalendarAPIに複数回送信することができます。
5.必要に応じて、アクセストークンを更新します。
アクセストークンの有効期間は限られています。アプリケーションが単一のアクセストークンの有効期間を超えてGoogleAPIにアクセスする必要がある場合、アプリケーションは更新トークンを取得できます。更新トークンを使用すると、アプリケーションは新しいアクセストークンを取得できます。
シナリオ
Webサーバーアプリケーション
Google OAuth 2.0エンドポイントは、PHP、Java、Python、Ruby、ASP.NETなどの言語とフレームワークを使用するウェブサーバーアプリケーションをサポートしています。
承認シーケンスは、アプリケーションがブラウザをGoogleURLにリダイレクトしたときに始まります。 URLには、要求されているアクセスのタイプを示すクエリパラメータが含まれています。 Googleは、ユーザー認証、セッション選択、およびユーザー同意を処理します。結果は認証コードであり、アプリケーションはこれをアクセストークンと更新トークンと交換できます。
アプリケーションは、将来使用するために更新トークンを保存し、アクセストークンを使用してGoogleAPIにアクセスする必要があります。アクセストークンの有効期限が切れると、アプリケーションは更新トークンを使用して新しいトークンを取得します。
詳細については、「 WebサーバーアプリケーションでのOAuth2.0の使用」を参照してください。
インストールされているアプリケーション
Google OAuth 2.0エンドポイントは、コンピューター、モバイルデバイス、タブレットなどのデバイスにインストールされるアプリケーションをサポートします。 Google API ConsoleでクライアントIDを作成する場合は、これがインストール済みアプリケーションであることを指定し、アプリケーションの種類としてAndroid、Chromeアプリ、iOS、ユニバーサルWindowsプラットフォーム（UWP）、またはデスクトップアプリを選択します。
このプロセスにより、クライアントIDが生成され、場合によっては、アプリケーションのソースコードに埋め込まれたクライアントシークレットが生成されます。 （このコンテキストでは、クライアントシークレットは明らかにシークレットとして扱われません。）
承認シーケンスは、アプリケーションがブラウザをGoogleURLにリダイレクトしたときに始まります。 URLには、要求されているアクセスのタイプを示すクエリパラメータが含まれています。 Googleは、ユーザー認証、セッション選択、およびユーザー同意を処理します。結果は認証コードであり、アプリケーションはこれをアクセストークンと更新トークンと交換できます。
アプリケーションは、将来使用するために更新トークンを保存し、アクセストークンを使用してGoogleAPIにアクセスする必要があります。アクセストークンの有効期限が切れると、アプリケーションは更新トークンを使用して新しいトークンを取得します。
詳細については、「インストールされているアプリケーションでのOAuth2.0の使用」を参照してください。
クライアントサイド（JavaScript）アプリケーション
Google OAuth 2.0エンドポイントは、ブラウザで実行されるJavaScriptアプリケーションをサポートします。
承認シーケンスは、アプリケーションがブラウザをGoogleURLにリダイレクトしたときに始まります。 URLには、要求されているアクセスのタイプを示すクエリパラメータが含まれています。 Googleは、ユーザー認証、セッション選択、およびユーザー同意を処理します。
結果はアクセストークンであり、クライアントはそれをGoogleAPIリクエストに含める前に検証する必要があります。トークンの有効期限が切れると、アプリケーションはプロセスを繰り返します。
詳細については、「クライアント側アプリケーションでのOAuth2.0の使用」を参照してください。
限られた入力デバイスでのアプリケーション
Google OAuth 2.0エンドポイントは、ゲーム機、ビデオカメラ、プリンターなどの入力が制限されたデバイスで実行されるアプリケーションをサポートします。
認証シーケンスは、アプリケーションが認証コードのGoogleURLに対してWebサービスリクエストを行うことから始まります。応答には、アプリケーションがユーザーに表示するURLやコードなど、いくつかのパラメーターが含まれています。
ユーザーはデバイスからURLとコードを取得してから、より豊富な入力機能を備えた別のデバイスまたはコンピューターに切り替えます。ユーザーはブラウザを起動し、指定されたURLに移動してログインし、コードを入力します。
その間、アプリケーションは指定された間隔でGoogleURLをポーリングします。ユーザーがアクセスを承認すると、Googleサーバーからの応答にアクセストークンと更新トークンが含まれます。アプリケーションは、将来使用するために更新トークンを保存し、アクセストークンを使用してGoogleAPIにアクセスする必要があります。アクセストークンの有効期限が切れると、アプリケーションは更新トークンを使用して新しいトークンを取得します。
詳細については、「デバイスでのOAuth2.0の使用」を参照してください。
サービスアカウント
PredictionAPIやGoogleCloudStorageなどのGoogleAPIは、ユーザー情報にアクセスすることなく、アプリケーションに代わって動作できます。このような状況では、アプリケーションはAPIに対して独自のIDを証明する必要がありますが、ユーザーの同意は必要ありません。同様に、エンタープライズシナリオでは、アプリケーションは一部のリソースへの委任されたアクセスを要求できます。
これらのタイプのサーバー間相互作用には、サービスアカウントが必要です。これは、個々のエンドユーザーではなくアプリケーションに属するアカウントです。アプリケーションはサービスアカウントに代わってGoogleAPIを呼び出し、ユーザーの同意は必要ありません。 （サービスアカウント以外のシナリオでは、アプリケーションがエンドユーザーに代わってGoogle APIを呼び出し、ユーザーの同意が必要になる場合があります。）
Google API Consoleから取得するサービスアカウントの資格情報には、一意の生成された電子メールアドレス、クライアントID、および少なくとも1つの公開鍵と秘密鍵のペアが含まれます。クライアントIDと1つの秘密鍵を使用して、署名されたJWTを作成し、適切な形式でアクセストークンリクエストを作成します。次に、アプリケーションはトークンリクエストをGoogle OAuth 2.0認証サーバーに送信します。GoogleOAuth2.0認証サーバーは、アクセストークンを返します。アプリケーションはトークンを使用してGoogleAPIにアクセスします。トークンの有効期限が切れると、アプリケーションはプロセスを繰り返します。
詳細については、サービスアカウントのドキュメントを参照してください。
トークンサイズ
トークンのサイズは、次の制限までさまざまです。
- 認証コード：256バイト
- アクセストークン：2048バイト
- 更新トークン：512バイト
GoogleCloudのSecurityToken Service APIによって返されるアクセストークンは、Google API OAuth 2.0アクセストークンと同様に構造化されていますが、トークンサイズの制限が異なります。詳細については、 APIドキュメントを参照してください。
Googleは、これらの制限内でトークンサイズを変更する権利を留保し、アプリケーションはそれに応じて可変トークンサイズをサポートする必要があります。
トークンの有効期限を更新
付与された更新トークンが機能しなくなる可能性を予測するには、コードを作成する必要があります。更新トークンは、次のいずれかの理由で機能しなくなる可能性があります。
- ユーザーがアプリのアクセスを取り消しました。
- 更新トークンは6か月間使用されていません。
- ユーザーがパスワードを変更し、更新トークンにGmailスコープが含まれています。
- ユーザーアカウントが、付与された（ライブ）更新トークンの最大数を超えました。
- ユーザーは、セッション制御ポリシーが有効になっているGoogle CloudPlatform組織に属しています。
OAuth同意画面が外部ユーザータイプ用に構成され、公開ステータスが「テスト中」のGoogle Cloud Platformプロジェクトには、7日で有効期限が切れる更新トークンが発行されます。
現在、OAuth2.0クライアントIDごとにGoogleアカウントごとに50の更新トークンの制限があります。制限に達した場合、新しい更新トークンを作成すると、警告なしに最も古い更新トークンが自動的に無効になります。この制限は、サービスアカウントには適用されません。
また、ユーザーアカウントまたはサービスアカウントがすべてのクライアントで持つことができる更新トークンの総数には、より大きな制限があります。ほとんどの通常のユーザーはこの制限を超えることはありませんが、実装のテストに使用される開発者のアカウントは超える可能性があります。
複数のプログラム、マシン、またはデバイスを認証する必要がある場合、1つの回避策は、Googleアカウントごとに認証するクライアントの数を15または20に制限することです。GoogleWorkspace管理者の場合は、管理者権限を持つ追加のユーザーを作成できます。それらを使用して、一部のクライアントを承認します。
Google Cloud Platform（GCP）組織のセッション制御ポリシーの処理
GCP組織の管理者は、 Google Cloudセッションコントロール機能を使用して、ユーザーがGCPリソースにアクセスするときに頻繁に再認証を行う必要がある場合があります。このポリシーは、Google Cloud Console、Google Cloud SDK（gcloud CLIとも呼ばれます）、およびCloudPlatformスコープを必要とするサードパーティのOAuthアプリケーションへのアクセスに影響を与えます。ユーザーがセッション制御ポリシーを設定している場合、セッション期間が終了すると、更新トークンが取り消された場合と同様にAPI呼び出しがエラーになります。セッション期間は非常に制限される可能性があるため（1時間から24時間の間）、このシナリオは、認証セッションを再開することによって適切に処理する必要があります。
同様に、サーバー間展開でユーザー資格情報を使用したり、使用を推奨したりしてはなりません。長時間実行されるジョブまたは操作のためにユーザー資格情報がサーバーにデプロイされ、顧客がそのようなユーザーにセッション制御ポリシーを適用すると、セッション期間が終了したときにユーザーを再認証する方法がないため、サーバーアプリケーションは失敗します。
顧客がこの機能を展開できるようにする方法の詳細については、この管理者向けのヘルプ記事を参照してください。
クライアントライブラリ
次のクライアントライブラリは、一般的なフレームワークと統合されているため、OAuth2.0の実装が簡単になります。今後、ライブラリにさらに多くの機能が追加される予定です。