ユーザー認証の仕組み

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

Google が提供する JavaScript ライブラリには、スコープの管理やユーザーの同意の取得など、標準の OAuth 2.0 フローでの作業を容易にする承認機能が含まれています。ユーザーのブラウザで実行されているウェブ アプリケーションは、このライブラリを使用して、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 つのスコープの同意ダイアログを示しています。単一のスコープがリクエストされた場合、スコープの承認または拒否にチェックボックスは必要ありません。

図 1: スコープが 1 つのユーザーの同意ダイアログ

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

図 2: 複数のスコープが表示されたユーザーの同意ダイアログ

ユーザー アカウント

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

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

たとえば、「Google でログイン」を使用すると、アクティブな Google アカウント セッションが確立されるため、認証リクエストを行う際に、後でユーザーに Google アカウントへのログインを求める必要がなくなります。ユーザー名、パスワード、または他の ID プロバイダなどの他の手段でアプリに対してユーザーを認証する場合、ユーザーは同意のために最初に Google アカウントにログインするよう求められます。

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

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

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

同意の確認と取り消し

ユーザーはいつでも Google アカウントの設定から同意の確認や取り消しを行えます。

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

その他の承認オプション

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

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

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