סקירה כללית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• משפרים את האבטחה באמצעות תהליך קוד ההרשאה של קישור OAuth.

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

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

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

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

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

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

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

קישור OAuth ('פרוטוקול 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, באמצעות תהליך קוד ההרשאה.

App Flip נתמך גם ל-Android וגם ל-iOS.

איך זה עובד:

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

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

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

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

קישור עם כניסה באמצעות חשבון Google שמבוסס על OAuth מוסיף את 'כניסה באמצעות חשבון Google' בנוסף לקישור OAuth, וכך המשתמשים יכולים להשלים את תהליך הקישור בלי לצאת מהפלטפורמה של Google. כך יש פחות נקודות חיכוכים והנטישות. קישור יעיל שמבוסס על OAuth מציע את חוויית המשתמש הטובה ביותר עם כניסה חלקה, יצירת חשבונות וקישור חשבונות, על ידי שילוב של כניסה באמצעות חשבון Google עם קישור OAuth. השירות שלכם חייב לתמוך בנקודות קצה (endpoint) של החלפת אסימונים והרשאות שעומדות בדרישות של OAuth 2.0. בנוסף, נקודת הקצה של המרת האסימונים צריכה לתמוך בטענות נכונות של 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 ולשיתוף פרטי הכניסה. פרטים נוספים זמינים במאמר רישום.