このガイドでは、ユーザー承認に Google Identity Services ライブラリを使用するか、独自の JavaScript ライブラリを実装するかを選択できます。このフローは、使用するウェブ アプリケーションに最適な OAuth 2.0 承認フローを選択するのに役立ちます。
このガイドを読む前に、概要とユーザー承認の仕組みのガイドに記載されている用語とコンセプトを理解していることを前提としています。
GIS ライブラリは、ユーザーのデバイスの対応ブラウザで実行されます。Node.js などのサーバー側の JavaScript フレームワークでの使用は想定されていません。代わりに、Google の Node.js クライアント ライブラリを使用してください。
このガイドでは、認証とデータ共有に関するトピックのみを説明します。ここではユーザー認証を確認しません。ユーザーの登録とログインについては、Google でログインと Google ログインからの移行ガイドをご覧ください。
GIS ライブラリが適しているかどうかを判断する
Google のライブラリを使用するか、ニーズに最適な独自のライブラリを作成するかを選択する必要があります。特長と機能の概要:
- Google の Identity Services JavaScript ライブラリは、次のことを実装します。
- ポップアップ ベースの同意フローによりリダイレクトが最小限に抑えられるため、ユーザーは承認プロセスの間、サイトにとどまることができます。
- クロスサイト リクエスト フォージェリ（CRSF）などのセキュリティ機能。
- 個々のスコープをリクエストしてユーザーの同意を確認するヘルパー メソッド。
- 人間が理解しやすいエラー処理とドキュメントへのリンク。エンジニアが開発中に使用する場合や、その後サイトを訪問したユーザーのためにリンクを提供します。
- Identity Services ライブラリを使用せずに実装する場合は、次の作業を行います。
- Google の OAuth 2.0 エンドポイント（リダイレクトを含む）を使用してリクエストとレスポンスを管理する。
- ユーザー エクスペリエンスを最適化する。
- リクエストとレスポンスを検証し、CSRF を防止するためのセキュリティ機能の実装。
- リクエストされたスコープに対してユーザーが同意していることを確認するメソッド。
- OAuth 2.0 エラーコードの管理、人が読める形式のメッセージの作成、ユーザーヘルプへのリンク。
要約すると、Google が提供する GIS ライブラリによって、OAuth 2.0 クライアントを迅速かつ安全に実装し、ユーザーの認証処理を最適化できます。
認可フローの選択
Google Identity Services JavaScript ライブラリを使用するのか、独自のライブラリを作成するのかに関係なく、2 つの OAuth 2.0 認可フロー（暗黙的コードまたは認可コード）のいずれかを選択する必要があります。
どちらのフローでも、Google API の呼び出しに使用できるアクセス トークンが生成されます。
この 2 つのフローの主な違いは次のとおりです。
- ユーザーアクションの数
- ユーザーが存在せずにアプリが Google API を呼び出すかどうか、
- エンドポイントをホストし、個々のユーザー アカウントのユーザーごとの更新トークンを保存するために、バックエンド プラットフォームが必要な場合。
- セキュリティレベルを柔軟に設定できます。
フローを比較してセキュリティ要件を評価する際は、ユーザー セキュリティ レベルが選択したスコープによって異なることを考慮する必要があります。たとえば、カレンダーの招待状を読み取り専用で閲覧する場合、読み取り/書き込みのスコープを使用してドライブ内のファイルを編集するよりもリスクが低いと考えることができます。
OAuth 2.0 フローの比較
| 暗黙的フロー | 認可コードフロー | |
| ユーザーの同意が必要 | すべてのトークン リクエストに対して行う（期限切れのトークンの置き換えを含む）。 | 最初のトークン リクエストのみ。 |
| ユーザーが実在している必要があります | ○ | いいえ、オフラインで使用できます。 |
| ユーザー セキュリティ | 最低 | ほとんどのアプリケーションにはクライアント認証があり、ブラウザ内のトークン処理のリスクを回避します。 |
| アクセス トークンの発行 | ○ | ○ |
| 更新トークンの発行 | × | ○ |
| サポートされているブラウザが必要です | ○ | ○ |
| Google API の呼び出しに使用されるアクセス トークン | ユーザーのブラウザで実行されているウェブアプリからのみ取得できるようにする。 | バックエンド プラットフォームで実行されているサーバーから、またはユーザーのブラウザで実行されているウェブアプリから。 |
| バックエンド プラットフォームが必要 | × | 〇（エンドポイントのホスティングとストレージの場合）。 |
| 安全なストレージが必要 | × | ○（更新トークンの保存用） |
| 認可コード エンドポイントのホスティングが必要 | × | はい。Google から認証コードを受け取ります。 |
| アクセス トークンの有効期限の動作 | 新しい有効なアクセス トークンをリクエストして取得するには、ボタンの押下やリンクのクリックなどのユーザー操作が必要です。 | 最初のユーザー リクエスト後、プラットフォームは保存された更新トークンを交換し、Google API の呼び出しに必要な新しい有効なアクセス トークンを取得します。 |