OAuth による Google アカウントのリンク（インプリシット フロー - アーカイブ済み）

サービスで OAuth 2.0 インプリシット フローをサポートするには、HTTPS 経由で認可エンドポイントにアクセスできるようにする必要があります。このエンドポイントは、ユーザーの認証を行い、ユーザーからデータアクセスへの同意を取得します。認可エンドポイントは、ログインしていないユーザーにログイン用の UI を表示し、リクエストされたアクセスへの同意を記録します。

Google アプリケーションからサービスの API を呼び出す必要がある場合、Google はこのエンドポイントを使用して、API の呼び出し許可をユーザーから取得します。

Google アカウントのリンク: OAuth 暗黙的フロー

次のシーケンス図は、ユーザー、Google、サービスの各エンドポイント間のインタラクションの詳細を示しています。

ユーザー Google アプリ / ブラウザ 認証エンドポイント 1. ユーザーがリンクを開始する 2. 認証エンドポイントにリダイレクト（GET） client_id、redirect_uri、state、scope 3. ログイン画面と同意画面を表示する 4. ユーザーが認証して同意を付与する 5. トークンを使用して Google にリダイレクト（GET） access_token、state 6. ユーザー トークンを保存する 7. ユーザー リソースにアクセスする
図 1. Google アカウントのリンク用の OAuth 2.0 暗黙的フローのイベント シーケンス。

役割と責任

次の表に、Google アカウントのリンク（GAL）OAuth 暗黙的フローにおけるアクターの役割と責任を示します。GAL では、Google は OAuth クライアントとして機能し、サービスはID/サービス プロバイダとして機能します。

アクター / コンポーネント GAL ロール 責任
Google アプリ / サーバー OAuth クライアント フローを開始し、ブラウザのリダイレクトを使用してアクセス トークンを受け取り、サービス API にアクセスするために安全に保存します。
承認エンドポイント 認可サーバー ユーザーを認証し、ユーザーの同意を取得して、有効期間の長いアクセス トークンを Google に直接発行します。
Google リダイレクト URI コールバック エンドポイント URL フラグメントに access_token 値と state 値を含む、承認サービスからのユーザー リダイレクトを受け取ります。

通常、Google が開始する OAuth 2.0 インプリシット フローのセッションは次のような流れになります。

  1. Google がユーザーのブラウザで認可エンドポイントを開きます。ユーザーがログインし（ログインしていない場合）、Google が API を使用してデータにアクセスすることを承諾します（まだ許可していない場合）。
  2. サービスがアクセス トークンを作成し、Google に返します。そのためには、アクセス トークンをリクエストに付加して、ユーザーのブラウザを Google にリダイレクトします。
  3. Google がサービスの API を呼び出し、リクエストごとにアクセス トークンを関連付けます。サービスは、アクセス トークンによって API へのアクセスが Google に許可されていることを確認し、API 呼び出しを完了します。

実装レシピ

暗黙的フローを実装する手順は次のとおりです。

ステップ 1: 認可リクエストを処理する

Google がアカウントのリンクを開始すると、ユーザーは認証エンドポイントにリダイレクトされます。プロトコル コントラクトとパラメータ要件の詳細については、認証エンドポイントをご覧ください。

リクエストを処理するには、次の操作を行います。

  1. リクエストを検証する:

    • client_id が Google に割り当てられたクライアント ID と一致することを確認します。
    • redirect_uri が想定される Google リダイレクト URL と一致することを確認します。 none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
    • response_type が token であることを確認します。

  2. ユーザーを認証する:

    • ユーザーがサービスにログインしているかどうかを確認します。
    • ユーザーがログインしていない場合は、ログインまたは登録フローを完了するよう促します。

  3. アクセス トークンを生成する:

    • ユーザーとクライアントに関連付けられた、推測不可能な一意のアクセス トークンを作成します。

  4. Google にリダイレクトする:

    • ブラウザを redirect_uri で指定された URL にリダイレクトします。
    • 次のパラメータを URL フラグメント（ハッシュ）に追加します。
      • access_token: 生成したアクセス トークン。
      • token_type: bearer でなければなりません。
      • state: Google から受信した変更されていない状態値。
userinfo リクエストを処理する

userinfo エンドポイントは、OAuth 2.0 で保護されたリソースで、リンクされたユーザーに関するクレームを返します。userinfo エンドポイントの実装とホストは任意ですが、以下のユースケースを除きます。

トークン エンドポイントからアクセス トークンが正常に取得されると、Google は、リンクされたユーザーに関する基本的なプロフィール情報を取得するためのリクエストを userinfo エンドポイントに送信します。

userinfo エンドポイント リクエスト ヘッダー
Authorization header Bearer タイプのアクセス トークン。

たとえば、userinfo エンドポイントが https://myservice.example.com/userinfo の場合、リクエストは次のようになります。

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

userinfo エンドポイントでリクエストを処理するには、次の手順を行います。

  1. Authorization ヘッダーからアクセス トークンを抽出し、そのアクセス トークンに関連付けられたユーザーの情報を返します。
  2. アクセス トークンが無効な場合は、WWW-Authenticate レスポンス ヘッダーを使用して HTTP 401 Unauthorized エラーを返します。userinfo エラー レスポンスの例を次に示します。 
    HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
    リンク処理中に 401 Unauthorized またはその他の失敗したエラー レスポンスが返された場合、そのエラーは修復不能となり、取得したトークンは破棄されるため、ユーザーはリンク処理をやり直す必要があります。

  3. アクセス トークンが有効な場合は、HTTPS の本文に次の JSON オブジェクトを含む HTTP 200 レスポンスを返します。 レスポンス:

    {
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}
     userinfo エンドポイントが HTTP 200 成功レスポンスを返すと、取得したトークンとクレームがユーザーの Google アカウントに登録されます。

    userinfo エンドポイント レスポンス
    sub システム内でユーザーを識別する一意の ID。
    email ユーザーのメールアドレス。
    given_name 省略可: ユーザーの名。
    family_name 省略可: ユーザーの姓。
    name 省略可: ユーザーの氏名。
    picture 省略可: ユーザーのプロフィール写真。