このページは、 Using OAuth 2.0 to Access Google APIs > を翻訳したものです。原文は HTML のコメントとして残してあります。
目次
Google API は OAuth 2.0 プロトコルを使って認証と認可を行います。 Google では標準的な OAuth 2.0 のシナリオに沿った利用をサポートしています。 代表的なものとしては、Web サーバー、インストールされたアプリケーション、 クライアントサイドアプリケーション（以下、アプリと略記）といったものです。
始めるにあたっては、まず Google Developers Console からクライアント証明書を取得します。その後、 あなたのクライアントアプリは Google の認可サーバーにアクセストークンを要求し、 その応答からトークンを取り出して、アクセスしたい Google API に対してトークンを送信します。Google で OAuth 2.0 を使った会話的なデモができますので、 OAuth 2.0 Playground で実験してみてください。
当ページでは、Google がサポートする OAuth 2.0 認可機構のシナリオについてその概要を記載し、 またより詳細な情報へのリンクを掲載しています。OAuth 2.0 を使った認可についての詳細は OpenID Connect を参照してください。
注意：正しい実装を行うことでセキュリティの影響を排除するために、 Google の OAuth 2.0 エンドポイントとのやり取りを行う際は OAuth 2.0 ライブラリを使うことを強くお勧めします。他の人から提供された、 十分にデバッグが行われているコードを使うことがベストプラクティスであり、 あなたとあなたのユーザーを守ることになります。詳細は クライアントライブラリを参照してください。
どのアプリケーションも、OAuth 2.0 を使って Google API にアクセスする際には基本的なパターンがあります。高いレベルでは、 あなたは以下の４つのステップを踏みます。:
Google Developers Console に行き、Google とあなたのアプリの間で共通に利用する、クライアントID やクライアントシークレットといった OAuth 2.0 の認証情報を取得します。 これらの値の組合せは、 あなたが構築しようとしているアプリの種類によって変化します。たとえば JavaScript アプリはシークレットを要求しませんが、Web サーバーアプリはこれを要求します。
あなたのアプリが Google API
を使ってプライベートデータにアクセスできるためには、事前にその API
へのアクセスを許可するための、アクセストークンを取得しておかなければなりません。
一つのアクセストークンで、複数の API
へのアクセスへの様々な度合いに応じた許可を与えることが可能です。
scopeをコールした際の変数パラメーターにより、
アクセストークンが許可するリソースや操作の組合せをコントロールできます。
アクセストークンをリクエストする間に、
あなたのアプリはscopeのパラメーター内で１つ以上の値を送信します。
このリクエストを行うには複数のやり方がありますが、 それはあなたが構築しようとしているアプリのタイプによって変わります。 たとえば JavaScript のアプリはアクセストークンをリクエストするのに Google へのブラウザのリダイレクトを使うかもしれませんが、 ブラウザを持たないデバイスにインストールされたアプリは Web サービスリクエストを使います。
リクエストによっては、ユーザーが Google アカウントを使ってログインを するところで、認証のステップを要求します。ログイン完了後、ユーザーはあなたの アプリがリクエストしているものに対して、許可するかどうかを尋ねられます。 その処理はuser concent(ユーザーの同意)と呼ばれています。
ユーザーが認可を承諾したら、Google の認可サーバーはあなたのアプリにアクセストークン（または、 アクセストークンを取得するのに使える認可コード）を送ります。 ユーザーが認可を承諾しなかった場合、サーバーはエラーを返します。
一般的にはアクセスが要求された際、最初から一括でリクエストに入れるのではなく、 リクエストのスコープを段階的に広げていくのがベストプラクティスです。たとえば、 購入機能をサポートしたいアプリは、ユーザーが”購入”ボタンを押すまでは、 Google Wallet へのアクセスを要求するべきではありません。 Incremental authorizationを参照してください。
アプリはアクセストークンを取得すると、それを HTTP の authorization ヘッダーに入れて Google API に送ります。 URI のクエリー文字列として送ることも可能ですが、推奨しません。それは、 URL パラメーターは最終的にはログに記録されるので、全く安全ではないからです。 また、不必要な URI パラメーター名を作らないのも良い REST な習慣です。
アクセストークンは、トークンリクエストのscope
で指定された操作とリソースの組合せに対してのみ有効です。たとえば、
あるアクセストークンが Google+ API に対して発行されても、それは
Google Contacts API に対してはアクセスを許可しません。ただし、
同じような操作を複数回行うために Google+ API
に複数回トークンを送ることは可能です。
アクセストークンの生存期限には限りがあります。 あなたのアプリがひとつのアクセストークンの生存期限を越えて Google API にアクセスを要求した場合、リフレッシュトークンが得られます。 あなたのアプリはリフレッシュトークンを使って新しいアクセストークンを 取得できます。
注意：リフレッシュトークンは長期間使える安全なストレージに保存し、 それが有効な間はそれを使い続けるようにしてください。 クライアントとユーザーの組合せ毎、 および全クライアントを通じたユーザー毎に発行できるリフレッシュトークンの 数には制限がかけられており、またこれらの制限値は異なります。 あなたのアプリがそのいずれかの制限を越えてリフレッシュトークンを要求した場合、 古いリフレッシュトークンは機能しなくなります。
Google の OAuth 2.0 エンドポイントは、PHP, Java, Python, Ruby, ASP.NET といった言語やフレームワークを使用する Web サーバーアプリをサポートしています。
あなたのアプリがブラウザを Google の URL にリダイレクトした時に、 認可処理のシーケンスが始まります。その URL には、リクエスト されようとしているアクセスのタイプを表すクエリーパラメーターが含まれています。 Google はユーザー認証、セッションの選択、およびユーザーの承諾画面を処理します。 その結果が認可コードとなり、 これをアプリがアクセストークンやリフレッシュトークン取得のために交換できます。
アプリは将来の利用に備えてリフレッシュトークンを保存するべきであり、
また Google API へのアクセスのためにアクセストークンを使用します。
アクセストークンが利用期限を迎えてしまった場合、
アプリはリフレッシュトークンを使って新しいアクセストークンを取得します。
詳細は
Using OAuth 2.0 for Web Server Applications
（和訳）
を参照してください。
Google OAuth 2.0 エンドポイントは、コンピューター、モバイル機器、
タブレットといったデバイスにインストールされたアプリケーションもサポートしています。
Google Developers Console
を通してクライアントIDを作る際、インストールされたアプリとするために、
アプリの種類として Android, Chrome, iOS, PalyStation4 または「その他」
を選択してください。
この手順によりクライアントIDが作られますが、同時にいくつかのケースでは、
あなたのアプリのソースコード中に埋め込むためのクライアントシークレットも作られます。
（この場合、クライアントシークレットは明らかに「シークレット」としては扱われません。）
あなたのアプリがブラウザを Google の URL にリダイレクトした時に、
認可処理のシーケンスが始まります。その URL には、リクエスト
されようとしているアクセスのタイプを表すクエリーパラメーターが含まれています。
Google はユーザー認証、セッションの選択、およびユーザーの承諾画面を処理します。
その結果が認可コードとなり、
これをアプリがアクセストークンやリフレッシュトークン取得のために交換できます。
アプリは将来の利用に備えてリフレッシュトークンを保存するべきであり、
またアクセストークンを使って Google API にアクセスします。
アクセストークンが利用期限を迎えてしまった場合、
アプリはリフレッシュトークンを使って新しいアクセストークンを取得します。
詳細は
Using OAuth 2.0 for Installed Applicationsを参照してください。
Google OAuth 2.0 エンドポイントは、ブラウザ上で動作する JavaScript
アプリケーションもサポートしています。
あなたのアプリがブラウザを Google の URL にリダイレクトした時に、
認可処理のシーケンスが始まります。その URL には、リクエスト
されようとしているアクセスのタイプを表すクエリーパラメーターが含まれています。
Google はユーザー認証、セッションの選択、およびユーザーの承諾画面を処理します。
その結果が認可コードとなりますが、
クライアントは Google API リクエストにこれをセットする前に、
この妥当性を検査する必要があります。トークンが有効期限切れになると、
アプリは処理を繰り返します（ループします）。
詳細は
Using OAuth 2.0 for Client-side Applicationsを参照してください。
Google OAuth 2.0 エンドポイントは、ゲーム機、ビデオカメラ、プリンター等の、
入力方法に制限のあるデバイス上のアプリケーションもサポートしています。
アプリが認可コードを取得するために Google の URL に対して Web
サービスリクエストを発行した時に、認可処理のシーケンスが始まります。
そのレスポンスには、アプリがユーザーに表示するための URL やコード等、
いくつかのパラメーターが含まれています。
ユーザーはそのデバイスから URL やコードを取得した後、
より優れた入力機能を持つ別のデバイスまたはコンピューターに処理を切り替えます。
ユーザーはブラウザを起動して指定された URL を開き、ログインしてコードを入力します。
同時に、アプリは Google の URL に指定された時間間隔で何度かアクセスを試みます。
Google サーバーからのレスポンスには、アクセストークンとリフレッシュトークンが含まれています。
アプリは将来の利用に備えてリフレッシュトークンを保存するべきであり、
またアクセストークンを使って Google API にアクセスします。
アクセストークンが利用期限を迎えてしまった場合、
アプリはリフレッシュトークンを使って新しいアクセストークンを取得します。
詳細は
Using OAuth 2.0 for Devicesを参照してください。
Prediction API や Google Cloud Storage といった Google API は、
ユーザー情報にアクセスすることなく、
あなたのアプリの代わりとなって動作することができます。このようなケースでは、
あなたのアプリは API に対して自分自身の正当性を保証する必要がありますが、
その際ユーザーの承諾は不要です。同様にエンタープライズ用途では、
あなたのアプリは何らかのリソースに対して委任されたアクセスのリクエストを行うことができます。
このようにサーバー同士でやり取りを行うためには、サービスアカウントが必要になります。
これは特定の個別のユーザーに代わって、あなたのアプリに所属するアカウントです。
あなたのアプリはサービスアカウントに代わって Google API を呼び出すことができ、
その際ユーザの承諾は不要です。（サービスアカウント以外のシナリオでは、
あなたのアプリはエンドユーザーの代わりに Google API を呼び出すことができますが、
その際ユーザーの承諾が必要になる場合があります。）
Google Developers Console から取得したサービスアカウントの資格情報には、
自動生成されたユニークなメールアドレス、クライアントID、
そして少なくとも一組の公開／秘密鍵のペアが含まれています。
クライアントIDと秘密鍵のひとつを使って署名済みの JWT を作成し、
適切な書式でアクセストークンリクエストの構築を行います。その後、
あなたのアプリは Google OAuth 2.0 の認可サーバーにトークンリクエストを送信し、
その応答としてアクセストークンが返されます。アプリはそのトークンを使って
Google API にアクセスします。トークンが有効期限切れになると、
アプリは処理を繰り返します（ループします）。
詳細は
service-accountのドキュメントを参照してください。
コードを記載する際は、
許可されているトークンが使えなくなる可能性を考慮に入れておく必要があります。
トークンは以下の３つの理由のいずれかにより動作しなくなります。:
現時点では Google ユーザーアカウント毎に 25 個のトークンという制限があります。
あるユーザーが 25 個の有効なトークンを所有している場合、次の認証リクエストは成功しますが、
同時に有効なトークンのうち最も古いものが無効化されます。
その際、ユーザーが気づけるような警告は出ません。
もし複数のプログラム、マシン、デバイスなどを認可する必要がある場合は、
１ユーザーあたりの認可するクライアント数を 15 ～ 20 くらいに制限するようにしてください。
もしあなたがGoogle Apps の管理者
である場合は、追加で管理者ユーザーを作成し、
それらを使ってクライアントを認可することもできます。
以下のクライアントライブラリはポピュラーなフレームワークを統合したもので、
これらを使うと OAuth 2.0 をより簡単に実装できます。
今後もさらなる機能追加が行われていく予定です。
特に記載のない限り、このページのコンテンツは
クリエイティブ・コモンズの表示 3.0 ライセンス
により使用許諾されます。サンプル コードは
Apache 2.0 ライセンス
（リンク先は英語）により使用許諾されます。詳しくは、Google
のサイトに関するポリシーをご覧ください。
最終更新日: 8月 18, 2015
インストールされたアプリケーション
クライアントサイド (JavaScript) アプリケーション
入力方法に制限のあるデバイス上のアプリケーション
サービスアカウント
注意：これらのサービスアカウントのシナリオでは、
アプリは JSON Web Token (JWT) を生成し、さらにそれを暗号化して署名する必要があります。
これらの処理を行う場合は、ライブラリの利用を強く推奨します。もしあなたが、
トークンの生成と署名を抽象化してくれるライブラリを使わずにこのようなコードを書いた場合、
エラー発生時に深刻なセキュリティの脅威になる場合があります。
このシナリオをサポートするライブラリの一覧については、
service-accountのドキュメントを参照してください。
注意：Google Apps ドメインで動かしたアプリでもサービスアカウントを利用できますが、
サービスアカウントは Google Apps のアカウントではないため Google Apps
の管理者が策定したドメインポリシーの支配を受けません。たとえば、Google Apps
の管理者コンソールにおいて、エンドユーザーがドメイン外とドキュメントを
共有できるようなポリシー設定をしたとしても、それはサービスアカウントには適用されません。
トークンの有効期限切れ
クライアントライブラリ
