OAuth と Google ログインのリンクタイプは、OAuth ベースのアカウント リンクに Google ログインを追加します。アクションでこのリンクタイプを使用する場合、フローは Google ログインから始まります。これにより、ユーザーの Google プロフィール情報がシステムに存在するかどうかを確認できます。そうでない場合は、標準の OAuth フローが開始されます。これら 2 つのリンクタイプを組み合わせることで、ユーザーはアクション内の ID を Google アカウントまたは Google 以外のアカウントにリンクできます。必要に応じて、Google プロフィール情報を使用して新しいアカウントを作成することもできます。
次のいずれかに該当する場合は、OAuth と Google ログインがアカウント リンク ソリューションとして推奨されます。
- 複数のプラットフォームにまたがるアクションがある(たとえば、アクションが Android アプリで動作する場合)。
- 既存の認証システムがあり、ユーザーが自分の ID を Google 以外のアカウントとリンクできるようにしたい場合。たとえば、ポイント プログラムを提供していて、ユーザーが既存のアカウントで獲得したポイントが失われないようにしたい場合などに便利です。
OAuth と Google ログインが適切なソリューションであることを確認するには、アカウント リンクタイプを選択するをご覧ください。
主な用語
OAuth と Google ログインの仕組みを理解する前に、次の用語を理解しておいてください。
- Google ID トークン: ユーザーの基本的な Google プロフィール情報(名前、メールアドレス、プロフィール写真)を含む、ユーザー ID の署名付きアサーション。Google ID トークンは JSON Web Token(JWT)です。デコードされたトークンの例を以下に示します。
{
"sub": 1234567890, // The unique ID of the user's Google Account
"iss": "https://accounts.google.com", // The token's issuer
"aud": "123-abc.apps.googleusercontent.com", // Client ID assigned to your Actions project
"iat": 233366400, // Unix timestamp of the token's creation time
"exp": 233370000, // Unix timestamp of the token's expiration time
"name": "Jan Jansen",
"given_name": "Jan",
"family_name": "Jansen",
"email": "jan@gmail.com", // If present, the user's email address
"locale": "en_US"
}
- アカウント ログイン ヘルパー インテント: アシスタントからアカウントのリンクフローをリクエストするために呼び出すヘルパー インテント。詳しくは、アカウントへのログインをご覧ください。
- コンテキスト文字列: アカウント ログイン ヘルパー インテントに追加するカスタム文字列。アカウントをリンクする理由をユーザーに伝えます。
- 認可コードフロー: OAuth 2.0 と Google ログインで実装できる OAuth 2.0 フロー。このフローには、次の 2 つのエンドポイントが必要です。
- 認可エンドポイント: まだログインしていないユーザーにログイン UI を表示するエンドポイント。リクエストされたアクセスへの同意が、有効期間の短い認証コードの形式で記録されます。
- トークン交換エンドポイント: このエンドポイントは、次の 2 種類の交換を行います。
- 認可コードを、有効期間の長い更新トークンと有効期間の短いアクセス トークンと交換します。この交換は、ユーザーがアカウント リンクのフローを行う際に行われます。
- 有効期間の長い更新トークンを有効期間の短いアクセス トークンと交換します。この交換は、アクセス トークンの有効期限が切れているために Google が新しいアクセス トークンを必要とする場合に発生します。
- 暗黙的なコードフロー: OAuth + Google ログインで実装できる OAuth 2.0 フロー。このフローには、認可エンドポイントのみが必要です。このフローでは、Google はユーザーのブラウザで認可エンドポイントを開きます。ログインに成功すると、有効期間の長いアクセス トークンを Google に返します。このアクセス トークンが、アシスタントからアクションに送信されるすべてのリクエストに含まれるようになりました。
- アクセス トークン: サービスがユーザーのデータの一部にアクセスすることを許可するトークン。アクセス トークンは個々のユーザーに関連付けられます。
- 更新トークン: 有効期間の短いアクセス トークンの有効期限が切れたときに、新しいアクセス トークンと交換されるトークン。
前提条件
OAuth と Google ログインのリンクタイプを使用するには、次のものが必要です。
- OAuth 2 サーバー
トークン交換エンドポイント
トークン交換エンドポイントを拡張して、ID トークンからの自動リンクとアカウント作成のための Google プロトコルのサポートを追加する必要があります(このエンドポイントへのリクエストに
intent=get
パラメータとintent=create
パラメータを追加する)。
仕組み
このセクションでは、OAuth と Google ログインの一般的なフローについて説明します。次のセクションの OAuth と GSI のフローでは、a)音声によるアカウントの作成を有効または無効にするかどうか、b)暗黙的なコードフローと認可コードフローのどちらを使用するかに基づいて、実行されるさまざまなフローについて説明します。
基本的な流れは次のとおりです。
- アクションが、Google プロフィールへのアクセスについてユーザーに同意を求めます。
- ユーザーが同意すると、アクションはユーザーの Google プロフィール情報を含む Google ID トークンを受け取ります。
- プロファイルのコンテンツを読み取るには、トークンを検証してデコードする必要があります。
- アクションはこのトークンを使用して、ユーザーの Google プロフィール情報がシステムに存在するかどうかを確認します。
- ログインしている場合、ユーザーはすでに Google アカウントでシステムにログインしており、アシスタントはユーザーの ID を Google アカウントにリンクします。ユーザーは、アカウントをリンクした状態でアシスタントと会話を続けることができます。
- 表示されない場合は、ステップ 5 をご覧ください。
- ユーザーは、a)Google プロフィール情報を使用して新しいアカウントを作成するか、b)別のアカウントでシステムにログインできます。ユーザーに表示される選択肢は、音声によるアカウントの作成を有効または無効にするかどうかによって異なります。ユーザーが別のアカウントでログインすることを選択した場合、標準の OAuth フローが開始されます。
- ユーザーが新しいアカウントを作成するか、別のプロバイダでログインすると、サービスが Google にアクセス トークンを返します。(認可コードフローを使用している場合、サービスも更新トークンを返します)。
- ユーザーは、アカウントをリンクしてアシスタントとの会話を続けることができます。
OAuth フローと GSI フロー
このセクションでは、OAuth と GSI で発生する可能性のあるさまざまなフローについて説明します。 これらの図では、暗黙的なコードフローではなく認可コードフローで発生するフローについて説明し、アクションの自然言語理解ソリューションとして Dialogflow を使用していることを前提としています。
各フローには、ユーザーがアクションを呼び出した後の一般的なステップが含まれます。
上記のフローでは、カスタマイズしたコンテキスト文字列を使用して actions.intent.SIGN_IN
ヘルパー インテントを呼び出します。このインテントでは、Google プロフィール情報にアクセスする権限がユーザーに求められます。ユーザーが同意すると、アシスタントは user@gmail.com
のプロフィール情報を含むリクエストを送信します。
この時点以降のフローは、音声によるアカウント リンクを構成しているかどうかと、ユーザーの情報がシステムにすでに存在するかどうかによって異なります。以降のセクションで、これらの各フローについて説明します。
音声アカウントの作成が有効なフロー
このセクションでは、音声によるアカウントの作成を有効にした場合に可能なアカウント リンクフローについて詳しく説明します。
フロー 1: ユーザーの情報がシステムに存在する
この場合、user@gmail.com
で表されるユーザーはバックエンドに存在するため、トークン交換エンドポイントはユーザーのトークンを返します。これで、アクション内のユーザー ID が Google アカウントにリンクされます。ユーザーの元のリクエスト(「通常注文」)はカスタム インテント order_drink.
と一致します。Webhook は、一致したインテントのフルフィルメントを処理し、データベースに user@gmail.com
の通常の順序を照会します。ユーザーはアシスタントとの会話を続けることができます。
フロー 2: ユーザーの情報がなく、ユーザーがアカウントを作成する
音声によるアカウントの作成を有効にしても、user@gmail.com
はバックエンドに存在しないため、アシスタントはユーザーに次のいずれかを行うかどうかを尋ねます。
a)Google プロフィール情報を使用してシステムに新しいアカウントを作成する。アカウントの新規作成は音声で行う
b)別のアカウントでシステムにログインする
この場合、ユーザーは音声を使用して新しいアカウントを作成することを選択します。Google は、アカウントの作成リクエストを使用して、サービスのトークン交換エンドポイントを呼び出します。このリクエストには、新しいアカウントを作成するために必要なコンポーネントを含む Google ID トークンが含まれています。その後、このトークンの情報(ユーザーの名前とメールアドレス)を使用して、ユーザーのアカウントを作成できます。
アカウントが作成されると、サービスは新しく作成されたアカウントのアクセス トークンと更新トークンを返します。これで、アクション内のユーザー ID が Google アカウントにリンクされます。ユーザーの元のリクエスト(「通常注文」)は、カスタム インテント order_drink.
と一致します。その後、Webhook は一致したインテントのフルフィルメントを処理し、ユーザーが新しいためまだ存在していない user@gmail.com
の通常の順序をデータベースに照会します。アクションはユーザーに何の注文をするか尋ねることができます。
フロー 3: ユーザーの情報がなく、ユーザーが別のアカウントでログインする
音声によるアカウントの作成をサポートしているため、アシスタントはユーザーに次のいずれかを行うかどうかを尋ねます。
a)Google プロフィール情報を使用してシステムに新しいアカウントを作成する。アカウントの新規作成は音声で行う
b)別のアカウントでシステムにログインする
この場合、ユーザーは別のアカウントでログインすることを選択し、それによって標準の OAuth フローが開始されます。音声専用デバイスでフローが開始された場合、実行はスマートフォンに転送されます。その後、Google がユーザーのブラウザで認可エンドポイントを開きます。ユーザーは、構成に応じて、a)Google ログインを使用していない既存のアカウントでサービスにログインするか、b)別のプロバイダを使用して新しいアカウントを作成するかを選択できます。OAuth フローの詳細については、OAuth のコンセプト ガイドをご覧ください。
ユーザーの認証情報を確認すると、サービスはアクセス トークンと更新トークンを Google に返します。これで、アクション内のユーザー ID が Google 以外のアカウントにリンクされました。ユーザーの元のリクエスト(「通常注文」)はカスタム インテント order_drink.
と一致します。その後、Webhook は一致したインテントのフルフィルメントを処理し、user@gmail.com
の通常の順序をデータベースに照会します。この順序はユーザーが初めてであるため、まだ存在していません。アクションは、ユーザーに注文したい内容や、通常の注文を設定するよう依頼できます。
音声アカウントの作成が無効になっているフロー
このセクションでは、音声によるアカウントの作成を無効にした場合に発生する可能性があるアカウントのリンクのフローについて詳しく説明します。
フロー 4: ユーザーの情報が存在しない
音声によるアカウントの作成を有効にしておらず、ユーザーがバックエンドに存在しないため、標準の OAuth フローが開始されます。アシスタントは、ユーザーのブラウザで認可エンドポイントを開きます(音声専用デバイスでフローが開始された場合、Google は画面のあるデバイスに実行を転送します)。ユーザーは、a)別のプロバイダでサービスに登録している場合は別のプロバイダでログインするか、b)別のプロバイダで新しいアカウントを作成するかを選択できます。OAuth フローの詳細については、OAuth のコンセプト ガイドをご覧ください。
ユーザーの認証情報を確認すると、サービスはアクセス トークンと更新トークンを Google に返します。これで、アクション内のユーザー ID が Google 以外のアカウントにリンクされました。ユーザーの元のリクエスト(「通常注文」)はカスタム インテント order_drink.
と一致します。その後、Webhook は一致したインテントのフルフィルメントを処理し、user@gmail.com
の通常の順序をデータベースに照会します。この順序はユーザーが初めてであるため、まだ存在していません。アクションは、ユーザーに通常の注文をセットアップするよう依頼できます。