ユーザー認証の仕組み

Google Identity Services や認証を初めて使用する場合、またはまだ知らない場合は、まず概要をご覧ください。

Google は、スコープを管理し、ユーザーの同意を得て、標準の OAuth 2.0 フローを簡単に使用するための認可機能を含む JavaScript ライブラリを提供しています。ユーザーのブラウザで実行されるウェブ アプリケーションは、このライブラリを使用して OAuth 2.0 暗黙的フローを管理するか、バックエンド コードで完了する認証コードフローを開始します。

認証のみのスコープ

ユーザー認証にのみ使用されるスコープには、email、profile、openid があります。アプリでこれらのスコープのみを使用する場合は、JWT ID トークンと、Google でログインのユーザー ログインとログインがニーズに合っているかどうかをご確認ください。ほとんどの場合、これはユーザー認証に使用できる最もシンプルでシンプルな方法です。

主な用語と概念

このガイドは、RFC6749 などの OAuth 2.0 のコンセプトと IETF 標準について基本的な知識があることを前提としています。以下のガイドは、認可ガイド全体で使用されます。

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

トークンの有効期間は 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 つのスコープの同意ダイアログを示します。単一のスコープがリクエストされている場合、スコープを承認または拒否するためのチェックボックスは必要ありません。

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

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

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

ユーザー アカウント

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

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

たとえば、「Google でログイン」を使用すると、有効な Google アカウント セッションが確立されるため、後で承認リクエスト時にユーザーに Google アカウントにログインするよう促す必要はありません。アプリのユーザー認証にユーザー名とパスワードや、その他の ID プロバイダなどの他の方法を選択した場合でも、同意を求める場合は Google アカウントにログインする必要があります。

承認の初期化中にログインヒント（通常はユーザーの Google アカウントのメールアドレス）を追加すると、Google はアカウント選択ツールの表示をスキップして、ユーザーの手順を省略できます。「Google でログイン」によって返される ID トークンの認証情報には、ユーザーのメールアドレスが含まれています。

ブラウザ内でのみ動作するウェブアプリは、ユーザー認証に Google のみを使用して、ユーザー アカウント管理システムを実装しないことを選択できます。このシナリオは「暗黙的フロー」と呼ばれ、更新トークンをユーザー アカウントや管理セキュア ストレージに関連付ける必要はありません。

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

同意の表示と取り消し

同意の確認と取り消しは、Google アカウントの設定でいつでも行えます。

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

その他の承認オプション

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

同様に、認証コードフローについても、独自のメソッドを実装し、ウェブサーバー アプリケーションに OAuth 2.0 を使用するで概説されている手順を使用できます。

どちらの場合も、Google Identity Services ライブラリを使用して開発時間と労力を軽減し、OAuth 2.0 セキュリティに関する現在のベスト プラクティスのようなセキュリティ リスクを最小限に抑えることを強くおすすめします。