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