このページは Cloud Translation API によって翻訳されました。

コードモデルの使用

Google Identity Services ライブラリを使用すると、ユーザーはブラウザベースのポップアップまたはリダイレクト UX フローを使用して、Google から認可コードをリクエストできます。これにより、安全な OAuth 2.0 フローが開始され、ユーザーに代わって Google API を呼び出すために使用されるアクセストークンが生成されます。

OAuth 2.0 認可コードフローの概要:

Google アカウントのオーナーは、ブラウザでボタンのクリックなどの操作で、Google に認可コードをリクエストします。
Google は、ユーザーのブラウザで実行されている JavaScript ウェブアプリのコールバックに一意の認可コードを送信するか、ブラウザのリダイレクトを使用して認可コードエンドポイントを直接呼び出します。
バックエンドプラットフォームが認可コードエンドポイントをホストし、コードを受信します。検証後、このコードは Google のトークンエンドポイントへのリクエストを使用して、ユーザーごとのアクセストークンと更新トークンと交換されます。
Google は認可コードを検証し、リクエストが安全なプラットフォームから発信されたことを確認して、アクセストークンと更新トークンを発行します。また、プラットフォームでホストされているログインエンドポイントを呼び出して、トークンを返します。
ログインエンドポイントはアクセストークンと更新トークンを受け取り、後で使用できるように更新トークンを安全に保存します。

前提条件

設定の手順に沿って、OAuth 同意画面を構成し、クライアント ID を取得して、クライアントライブラリを読み込みます。

Code クライアントを初期化する

google.accounts.oauth2.initCodeClient() メソッドはコードクライアントを初期化します。

ポップアップモードまたはリダイレクトモード

認証コードを共有するには、リダイレクト モードまたはポップアップ モードのユーザーフローのいずれかを使用します。リダイレクトモードでは、サーバー上で OAuth2 認可エンドポイントをホストします。Google はユーザーエージェントをこのエンドポイントにリダイレクトし、認証コードを URL パラメータとして共有します。ポップアップモードの場合は、認可コードをサーバーに送信する JavaScript コールバックハンドラを定義します。ポップアップモードを使用すると、ユーザーがサイトを離れることなくシームレスなユーザーエクスペリエンスを提供できます。

次のクライアントを初期化するには:

UX フローをリダイレクトし、ux_mode を redirect に設定し、redirect_uri の値をプラットフォームの認可コードエンドポイントに設定します。この値は、API Console で構成した OAuth 2.0 クライアントの承認済みリダイレクト URI のいずれかと完全に一致する必要があります。また、リダイレクト URI の検証ルールにも準拠している必要があります。
ポップアップ UX フローの場合、ux_mode を popup に設定し、callback の値を、プラットフォームに認証コードを送信するために使用する関数の名前に設定します。

CSRF 攻撃を防ぐ

クロスサイトリクエストフォージェリ（CSRF）攻撃を防ぐため、リダイレクトモードとポップアップモードの UX フローでは、若干異なる手法が採用されています。リダイレクトモードでは、OAuth 2.0 の state パラメータが使用されます。state パラメータの生成と検証について詳しくは、RFC6749 の 10.12 クロスサイトリクエストフォージェリをご覧ください。ポップアップモードでは、リクエストにカスタム HTTP ヘッダーを追加し、サーバーで想定される値と送信元と一致することを確認します。

UX モードを選択して、認証コードと CSRF 処理を示すコードスニペットを表示します。

リダイレクトモード

クライアントを初期化して、Google がユーザーのブラウザを認証エンドポイントにリダイレクトし、認証コードを URL パラメータとして共有します。

const client = google.accounts.oauth2.initCodeClient({
  client_id: 'YOUR_GOOGLE_CLIENT_ID',
  scope: 'https://www.googleapis.com/auth/calendar.readonly',
  ux_mode: 'redirect',
  redirect_uri: "https://your.domain/code_callback_endpoint",
  state: "YOUR_BINDING_VALUE"
});

ユーザーのブラウザが Google から認証コードを受信し、サーバーに送信するクライアントを初期化します。

const client = google.accounts.oauth2.initCodeClient({
  client_id: 'YOUR_GOOGLE_CLIENT_ID',
  scope: 'https://www.googleapis.com/auth/calendar.readonly',
  ux_mode: 'popup',
  callback: (response) => {
    const xhr = new XMLHttpRequest();
    xhr.open('POST', code_receiver_uri, true);
    xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    // Set custom header for CRSF
    xhr.setRequestHeader('X-Requested-With', 'XmlHttpRequest');
    xhr.onload = function() {
      console.log('Auth code response: ' + xhr.responseText);
    };
    xhr.send('code=' + response.code);
  },
});

OAuth 2.0 コードフローをトリガーする

コードクライアントの requestCode() メソッドを呼び出して、ユーザーフローをトリガーします。

<button onclick="client.requestCode();">Authorize with Google</button>

この場合、ユーザーは Google アカウントにログインし、リダイレクトエンドポイントまたはコールバックハンドラのいずれかに認可コードを返す前に、個々のスコープの共有に同意する必要があります。

認証コードの処理

Google はユーザーごとに一意の認可コードを生成し、バックエンドサーバーで受け取って検証します。

ポップアップモードでは、callback で指定されたハンドラがユーザーのブラウザで実行され、認可コードをプラットフォームでホストされているエンドポイントにリレーします。

リダイレクトモードの場合、redirect_url で指定されたエンドポイントに GET リクエストが送信され、URL の code パラメータで認可コードが共有されます。認証コードを受け取るには:

既存の実装がない場合は、新しい認可エンドポイントを作成します。
GET リクエストと URL パラメータを受け入れるように既存のエンドポイントを更新します。以前は、ペイロードに認証コード値を含む PUT リクエストが使用されていました。

承認エンドポイント

認証コードエンドポイントは、次の URL クエリ文字列パラメータを使用して GET リクエストを処理する必要があります。

名前	値
authuser	ユーザーのログイン認証をリクエストする
コード	Google によって生成された OAuth2 認証コード
HD	ユーザーアカウントのホストされているドメイン
プロンプト	ユーザーの同意ダイアログ
スコープ	承認される 1 つ以上の OAuth2 スコープのスペース区切りリスト
state	CRSF 状態変数

example.com でホストされている auth-code という名前のエンドポイントへの URL パラメータを含む GET リクエストの例:

Request URL: https://www.example.com/auth-code?state=42a7bd822fe32cc56&code=4/0AX4XfWiAvnXLqxlckFUVao8j0zvZUJ06AMgr-n0vSPotHWcn9p-zHCjqwr47KHS_vDvu8w&scope=email%20profile%20https://www.googleapis.com/auth/calendar.readonly%20https://www.googleapis.com/auth/photoslibrary.readonly%20https://www.googleapis.com/auth/contacts.readonly%20openid%20https://www.googleapis.com/auth/userinfo.email%20https://www.googleapis.com/auth/userinfo.profile&authuser=0&hd=example.com&prompt=consent

認可コードフローが以前の JavaScript ライブラリによって開始された場合、または Google OAuth 2.0 エンドポイントへの直接呼び出しによって開始された場合、POST リクエストが使用されます。

HTTP リクエスト本文に認証コードをペイロードとして含む POST リクエストの例:

Request URL: https://www.example.com/auth-code
Request Payload: 4/0AX4XfWhll-BMV82wi4YwbrSaTPaRpUGpKqJ4zBxQldU\_70cnIdh-GJOBZlyHU3MNcz4qaw

リクエストを検証します

サーバーで次の操作を行い、CSRF 攻撃を回避します。

リダイレクトモードの場合は、state パラメータの値を確認します。

X-Requested-With: XmlHttpRequest ヘッダーがポップアップモードに設定されていることを確認します。

認証コードリクエストを正常に検証した場合にのみ、Google から更新トークンとアクセストークンを取得する必要があります。

アクセストークンと更新トークンを取得する

バックエンドプラットフォームが Google から認可コードを受信してリクエストを検証したら、認可コードを使用して Google からアクセストークンと更新トークンを取得し、API 呼び出しを行います。

ウェブサーバーアプリケーションに OAuth 2.0 を使用するガイドのステップ 5: 認証コードを更新トークンとアクセストークンと交換するから手順に沿って対応します。

トークンを管理する

プラットフォームが更新トークンを安全に保存している。ユーザーアカウントが削除されたとき、またはユーザーの同意が google.accounts.oauth2.revoke によって取り消されたとき、または https://myaccount.google.com/permissions から直接取り消されたときに、保存されている更新トークンを削除します。

必要に応じて、RISC を使用してクロスアカウント保護でユーザーアカウントを保護することもできます。

通常、バックエンドプラットフォームはアクセストークンを使用して Google API を呼び出します。ウェブアプリがユーザーのブラウザから Google API を直接呼び出す場合も、アクセストークンをウェブアプリケーションと共有する方法を実装する必要があります。この方法については、このガイドの範囲外です。この方法で JavaScript 用 Google API クライアントライブラリを使用する場合は、gapi.client.SetToken() を使用してアクセストークンをブラウザのメモリに一時的に保存し、ライブラリが Google API を呼び出すようにします。