סקירה כללית

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

פרוטוקול OAuth 2.0 המאובטח מאפשר לקשר בבטחה את חשבון Google של המשתמש לחשבון שלו בפלטפורמה, וכך לתת לאפליקציות ולמכשירים של Google גישה לשירותים שלכם.

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

תרחישים לדוגמה

ריכזנו כאן כמה מהסיבות להטמעת קישור לחשבון Google:

  • שיתוף הנתונים של משתמש מהפלטפורמה שלכם עם אפליקציות ושירותים של Google.

  • להפעיל את תוכן הסרטונים והסרטים באמצעות Google TV.

  • ניהול ושליטה במכשירים המחוברים ל-Google Smart Home באמצעות אפליקציית Google Home ו-Google Assistant, "Ok Google, turn on the lights".

  • אתם יכולים ליצור חוויות פונקציונליות מותאמות אישית של Google Assistant באמצעות פעולות שיחה, למשל "Ok Google, order my usual from Starbucks".

  • מאפשרים למשתמשים לצבור פרסים על ידי צפייה בשידורים חיים שעומדים בקריטריונים ב-YouTube, אחרי שהם מקשרים את חשבון Google שלהם לחשבון שותף שמעניק פרסים.

  • לאכלס מראש חשבונות חדשים במהלך ההרשמה באמצעות נתונים ששותפו בהסכמה מפרופיל בחשבון Google.

התכונות הנתמכות

התכונות הבאות נתמכות בקישור לחשבון Google:

  • שיתוף מהיר וקל של הנתונים באמצעות התהליך OAuth Linking implicit.

  • לשפר את האבטחה באמצעות התהליך OAuth Linking authorization code.

  • איך נכנסים משתמשים קיימים או נרשמים משתמשים חדשים מאומתים ב-Google לפלטפורמה, מקבלים את הסכמתם ומשתפים את הנתונים בצורה מאובטחת באמצעות קישור פשוט.

  • הפחתת החיכוך באמצעות App Flip. באפליקציה מהימנה של Google, הקשה אחת פותחת באופן מאובטח את האפליקציה המאומתת ל-Android או ל-iOS, והקשה אחת מאשרת את הסכמת המשתמש ומקשרת את החשבונות.

  • לשפר את פרטיות המשתמשים על ידי הגדרת היקפים מותאמים אישית לשיתוף רק נתונים נחוצים, להגביר את אמון המשתמשים על ידי הגדרה ברורה של אופן השימוש בנתונים שלהם.

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

תהליכי קישור חשבונות

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

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

קישור OAuth ('Web OAuth')

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

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

איור 1. קישור חשבון בטלפון של המשתמש באמצעות Web OAuth

קישור של App Flip שמבוסס על OAuth ('App Flip')

תהליך OAuth ששולח משתמשים לאפליקציה שלכם לצורך קישור.

קישור של App Flip מבוסס-OAuth מנחה את המשתמשים כשהם עוברים בין האפליקציות לנייד שאושרו ל-Android או ל-iOS לבין הפלטפורמה של Google, כדי לבדוק את השינויים המוצעים בגישה לנתונים ולהביע הסכמה לקישור החשבון שלהם בפלטפורמה לחשבון Google שלהם. כדי להפעיל את App Flip, השירות שלכם צריך לתמוך בקישור באמצעות OAuth או בקישור לחשבון Google שמבוסס על OAuth באמצעות התהליך קוד הרשאה.

התכונה 'העברת אפליקציות' נתמכת גם ב-Android וגם ב-iOS.

איך זה עובד:

אפליקציית Google בודקת אם האפליקציה שלכם מותקנת במכשיר של המשתמש:

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

איור 2. קישור חשבון בטלפון של המשתמש באמצעות App Flip

קישור פשוט מבוסס-OAuth ('פשוט')

קישור פשוט יותר של כניסה באמצעות חשבון Google שמבוסס על OAuth מוסיף את כניסה באמצעות חשבון Google לקישור OAuth, ומאפשר למשתמשים להשלים את תהליך הקישור בלי לצאת מהממשק של Google. כך אפשר לצמצם את החיכוכים ואת מספר המשתמשים שמפסיקים את התהליך. קישור פשוט מבוסס-OAuth משלב בין כניסה באמצעות חשבון Google לבין קישור באמצעות OAuth, ומספק את חוויית המשתמש הטובה ביותר עם כניסה חלקה, יצירת חשבון וקישור חשבון. השירות חייב לתמוך בנקודות קצה שתואמות ל-OAuth 2.0 להרשאה ולהחלפת אסימונים. בנוסף, נקודת הקצה להחלפת האסימונים חייבת לתמוך בטענות נכוֹנוּת (assertions) של JSON Web Token‏ (JWT) ולהטמיע את הכוונות check,‏ create ו-get.

איך זה עובד:

Google מאמתת את חשבון המשתמש ומעבירה לכם את המידע הבא:

  • אם קיים חשבון של המשתמש במסד הנתונים, המשתמש יצליח לקשר את חשבון Google שלו לחשבון שלו בשירות שלכם.
  • אם אין חשבון של המשתמש במסד הנתונים שלכם, המשתמש יכול ליצור חשבון חדש של צד שלישי באמצעות המידע המאומת ש-Google מספקת : כתובת אימייל, שם ותמונת פרופיל, או להיכנס לחשבון ולקשר אותו לכתובת אימייל אחרת (הוא יצטרך להיכנס לחשבון בשירות שלכם דרך Web OAuth).

איור 3. קישור חשבון בטלפון של המשתמש באמצעות קישור פשוט

באיזה תהליך כדאי להשתמש?

מומלץ להטמיע את כל התהליכים כדי להבטיח שהמשתמשים ייהנו מחוויית הקישור הטובה ביותר. התהליכים 'פשוט יותר' ו'החלפת אפליקציה' מפחיתים את הקשיים בקישור, כי המשתמשים יכולים להשלים את תהליך הקישור בכמה שלבים בודדים. קישור OAuth לאינטרנט הוא האפשרות הכי פשוטה, וזו התחלה טובה. לאחר מכן תוכלו להוסיף את תהליכי הקישור האחרים.

עבודה עם אסימונים

הקישור לחשבון Google מבוסס על תקן התחום OAuth 2.0.

אתם מנפיקים אסימוני גישה ל-Google עבור חשבונות Google נפרדים אחרי שאתם מקבלים את הסכמת בעלי החשבונות לקשר את החשבונות שלהם ולשתף נתונים.

Token types

OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.

Three types of OAuth 2.0 tokens can be used during account linking:

  • Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.

  • Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.

  • Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.

Token handling

Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:

  • You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
  • Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.

Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.

Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:

  • Accept unexpired access tokens, even after a newer token is issued.
  • Use alternatives to Refresh Token Rotation.
  • Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.
Maintenance and outage handling

During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.

Your endpoints should respond with a 503 error code and empty body. In this case, Google retries failed token exchange requests for a limited time. Provided that Google is later able to obtain refresh and access tokens, failed requests are not visible to users.

Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.

Recommendations

There are many solutions to minimize maintenance impact. Some options to consider:

  • Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.

  • Reduce the number of token requests during the maintenance period:

    • Limit maintenance periods to less than the access token lifetime.

    • Temporarily increase the access token lifetime:

      1. Increase token lifetime to greater than maintenance period.
      2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
      3. Enter maintenance.
      4. Respond to token requests with a 503 error code and empty body.
      5. Exit maintenance.
      6. Decrease token lifetime back to normal.

רישום ב-Google

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