アカウントは、業界標準の OAuth 2.0 認可コードフローを使用してリンクされます。
エージェント向けの OAuth 2.1 と PKCE
ステートレス AI エージェントとマルチモーダル パイプラインには、OAuth 2.1 の適用をおすすめします。
- PKCE(Proof Key for Code Exchange): 認可コードフローを保護し、傍受攻撃を防ぐために使用する必要があります。
- 暗黙的フローなし: 暗黙的フローでは、アクセス トークンが URL で公開されるため、エージェント環境でセキュリティ リスクが生じます。
サービスは、OAuth 2.0/2.1 準拠の認証エンドポイントとトークン交換エンドポイントをサポートする必要があります。
プロジェクトを作成する
アカウント リンクを使用するプロジェクトを作成するには:
- Google API コンソールに移動します。
- [プロジェクトの作成] をクリックします。
- 名前を入力するか、生成された候補を受け入れます。
- 残りのフィールドを確認または編集します。
- [作成] をクリックします。
プロジェクト ID を表示するには:
- Google API コンソールに移動します。
- ランディング ページの表でプロジェクトを探します。プロジェクト ID は [ID] 列に表示されます。
OAuth 同意画面を構成する
Google アカウントのリンク プロセスには同意画面が含まれています。この画面では、データへのアクセスをリクエストしているアプリケーション、リクエストしているデータの種類、適用される規約がユーザーに通知されます。Google API クライアント ID を生成する前に、OAuth 同意画面を構成する必要があります。
- Google API コンソールの OAuth 同意画面 ページを開きます。
- プロンプトが表示されたら、作成したプロジェクトを選択します。
[OAuth 同意画面] ページでフォームに入力し、[保存] ボタンをクリックします。
アプリケーション名: 同意を求めるアプリケーションの名前。名前はアプリケーションを正確に反映し、ユーザーが他の場所で見るアプリケーション名と一致している必要があります。アプリケーション名は、アカウント リンクの同意画面に表示されます。
アプリケーション ロゴ: 同意画面に表示される画像で、ユーザーがアプリを認識しやすくなります。ロゴは、アカウント リンクの同意画面とアカウント設定に表示されます。
サポートメール: 同意に関して問い合わせる際に使用します。
Google API のスコープ: スコープを使用すると、アプリケーションはユーザーの非公開の Google データにアクセスできます。Google アカウントのリンクのユースケースでは、デフォルトのスコープ(email、profile、openid)で十分です。機密性の高いスコープを追加する必要はありません。一般的に、スコープは事前にリクエストするのではなく、アクセスが必要になったときに段階的にリクエストすることが効果的な手法です。詳細
承認済みドメイン: デベロッパーとユーザーを保護するために、Google では、OAuth を使用して認証するアプリケーションのみに承認済みドメインの使用を許可しています。アプリケーションのリンクは、承認済みドメインでホストする必要があります。詳細
アプリケーションのホームページへのリンク: アプリケーションのホームページ。承認済みドメインでホストする必要があります。
アプリケーションのプライバシー ポリシーへのリンク: Google アカウント リンクの同意画面に表示されます。承認済みドメインでホストする必要があります。
アプリケーションの利用規約へのリンク(省略可): 承認済みドメインでホストする必要があります。
図 1. 架空のアプリケーション Tunery の Google アカウントのリンクの同意画面
[検証ステータス] を確認します。アプリケーションの検証が必要な場合は、[検証のために送信] ボタンを**クリック**して、検証を受けるためにアプリケーションを送信します。詳しくは、OAuth の検証要件をご覧ください。
OAuth サーバーを実装する
OAuth 2.0 服务器的 授权代码流程实现包含两个端点,您的服务通过 HTTPS 提供这两个端点。第一个端点是授权端点,负责查找用户或征得用户同意以获取数据访问权限。授权端点会向尚未登录的用户显示登录界面,并记录用户对所请求访问权限的同意情况。第二个端点是令牌交换端点,用于获取加密字符串(称为令牌),这些令牌授权用户访问您的服务。
当 Google 应用需要调用您服务的某个 API 时,Google 会同时使用这些端点,以获取用户授权代表他们调用这些 API。
Google 账号关联:OAuth 授权代码流程
以下序列图详细介绍了用户、Google 和您服务的端点之间的交互。
角色和职责
下表定义了 Google 账号关联 (GAL) OAuth 流程中参与者的角色和职责。请注意,在 GAL 中,Google 充当 OAuth 客户端 ,而您的服务充当 身份/服务提供方 。
| 参与者 / 组件 | GAL 角色 | 职责 |
|---|---|---|
| Google 应用 / 服务器 | OAuth 客户端 | 发起流程,接收授权代码,将其交换为 令牌,并安全地存储这些令牌以访问您服务的 API。 |
| 您的授权端点 | 授权服务器 | 对用户进行身份验证,并征得用户同意与 Google 分享其数据访问权限。 |
| 您的令牌交换端点 | 授权服务器 | 验证授权代码和刷新令牌,并向 Google 服务器颁发访问 令牌。 |
| Google 重定向 URI | 回调端点 | 接收来自您的授权服务的用户重定向,其中包含
code 和 state 值。 |
由 Google 发起的 OAuth 2.0 授权代码流程会话具有以下流程:
- Google 在用户的浏览器中打开您的授权端点。如果流程是在仅支持语音的设备上为 Action 启动的,Google 会将执行转移到手机。
- 用户登录(如果尚未登录),并授予 Google 权限以使用您的 API 访问其数据(如果尚未授予权限)。
- 您的服务会创建 授权代码并将其返回给 Google。为此,请将用户的浏览器重定向回 Google,并将授权代码附加到请求中。
- Google 会将授权代码发送到您的令牌交换端点,该端点会验证代码的真实性并返回 访问令牌和 刷新令牌。访问令牌是一种短期令牌,您的服务会将其作为访问 API 的凭据。刷新令牌是一种长期令牌,Google 可以存储该令牌,并在访问令牌过期时使用它来获取新的访问令牌。
- 用户完成账号关联流程后,Google 发送的每个后续请求都包含访问令牌。
实现方案
请按照以下步骤实现授权代码流程。
第 1 步:处理授权请求
当 Google 发起账号关联时,它会将用户重定向到您的授权端点。如需了解详细的协议合同和参数要求,请参阅授权端点。
如需处理请求,请执行以下操作:
验证请求:
- 确认
client_id与分配给 Google 的客户端 ID 相匹配。 - 确认
redirect_uri与预期的 Google 重定向 网址:none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID相匹配 - 验证
response_type是否为code。
- 确认
对用户进行身份验证:
- 检查用户是否已登录您的服务。
- 如果用户未登录,请提示他们完成您的登录或注册流程。
生成授权代码:
- 创建与用户和客户端关联的唯一且难以猜测的授权代码。
- 将代码设置为在约 10 分钟后过期。
重定向回 Google:
- 将浏览器重定向到
redirect_uri中提供的网址。 - 附加以下查询参数:
code:您生成的授权代码。state:从 Google 收到的未修改的状态值。
- 将浏览器重定向到
第 2 步:处理令牌交换请求
您的令牌交换端点会处理两种类型的请求:将代码交换为令牌,以及刷新过期的访问令牌。如需了解详细的协议合同和参数要求,请参阅令牌交换端点。
A. 将授权代码交换为令牌
当 Google 收到授权代码时,它会调用您的令牌交换端点 (POST) 以检索令牌。
验证请求:
- 验证
client_id和client_secret。 - 验证授权代码是否有效且未过期。
- 确认
redirect_uri与第 1 步中使用的值相匹配。 - 如果验证失败,则返回 HTTP
400 Bad Request,并返回{"error": "invalid_grant"}。
- 验证
颁发令牌:
- 生成长期有效的
refresh_token和短期有效的access_token(通常为 1 小时)。 - 返回 HTTP
200 OK,并返回标准 JSON 令牌响应。
- 生成长期有效的
B. 刷新访问令牌
当访问令牌过期时,Google 会使用刷新令牌请求新的访问令牌。
验证请求:
- 验证
client_id、client_secret和refresh_token。 - 如果验证失败,则返回 HTTP
400 Bad Request,并返回{"error": "invalid_grant"}。
- 验证
颁发新的访问令牌:
- 生成新的短期有效的
access_token。 - 返回 HTTP
200 OK,并返回 JSON 令牌响应(可以选择包含新的刷新令牌)。
- 生成新的短期有效的
处理 userinfo 请求
userinfo 端点是受 OAuth 2.0 保护的资源,会返回关联用户的声明。实现和托管 userinfo 端点是可选的,但以下用例除外:
从您的令牌端点成功检索到访问令牌后,Google 会向您的 userinfo 端点发送请求,以检索关联用户的基本个人资料信息。
| userinfo 端点请求标头 | |
|---|---|
Authorization header |
Bearer 类型的访问令牌。 |
例如,如果您的 userinfo 端点可通过
https://myservice.example.com/userinfo 时,请求可能如下所示:
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
为了让 userinfo 端点能够处理请求,请执行以下步骤:
- 从 Authorization 标头中提取访问令牌,并返回与访问令牌相关联的用户的信息。
- 如果访问令牌无效,则使用
WWW-Authenticate响应标头返回 HTTP 401 Unauthorized 错误。下面是一个 userinfo 错误响应示例: 如果在关联过程中返回 401 未经授权错误或任何其他失败的错误响应,该错误将无法恢复,检索到的令牌将被舍弃,并且用户必须重新开始关联流程。HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
如果访问令牌有效,则返回 HTTPS 正文中包含以下 JSON 对象的 HTTP 200 响应 回答:
如果您的 userinfo 端点返回 HTTP 200 成功响应,则系统会针对用户的 Google 账号注册检索到的令牌和声明。{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }userinfo 端点响应 sub系统中用于识别用户的唯一 ID。 email用户的电子邮件地址。 given_name可选:用户的名字。 family_name可选:用户的姓氏。 name可选:用户的全名。 picture可选:用户的个人资料照片。
実装の検証
OAuth 2.0 Playground ツールを使用して、実装を検証できます。
このツールで、次の手順を行います。
- [構成] 設定をクリックして、[OAuth 2.0 構成] ウィンドウを開きます。
- [OAuth flow] フィールドで、[クライアントサイド] を選択します。
- [OAuth Endpoints] フィールドで、[Custom] を選択します。
- 対応するフィールドに、OAuth 2.0 エンドポイントと Google に割り当てたクライアント ID を指定します。
- [Step 1] セクションで、Google スコープを選択しないでください。代わりに、このフィールドを空白のままにするか、サーバーで有効なスコープを入力します(OAuth スコープを使用しない場合は任意の文字列を入力します)。完了したら、[Authorize APIs] をクリックします。
- [Step 2] セクションと [Step 3] セクションで、OAuth 2.0 フローを確認し、各ステップが意図したとおりに動作することを確認します。
Google アカウント リンク デモツールを使用して、実装を検証できます。
このツールで、次の手順を行います。
- [Google でログイン] ボタンをクリックします。
- リンクするアカウントを選択します。
- サービス ID を入力します。
- 必要に応じて、アクセスをリクエストするスコープを 1 つ以上入力します。
- [Start Demo] をクリックします。
- 確認のメッセージが表示されたら、リンク リクエストに同意または拒否できることを確認します。
- プラットフォームにリダイレクトされることを確認します。