アカウントは、業界標準の OAuth 2.0 インプリシット フローと認可コードフローを使用してリンクされます。サービスは、OAuth 2.0 準拠の認可エンドポイントとトークン交換エンドポイントをサポートする必要があります。
在隐式流程中,Google 会在用户的浏览器中打开您的授权端点。成功登录后,您将向 Google 返回一个长期访问令牌。现在,此访问令牌会包含在 Google 发送的每个请求中。
在授权代码流程中,您需要两个端点:
授权端点,用于向尚未登录的用户显示登录界面。授权端点还会创建一个短期授权代码,以记录用户对所请求访问权限的同意情况。
令牌交换端点,负责两种类型的交换:
- 使用授权代码换取长期有效的刷新令牌和短期有效的访问令牌。当用户完成账号关联流程时,就会发生此交换。
- 将长期有效的刷新令牌换成短期有效的访问令牌。当 Google 需要新的访问令牌(因为现有访问令牌已过期)时,就会发生这种交换。
选择 OAuth 2.0 流程
虽然隐式流程更易于实现,但 Google 建议通过隐式流程签发的访问令牌永不过期。这是因为,在隐式流程中,令牌过期后,系统会强制用户重新关联其账号。如果您出于安全考虑需要令牌过期,我们强烈建议您改用授权码流程。
设计准则
本部分介绍了您为 OAuth 关联流程托管的用户屏幕的设计要求和建议。在 Google 应用调用该 API 后,您的平台会向用户显示登录 Google 页面和账号关联意见征求界面。同意关联账号后,系统会将用户重定向回 Google 的应用。
要求
- 您必须说明用户的账号将与 Google 相关联,而非 Google Home 或 Google 助理等特定 Google 产品相关联。
建议
建议您执行以下操作:
显示 Google 的隐私权政策。在同意屏幕上添加指向 Google 隐私权政策的链接。
要共享的数据。使用清晰简洁的语言告知用户 Google 需要哪些用户数据以及原因。
添加醒目的号召性用语。在用户同意页面上提供明确的号召性用语,例如“同意并关联”。这是因为用户需要了解他们需要与 Google 分享哪些数据才能关联账号。
可以取消。为用户提供返回或取消链接的途径,如果用户选择不进行关联。
明确的登录流程。确保用户有明确的 Google 账号登录方法,例如用户名和密码字段或使用 Google 账号登录。
能够解除关联。提供一种可让用户解除关联的机制,例如指向您平台上账号设置的网址。或者,您也可以添加指向 Google 账号的链接,以便用户管理其关联的账号。
能够更改用户账号。建议用户切换账号的方法。如果用户通常拥有多个账号,这种做法尤为有益。
- 如果用户必须关闭意见征求界面才能切换账号,请向 Google 发送可恢复的错误,以便用户可以使用 OAuth 关联和隐式流程登录所需的账号。
添加您的徽标。在意见征求页面上显示您的公司徽标。 按照您的样式准则放置徽标。如果您还想显示 Google 的徽标,请参阅徽标和商标。
创建项目
如需创建使用账号关联的项目,请执行以下操作:
- 点击 Create project。
- 输入名称或接受生成的建议。
- 确认或修改所有剩余字段。
- 点击创建。
如需查看项目 ID,请执行以下操作:
- 在着陆页的表格中找到您的项目。项目 ID 会显示在 ID 列中。
配置 OAuth 权限请求页面
Google 账号关联流程包含一个权限请求页面,该页面会告知用户哪个应用在请求访问其数据、请求访问哪些类型的数据,以及适用的条款。您需要先配置 OAuth 权限请求页面,然后才能生成 Google API 客户端 ID。
- 打开 Google API 控制台的 OAuth 同意屏幕页面。
- 如果出现提示,请选择您刚刚创建的项目。
在“OAuth 同意屏幕”页面上,填写表单,然后点击“保存”按钮。
应用名称:征求用户同意的应用的名称。名称应准确反映您的应用,并与用户在其他位置看到的应用名称保持一致。应用名称将显示在账号关联权限请求界面上。
应用徽标:权限请求页面上显示的一张图片,用以让用户认出您的应用。徽标会显示在账号关联权限请求页面和账号设置中
支持电子邮件地址:供用户就其同意问题与您联系。
Google API 的范围:借助范围,您的应用可以访问用户的非公开 Google 数据。对于 Google 账号关联使用情形,默认范围(电子邮件地址、个人资料、openid)就足够了,您无需添加任何敏感范围。一般来说,最佳做法是在需要访问权限时逐步请求权限范围,而不是提前请求。了解详情。
已获授权的网域:为了保护您和您的用户,Google 只允许使用 OAuth 进行身份验证的应用使用已获授权的网域。应用的链接必须托管在已获授权的网域上。了解详情。
应用首页链接:应用的首页。必须托管在已获授权的网域上。
应用隐私权政策链接:显示在 Google 账号关联意见征求界面上。必须托管在已获授权的网域上。
应用服务条款链接(可选):必须托管在已获授权的网域上。
图 1. 虚构应用 Tunery 的 Google 账号关联意见征求界面
查看“验证状态”,如果您的应用需要验证,请点击“提交以供验证”按钮,提交应用以供验证。如需了解详情,请参阅 OAuth 验证要求。
OAuth サーバーを実装する
OAuth 2.0 の暗黙的フローをサポートするには、サービスで認証を行います。 使用できます。このエンドポイントは、認証と認可を担当します。 データアクセスについてユーザーから同意を得る。認可エンドポイントは、ログインしていないユーザーにログイン用の UI を表示し、リクエストされたアクセスへの同意を記録します。
Google アプリケーションが、サービスの承認済み API のいずれかを呼び出す必要がある場合は、 Google はこのエンドポイントを使用して、これらの API を呼び出す権限をユーザーから取得します 委任できます。
通常、Google が開始する OAuth 2.0 インプリシット フローのセッションは次のような流れになります。
- Google がユーザーのブラウザで認可エンドポイントを開きます。「 ユーザーがログインし(まだログインしていない場合)、Google に次の権限を与える API を使用してデータにアクセスする必要があります(まだ権限を付与していない場合)。
- サービスによってアクセス トークンが作成され、トークンが Googleそのためには、アクセス権を使ってユーザーのブラウザを Google にリダイレクトします。 リクエストに添付されたトークンです。
- Google がサービスの API を呼び出し、アクセス トークンを できます。サービスが、そのアクセス トークンが Google Cloud アクセスが承認され、API 呼び出しが完了します。
認可リクエストの処理
Google アプリケーションで OAuth 2.0 経由でアカウント リンクを実行する必要がある場合 の暗黙的フローで、Google はユーザーを認可エンドポイントに送り、 次のパラメータを含むリクエストです。
| 認可エンドポイントのパラメータ | |
|---|---|
client_id |
Google に割り当てたクライアント ID。 |
redirect_uri |
このリクエストに対するレスポンスを送信する URL。 |
state |
リダイレクト URL で変更されずに Google に返される会計上の値。 |
response_type |
レスポンスで返される値のタイプ。OAuth 2.0 暗黙の API では、
レスポンス タイプは常に token です。 |
user_locale |
Google アカウントの言語設定は RFC5646 ユーザーの使用言語にコンテンツをローカライズするために使用される形式を使用すること。 |
たとえば、認可エンドポイントが
https://myservice.example.com/auth の場合、リクエストは次のようになります。
GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&response_type=token&user_locale=LOCALE
認可エンドポイントでログイン リクエストを処理するには、次の操作を行います。 手順:
client_idとredirect_uriの値を検証する 意図しないクライアント アプリへのアクセスや構成ミスのあるクライアント アプリclient_idが、指定したクライアント ID と一致することを確認します。 割り当てられていますredirect_uriで指定された URL を確認します。 パラメータの形式は次のとおりです。https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
ユーザーがサービスにログインしているかどうか確認します。ユーザーがログインしていない場合は、サービスのログインまたは登録フローを完了します。
Google が API にアクセスするために使用するアクセス トークンを生成します。「 アクセス トークンには任意の文字列値を指定できますが、アクセス トークンを一意に 推測できるようにする必要があります。
ユーザーのブラウザを URL にリダイレクトする HTTP レスポンスを送信する
redirect_uriパラメータで指定します。URL フラグメントに次のパラメータをすべて含めます。access_token: 生成したアクセス トークンtoken_type: 文字列bearerstate: 元の状態から変更されていない状態の値 リクエスト
結果の URL の例を次に示します。
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
Google の OAuth 2.0 リダイレクト ハンドラがアクセス トークンを受け取り、
state 値が変更されていないことを確認します。Google は、
そのトークンを後続の呼び出しにアタッチします。
サービス API に追加できます。
userinfo リクエストを処理する
userinfo エンドポイントは、OAuth 2.0 で保護されたリソースで、リンクされたユーザーに関するクレームを返します。userinfo エンドポイントの実装とホストは任意ですが、以下のユースケースを除きます。
- Google One タップによるリンクされたアカウントへのログイン。
- Android TV のスムーズな定期購入。
トークン エンドポイントからアクセス トークンが正常に取得されると、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 Unauthorized またはその他の失敗したエラー レスポンスが返された場合、そのエラーは修復不能となり、取得したトークンは破棄されるため、ユーザーはリンク処理をやり直す必要があります。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 ツールを使用します。
ツールで、次の操作を行います。
- [Configuration] をクリックして [OAuth 2.0 Configuration] ウィンドウを開きます。
- [OAuth flow] フィールドで、[Client-side] を選択します。
- [OAuth Endpoints](OAuth エンドポイント)で、[Custom](カスタム)を選択します。
- 対応するフィールドに、OAuth 2.0 エンドポイントと Google に割り当てたクライアント ID を指定します。
- [ステップ 1] セクションで、Google スコープは選択しないでください。代わりに、このフィールドを空白のままにするか、サーバーで有効なスコープを入力します(OAuth スコープを使用しない場合は任意の文字列を入力します)。完了したら、[API を承認] をクリックします。
- ステップ 2 とステップ 3 のセクションで OAuth 2.0 フローを実行し、各ステップが意図したとおりに機能することを確認します。
実装を検証するには、Google アカウント リンクのデモツールを使用します。
ツールで次の操作を行います。
- [Google でログイン] ボタンをクリックします。
- リンクするアカウントを選択します。
- サービス ID を入力します。
- 必要に応じて、アクセスをリクエストするスコープを 1 つ以上入力します。
- [デモを開始] をクリックします。
- リンク リクエストに同意できることを確認して、リクエストを拒否します。
- プラットフォームにリダイレクトされることを確認します。