קישור חשבון Google באמצעות OAuth

החשבונות מקושרים באמצעות תהליכי הרשאה ומרומזים של OAuth 2.0, שהם תהליכים מקובלים בתחום.

השירות שלכם צריך לתמוך בנקודות קצה של הרשאה ושל החלפת אסימונים שתואמות ל-OAuth 2.0.

在 隐式 流程中，Google 会在用户的浏览器中打开您的授权端点。成功登录后，您会向 Google 返回长期有效的访问令牌。此访问令牌现在包含在 Google 发送的每个请求中。

在 授权代码 流程中，您需要两个端点：

  • 授权 端点，用于向尚未登录的用户显示登录界面。授权端点还会创建一个短期有效的授权代码，以记录用户对所请求访问权限的同意情况。

  • 令牌交换 端点，负责两种类型的交换：

    1. 将授权代码交换为长期有效的刷新令牌和短期有效的访问令牌。当用户完成账号关联流程时，会发生此交换。
    2. 将长期有效的刷新令牌交换为短期有效的访问令牌。 当 Google 需要新的访问令牌（因为其拥有的访问令牌已过期）时，会发生此交换。

选择 OAuth 2.0 流程

虽然 隐式 流程的实现较为简单，但 Google 建议通过隐式流程颁发的访问令牌永不过期。这是因为，如果令牌通过隐式流程过期，用户就必须再次关联其账号。如果您出于安全原因需要令牌过期，我们强烈建议您改用 授权代码 流程。

设计准则

本部分介绍了您为 OAuth 关联流程托管的用户界面的设计要求和建议。在 Google 的应用调用后，您的平台会向用户显示“登录 Google”页面和账号关联同意屏幕。用户同意关联账号后，系统会将用户重定向回 Google 的应用。

此图显示了用户将其 Google 账号与您的身份验证系统相关联的步骤。第一个屏幕截图显示了用户从您的平台发起的关联。第二张图片显示了用户登录 Google 的界面，第三张图片显示了用户同意并确认将自己的 Google 账号与您的应用相关联的界面。最后一张屏幕截图显示了 Google 应用中成功关联的用户账号。
图 1.账号关联用户登录 Google 和同意屏幕。

要求

  1. 您必须说明，用户的账号将与 Google 关联， 而不是与 Google Home 或 Google 助理等特定 Google 产品关联。

建议

建议您执行以下操作：

  1. 显示 Google 的隐私权政策。在权限请求页面上添加指向 Google 的隐私权政策 的链接。

  2. 要共享的数据。 使用清晰简洁的语言告知用户 Google 需要哪些数据及其原因。

  3. 明确的号召性用语。 在同意屏幕上添加明确的号召性用语，例如“同意并关联”。 这是因为用户需要了解他们需要与 Google 共享哪些数据才能关联其账号。

  4. 能够取消。 为用户提供返回或取消的方式（如果他们选择不关联）。

  5. 清晰的登录流程。 确保用户有清晰的 Google 账号登录方法，例如用户名和密码字段，或 “使用 Google 账号登录”。

  6. 能够取消关联。 为用户提供取消关联的机制，例如指向您平台上账号设置的网址。或者，您可以 添加指向 Google 账号的链接，用户 可以在其中管理其关联的账号。

  7. 能够更改用户账号。 为用户提供切换账号的方法。如果用户倾向于拥有多个账号，这一点尤其有用。

    • 如果用户必须关闭权限请求页面才能切换账号，请向 Google 发送可恢复的错误，以便用户可以使用 OAuth 关联 和 隐式 流程登录所选账号。

  8. 添加您的徽标。 在权限请求页面上显示您的公司徽标。请按照您的样式指南放置徽标。如果您想要或需要 同时显示 Google 的徽标，请参阅 徽标和商标。

Create the project

To create your project to use account linking:

  1. Go to the Google API Console.
  2. Click Create project.
  3. Enter a name or accept the generated suggestion.
  4. Confirm or edit any remaining fields.
  5. Click Create.

To view your project ID:

  1. Go to the Google API Console.
  2. Find your project in the table on the landing page. The project ID appears in the ID column.

The Google Account Linking process includes a consent screen which tells users the application requesting access to their data, what kind of data they are asking for and the terms that apply. You will need to configure your OAuth consent screen before generating a Google API client ID.

  1. Open the OAuth consent screen page of the Google APIs console.
  2. If prompted, select the project you just created.

  3. On the "OAuth consent screen" page, fill out the form and click the “Save” button.

    Application name: The name of the application asking for consent. The name should accurately reflect your application and be consistent with the application name users see elsewhere. The application name will be shown on the Account Linking consent screen.

    Application logo: An image on the consent screen that will help users recognize your app. The logo is shown on Account linking consent screen and on account settings

    Support email: For users to contact you with questions about their consent.

    Scopes for Google APIs: Scopes allow your application to access your user's private Google data. For the Google Account Linking use case, default scope (email, profile, openid) is sufficient, you don’t need to add any sensitive scopes. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. Learn more.

    Authorized domains: To protect you and your users, Google only allows applications that authenticate using OAuth to use Authorized Domains. Your applications' links must be hosted on Authorized Domains. Learn more.

    Application Homepage link: Home page for your application. Must be hosted on an Authorized Domain.

    Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.

    Application Terms of Service link (Optional): Must be hosted on an Authorized Domain.

    Figure 1. Google Account Linking Consent Screen for a fictitious Application, Tunery

  4. Check "Verification Status", if your application needs verification then click the "Submit For Verification" button to submit your application for verification. Refer to OAuth verification requirements for details.

הטמעת שרת OAuth

n

כדי לתמוך בתהליך המשתמע של OAuth 2.0, השירות שלכם צריך לספק נקודת קצה להרשאה באמצעות HTTPS. נקודת הקצה הזו אחראית לאימות ולקבלת הסכמה מהמשתמשים לגישה לנתונים. נקודת הקצה של ההרשאה מציגה למשתמשים שלא מחוברים כבר ממשק משתמש לכניסה, ומתעדת את ההסכמה לגישה המבוקשת.

כשיישום של Google צריך לשלוח קריאה לאחד מממשקי ה-API המורשים של השירות שלכם, Google משתמשת בנקודת הקצה הזו כדי לקבל מהמשתמשים שלכם הרשאה לשלוח קריאות לממשקי ה-API האלה בשמם.

קישור של חשבון Google: תהליך מרומז של OAuth

בתרשים הרצף הבא מפורטות האינטראקציות בין המשתמש, Google ונקודות הקצה של השירות שלכם.

משתמש אפליקציית Google / דפדפן נקודת הקצה של האימות ‫1. המשתמש יוזם את הקישור 2. הפניה לנקודת הקצה של אימות (GET) client_id, redirect_uri, state, scope 3. הצגת מסך הכניסה ומסך בקשת ההסכמה 4. המשתמש מאמת את עצמו ומעניק הסכמה 5. הפניה חזרה אל Google עם טוקן (GET) access_token, state 6. שמירת טוקנים של משתמשים בחנות 7. גישה למשאבים של משתמשים
איור 1. רצף האירועים בזרם הענקת גישה משתמע של OAuth 2.0 לקישור של חשבון Google.

תפקידים ותחומי אחריות

בטבלה הבאה מוגדרים התפקידים והאחריות של הגורמים בזרם הענקת גישה משתמע של OAuth לקישור של חשבון Google (GAL). חשוב לזכור שב-GAL, ‏ Google פועלת כלקוח OAuth, והשירות שלכם פועל כספק זהויות או ספק שירותים.

המשתמש / הרכיב תפקיד ב-GAL תחומי אחריות
אפליקציית Google / שרת לקוח OAuth מתחיל את התהליך, מקבל את אסימון הגישה באמצעות הפניה אוטומטית בדפדפן, ומאחסן אותו בצורה מאובטחת כדי לגשת לממשקי ה-API של השירות.
נקודת הקצה להרשאה שרת הרשאות השירות מאמת את המשתמשים, מקבל את ההסכמה שלהם ומנפיק אסימוני גישה לטווח ארוך ישירות ל-Google.
‫URI של הפניה לכתובת אחרת ב-Google נקודת קצה של קריאה חוזרת (callback) מקבל את ההפניה האוטומטית של המשתמש משירות ההרשאה עם הערכים access_token ו-state בקטע של כתובת ה-URL.

בדרך כלל, סשן של זרם הענקת גישה משתמע באמצעות OAuth 2.0 שמתחיל על ידי Google מתנהל כך:

  1. ‫Google פותחת את נקודת הקצה של ההרשאה בדפדפן של המשתמש. המשתמש נכנס לחשבון שלו, אם הוא לא מחובר כבר, ומעניק ל-Google הרשאה לגשת לנתונים שלו באמצעות ה-API שלכם, אם הוא עדיין לא העניק הרשאה.
  2. השירות שלכם יוצר אסימון גישה ומחזיר אותו ל-Google. כדי לעשות זאת, צריך להפנות את הדפדפן של המשתמש בחזרה אל Google עם אסימון הגישה שמצורף לבקשה.
  3. ‫Google קוראת לממשקי ה-API של השירות ומצרפת את אסימון הגישה לכל בקשה. השירות שלכם מאמת שאסימון הגישה מעניק ל-Google הרשאה לגשת ל-API, ואז משלים את הקריאה ל-API.

טיפול בבקשות הרשאה

כשנדרש קישור חשבון באפליקציית Google באמצעות זרם הענקת גישה משתמע של OAuth 2.0, ‏ Google שולחת את המשתמש לנקודת הקצה של ההרשאה עם בקשה שכוללת את הפרמטרים הבאים:

פרמטרים של נקודת קצה להרשאה
client_id מזהה הלקוח שהקציתם ל-Google.
redirect_uri כתובת ה-URL שאליה שולחים את התשובה לבקשה הזו.
state ערך לניהול חשבונות שמועבר בחזרה ל-Google ללא שינוי ב-URI של ההפניה.
response_type סוג הערך שיוחזר בתשובה. בתהליך המרומז של OAuth 2.0, סוג התגובה הוא תמיד 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

כדי שנקודת הקצה של ההרשאה תוכל לטפל בבקשות כניסה, צריך לבצע את השלבים הבאים:

  1. כדי למנוע מתן גישה לאפליקציות לקוח לא מכוונות או לא מוגדרות, צריך לוודא שהערכים של client_id ושל redirect_uri נכונים:

    • מוודאים שהערך client_id זהה למזהה הלקוח שהקציתם ל-Google.
    • בודקים שכתובת ה-URL שצוינה על ידי הפרמטר redirect_uri היא מהצורה הבאה: 
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID

  2. בודקים אם המשתמש מחובר לשירות שלכם. אם המשתמש לא מחובר, צריך להשלים את תהליך הכניסה או ההרשמה לשירות.

  3. יוצרים אסימון גישה ש-Google יכולה להשתמש בו כדי לגשת ל-API. אסימון הגישה יכול להיות כל ערך מחרוזת, אבל הוא חייב לייצג באופן ייחודי את המשתמש ואת הלקוח שאליהם האסימון מתייחס, ואי אפשר לנחש אותו.

  4. שליחת תגובת HTTP שמפנה את הדפדפן של המשתמש לכתובת ה-URL שצוינה בפרמטר redirect_uri. צריך לכלול את כל הפרמטרים הבאים בפרגמנט URL:

    • ‫access_token: אסימון הגישה שיצרתם
    • token_type: המחרוזת bearer
    • ‫state: ערך הסטטוס שלא השתנה מהבקשה המקורית

    דוגמה לכתובת ה-URL שמתקבלת: 

    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING

ה-handler של ההפניה האוטומטית מסוג OAuth 2.0 של Google מקבל את טוקן הגישה ומאשר שהערך של state לא השתנה. אחרי ש-Google מקבלת אסימון גישה לשירות שלכם, היא מצרפת את האסימון לקריאות הבאות לממשקי ה-API של השירות.

处理 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 端点能够处理请求，请执行以下步骤：

  1. 从 Authorization 标头中提取访问令牌，并返回与访问令牌相关联的用户的信息。
  2. 如果访问令牌无效，则使用 WWW-Authenticate 响应标头返回 HTTP 401 Unauthorized 错误。下面是一个 userinfo 错误响应示例： 
    HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
    如果在关联过程中返回 401 未经授权错误或任何其他失败的错误响应，该错误将无法恢复，检索到的令牌将被舍弃，并且用户必须重新开始关联流程。

  3. 如果访问令牌有效，则返回 HTTPS 正文中包含以下 JSON 对象的 HTTP 200 响应 回答：

    {
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}
     如果您的 userinfo 端点返回 HTTP 200 成功响应，则系统会针对用户的 Google 账号注册检索到的令牌和声明。

    userinfo 端点响应
    sub 系统中用于识别用户的唯一 ID。
    email 用户的电子邮件地址。
    given_name 可选：用户的名字。
    family_name 可选：用户的姓氏。
    name 可选：用户的全名。
    picture 可选：用户的个人资料照片。

אימות ההטמעה

כדי לאמת את ההטמעה, אפשר להשתמש בכלי OAuth 2.0 Playground.

בכלי, מבצעים את השלבים הבאים:

  1. לוחצים על Configuration (הגדרה) כדי לפתוח את חלון ההגדרה של OAuth 2.0.
  2. בשדה OAuth flow (תהליך OAuth), בוחרים באפשרות Client-side (בצד הלקוח).
  3. בשדה OAuth Endpoints (נקודות קצה של OAuth), בוחרים באפשרות Custom (מותאם אישית).
  4. בשדות המתאימים, מציינים את נקודת הקצה של OAuth 2.0 ואת מזהה הלקוח שהקציתם ל-Google.
  5. בקטע Step 1, לא בוחרים אף היקף של Google. במקום זאת, משאירים את השדה הזה ריק או מקלידים היקף הרשאות שתקף לשרת (או מחרוזת שרירותית אם לא משתמשים בהיקפי הרשאות OAuth). בסיום, לוחצים על הרשאת ממשקי API.
  6. בקטעים שלב 2 ושלב 3, עוברים על תהליך ההרשאה באמצעות OAuth 2.0 ומוודאים שכל שלב פועל כמו שצריך.

כדי לאמת את ההטמעה, אפשר להשתמש בכלי Google Account Linking Demo.

בכלי, מבצעים את השלבים הבאים:

  1. לוחצים על הכפתור כניסה באמצעות חשבון Google.
  2. בוחרים את החשבון שרוצים לקשר.
  3. מזינים את מזהה השירות.
  4. אפשר להזין היקף אחד או יותר שרוצים לבקש גישה אליהם.
  5. לוחצים על התחלת ההדגמה.
  6. כשמופיעה הבקשה, מאשרים שרוצים להסכים לבקשת הקישור או לדחות אותה.
  7. מוודאים שמופנים לפלטפורמה שלכם.