ユーザー認証の仕組み

Google Identity Services または認可を初めて使用する場合や、よく知らない場合は、 まず概要をお読みください。

Google は、スコープの管理、ユーザーの同意の取得、標準の OAuth 2.0 フローの操作の簡素化に役立つ認可機能を備えた JavaScript ライブラリを提供しています。ユーザーのブラウザで実行されるウェブ アプリケーションは、このライブラリを使用して OAuth 2.0 暗黙的フローを管理するか、バックエンド プラットフォームで完了する認可コードフローを開始します。

認証専用スコープ

いくつかのスコープは、ユーザー認証にのみ使用されます（email、profile、openid）。アプリでこれらのスコープのみを使用する場合は、ユーザー登録とログインに JWT ID トークンと [Google でログイン] が適しているかどうかを検討してください。ほとんどの場合、これがユーザー認証に利用できる最も簡単な方法です。

主な用語と概念

このガイドでは、OAuth 2.0 の概念 と、RFC6749などの IETF 標準について基本的な知識があることを前提としています。認可ガイド全体で使用される用語は次のとおりです。

• アクセス トークン は、Google が発行するユーザーごとの有効期間の短い認証情報で、Google API の安全な呼び出しとユーザーデータへのアクセスに使用されます。
• 認証コード は、ブラウザから Google アカウントにログインする個々のユーザーを安全に識別するために Google が発行する一時的なコードです。バックエンド プラットフォームは、このコードをアクセス トークンと更新トークンに交換します。
• 更新トークン は、Google が発行するユーザーごとの有効期間の長い認証情報で、プラットフォームに安全に保存され、ユーザーがいない場合でも新しい有効なアクセス トークンを取得するために使用できます。
• スコープ は、トークンを定義された限られた量のユーザーデータに制限します。詳しくは、 Google API の OAuth 2.0 スコープをご覧ください。
• ポップアップ モード は、ユーザーのブラウザで実行される JavaScript コールバックに基づく認可コードフローです。Google はコールバック ハンドラを呼び出します。このハンドラは、認証コードをプラットフォームに送信します。その方法はユーザーが決定します。
• リダイレクト モード は、HTTP リダイレクトに基づく認可コードフローです。 ユーザー エージェントは最初に Google にリダイレクトされ、Google からプラットフォームの認証コード エンドポイントへの 2 回目のリダイレクトにコードが含まれます。

トークンの有効期間は、発行者である Google によって設定されます。正確な期間は、さまざまな要因によって異なる場合があります。

OAuth 2.0 フロー

インプリシット フローと認証コードフローの 2 つのフローについて説明します。どちらも、Google API での使用に適したアクセス トークンを返します。

認可コードフローは、ユーザーのセキュリティが強化されるため、推奨されます。 このフローは、ユーザーがいなくてもアクセス トークンを取得するために使用できる更新トークンも返します。これにより、プラットフォームは、直前にスケジュールされた会議のリマインダー SMS の送信などの非同期アクションを実行できます。2 つのフローの違いについて詳しくは、 認可モデルを選択するをご覧ください。

Google Identity Services JavaScript ライブラリは、OAuth 2.0 標準に準拠して次のことを行います。

• インプリシット フローを管理して、ブラウザ内の ウェブアプリが Google API の呼び出しに 必要なアクセス トークンを Google からすばやく取得できるようにします。
• ユーザーの ブラウザから認可コードフローを開始します。

一般的な手順

インプリシット フローと認可コードフローはどちらも同じように開始されます。

1. アプリが 1 つ以上のスコープへのアクセスをリクエストします。
2. Google はユーザーに同意ダイアログを表示し、必要に応じてユーザーを Google アカウントにログインさせます。
3. ユーザーは、リクエストされたスコープごとに個別に承認します。

各フローは、異なる手順で終了します。

暗黙的フローを使用する場合

• Google はコールバック ハンドラを使用して、同意の結果をアプリに通知し、承認されたスコープのアクセス トークンを返します。

認可コードフローを使用する場合

• Google は、ユーザーごとの認証コードで応答します。
  • リダイレクト モードでは、コードはプラットフォームの認可コード エンドポイントに返されます。
  • ダイアログ モードでは、ユーザーがウェブサイトを離れる必要なく、コードがブラウザ内アプリのコールバック ハンドラに返されます。
• ステップ 4: OAuth 2.0 サーバー レスポンスを処理するから始まるバックエンド プラットフォームは、Google とのサーバー間交換を完了し、最終的にユーザーごとの更新トークンとアクセス トークンがプラットフォームに返されます。

ユーザーの同意

アクセス トークンを取得する前に、個々のユーザーは、リクエストされたスコープにアクセスするための同意をアプリに付与する必要があります。これを行うために、Google はステップ 2 で同意ダイアログを表示し、その結果を myaccount.google.com/permissionsに記録します。

アプリ名、ロゴ、プライバシー ポリシー、利用規約、リクエストされたスコープが、リクエストを承認またはキャンセルするオプションとともにユーザーに表示されます。

図 1 に、単一スコープの同意ダイアログを示します。単一のスコープがリクエストされた場合、スコープを承認または拒否するためにチェックボックスは必要ありません。

図 1: 単一スコープのユーザー同意ダイアログ。

図 2 に、複数のスコープの同意ダイアログを示します。複数のスコープがリクエストされた場合は、ユーザーが各スコープを承認または拒否できるように、個別のチェックボックスが必要です。

図 2: 複数のスコープのユーザー同意ダイアログ。

ユーザー アカウント

同意を記録してアクセス トークンを発行するには、Google アカウントが必要です。 これを行う前に、個々のユーザーは Google アカウントにログインして Google に対する認証を行う必要があります。

必須ではありませんが、ウェブアプリまたはバックエンド プラットフォームへの登録とログインには [Google でログイン]を使用することをおすすめします。これにより、必要な手順の数を最小限に抑えてユーザーの負担を軽減し、必要に応じてアクセス トークンをプラットフォーム上の個々のアカウントに関連付けることができます。

たとえば、[Google でログイン] を使用すると、アクティブな Google アカウント セッションが確立されるため、認可リクエストを行うときにユーザーに Google アカウントへのログインを求める必要がなくなります。ユーザー名とパスワードなどの他の方法や、他の ID プロバイダを使用してアプリに対するユーザーの認証を行う場合でも、同意を得るために最初に Google アカウントにログインする必要があります。

認可の初期化時にログイン ヒント（通常はユーザーの Google アカウントのメールアドレス）を追加すると、Google はアカウント選択ツールの表示 をスキップできるため、ユーザーの手間が省けます。[Google でログイン] から返される ID トークン クレデンシャルには、ユーザーのメールアドレスが含まれています。

ブラウザでのみ実行されるウェブアプリは、ユーザー アカウント管理システムを実装しないことを選択し、ユーザー認証を Google のみに依存する場合があります。 このシナリオ（暗黙的フロー）では、更新トークンをユーザー アカウントと管理セキュアストレージに関連付ける必要はありません。

一方、認可コードフローではユーザー アカウント システムが必要です。 ユーザーごとの更新トークンは、バックエンド プラットフォーム上の個々のアカウントに関連付け、後で使用できるように保存する必要があります。ユーザー アカウント システムの実装、操作、管理の方法はプラットフォームによって異なり、詳細については説明しません。

同意の表示と取り消し

ユーザーは、Google アカウントの設定からいつでも同意を表示または取り消すことができます。

必要に応じて、ウェブアプリまたはプラットフォームは google.accounts.oauth2.revokeを呼び出してトークンを取り消し、ユーザーの同意を削除できます。 これは、ユーザーがプラットフォームからアカウントを削除する場合に便利です。

その他の認可オプション

または、ブラウザは Google の OAuth 2.0 エンドポイントを直接呼び出すことで、暗黙的フローを使用してアクセス トークンを取得できます。これは、クライアントサイド ウェブ アプリケーション用の OAuth 2.0で説明されています。

同様に、認可コードフローでは、独自の方法を実装し、ウェブサーバー アプリケーション用の OAuth 2.0 の使用で説明されている手順に沿って操作することもできます。

どちらの場合も、Google Identity Services ライブラリ を使用して、開発時間と労力を削減し、 OAuth 2.0 Security Best Current Practiceで説明されているようなセキュリティ リスクを最小限に抑えることを強くおすすめします。