סקירה כללית

בחירת מסלול השילוב

בוחרים את הנתיב שהכי מתאים לצרכים שלכם:

נתיב הכי טוב עבור מידע נוסף
Universal Commerce Protocol‏ (UCP) מוֹכרים וקמעונאים. מסמכי UCP
קישור חשבונות רגיל בית חכם, טלוויזיה ו-YouTube. Docs

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

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

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

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

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

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

  • שילוב עם Google שופינג ופלטפורמות שמבוססות על AI (חיפוש Google, ‏ Gemini) באמצעות Universal Commerce Protocol‏ (UCP).

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

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

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

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

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

יכולות ודרישות

בטבלה הבאה מוגדרים התמיכה וההמלצות לכל תהליך קישור.

קישור Flow תכונות רגילות תכונות UCP
App Flip מומלץ מומלץ
קישור יעיל יותר מומלץ מומלץ
קישור OAuth חובה (Fallback) חובה (Fallback)
OAuth 2.1 מומלץ מומלץ

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

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

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

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

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

קישור OAuth

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

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

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

קישור אפליקציות מבוסס-OAuth ('קישור אפליקציות')

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

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

התכונה 'החלפת אפליקציות' נתמכת ב-Android וב-iOS.

איך זה עובד:

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

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

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

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

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

איך זה עובד:

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

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

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

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

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

עבודה עם טוקנים

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

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

סוגי האסימונים

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

אפשר להשתמש בשלושה סוגים של אסימוני OAuth 2.0 במהלך קישור החשבונות:

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

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

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

טיפול בטוקנים

תנאי מירוץ בסביבות מקובצות ובחילופי נתונים בין לקוח לשרת עלולים להוביל לתרחישים מורכבים של תזמון וטיפול בשגיאות כשעובדים עם טוקנים. לדוגמה:

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

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

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

  • לקבל אסימוני גישה שתוקפם לא פג, גם אחרי הנפקת אסימון חדש יותר.
  • אפשר להשתמש בחלופות לRefresh Token Rotation.
  • תמיכה בכמה אסימוני גישה ורענון שתקפים בו-זמנית. מטעמי אבטחה, מומלץ להגביל את מספר האסימונים ואת משך החיים שלהם.
תחזוקה וטיפול בהפסקות שירות

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

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

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

המלצות

יש הרבה פתרונות לצמצום ההשפעה של התחזוקה. כמה אפשרויות שכדאי לבדוק:

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

  • הפחתת מספר הבקשות לטוקנים במהלך תקופת התחזוקה:

    • הגבלת תקופות התחזוקה למשך זמן קצר יותר ממשך החיים של טוקן הגישה.

    • הגדלה זמנית של משך החיים של אסימון הגישה:

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

קישור מתמשך

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

כדי להטמיע קישור מתמשך, משתמשים בגישה של 'חלון נע': מאריכים את תוקף טוקן הרענון הקיים במקום להחליף אותו (בהתאם לסעיף 6 ב-RFC 6749). כך נמנעים מצבי מירוץ וביטול קישור לא מכוון שיכולים להתרחש אם מונפק טוקן רענון חדש אבל Google לא מקבלת או מאחסנת אותו.

הרשמה באמצעות Google

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