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

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

שימו לב: אי אפשר להשתמש בתהליך המשתמע ב-MCP, ב-UCP ובתהליכים שמבוססים על סוכנים. בדרך כלל לא מומלץ להשתמש בו בשילובים חדשים. במקום זאת, צריך להשתמש בהרשאה באמצעות קוד.

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

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

בתהליך קוד ההרשאה, נדרשות שתי נקודות קצה:

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

• נקודת הקצה (endpoint) של החלפת אסימונים, שאחראית על שני סוגים של החלפות:

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

בחירת תהליך OAuth 2.0

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

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

זרם הענקת גישה משתמע קוד הרשאה

הנחיות עיצוב

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

איור 1. קישור החשבון מאפשר למשתמשים להיכנס ל-Google ולמסכי הסכמה.

דרישות

1. אתם צריכים להבהיר למשתמש שהחשבון שלו יקושר ל-Google, ולא למוצר ספציפי של Google כמו Google Home או Google Assistant.

המלצות

מה אתם יכולים לעשות?

1. הצגת מדיניות הפרטיות של Google במסך ההסכמה, צריך לכלול קישור למדיניות הפרטיות של Google.

2. הנתונים שישותפו. השתמשו בשפה ברורה ותמציתית כדי להסביר למשתמשים אילו נתונים שלהם נדרשים ל-Google ולמה.

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

4. אפשרות ביטול. אפשר לספק למשתמשים אפשרות לחזור או לבטל, אם הם בוחרים לא לקשר את החשבון.

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

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

7. אפשרות לשנות את חשבון המשתמש. תציע שיטה למשתמשים להחליף בין החשבונות שלהם. האפשרות הזו שימושית במיוחד אם למשתמשים יש בדרך כלל כמה חשבונות.

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

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

איור 2. הנחיות עיצוב למסכי כניסה של משתמשים ל-Google ולמסכי הסכמה

יצירת הפרויקט

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

כדי ליצור את הפרויקט לשימוש בקישור לחשבון:

1. עוברים אל Google API Console.
2. לוחצים על יצירת פרויקט.
3. מזינים שם או מאשרים את ההצעה שנוצרה.
4. מאשרים או עורכים את השדות שנותרו.
5. לוחצים על יצירה.

כדי לראות את מזהה הפרויקט:

1. עוברים אל Google API Console.
2. מחפשים את הפרויקט בטבלה בדף הנחיתה. מזהה הפרויקט מופיע בעמודה ID.

הגדרה של מסך ההסכמה ל-OAuth

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

1. פותחים את הדף מסך ההסכמה ל-OAuth ב-Google APIs Console.
2. אם מתבקשים, בוחרים את הפרויקט שיצרתם.

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

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

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

   כתובת אימייל לתמיכה: כתובת אימייל שאליה משתמשים יכולים לפנות אם יש להם שאלות לגבי ההסכמה שלהם.

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

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

   קישור לדף הבית של האפליקציה: דף הבית של האפליקציה. הן חייבות להתארח בדומיין מורשה.

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

   קישור לתנאים ולהגבלות של האפליקציה (אופציונלי): הקישור צריך להיות מאוחסן בדומיין מורשה.

   

   איור 1. מסך הסכמה לקישור של חשבון Google לאפליקציה פיקטיבית, Tunery

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

הטמעת שרת OAuth

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

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

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

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

איור 1. רצף האירועים בתהליך הרשאה באמצעות קוד של OAuth 2.0 לקישור של חשבון Google.

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

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

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

סשן של הרשאה באמצעות קוד ב-OAuth 2.0 שהופעל על ידי Google מתנהל באופן הבא:

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

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

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

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

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

1. מוודאים שהערך client_id זהה למזהה הלקוח שהקציתם ל-Google, ושהערך redirect_uri זהה לכתובת ההפניה האוטומטית ש-Google סיפקה לשירות שלכם. הבדיקות האלה חשובות כדי למנוע מתן גישה לאפליקציות לקוח לא מכוונות או לא מוגדרות. אם אתם תומכים בכמה תהליכי OAuth 2.0, צריך גם לוודא שresponse_type הוא code.
2. בודקים אם המשתמש מחובר לשירות שלכם. אם המשתמש לא מחובר, צריך להשלים את תהליך הכניסה או ההרשמה לשירות.
3. יוצרים קוד הרשאה ש-Google יכולה להשתמש בו כדי לגשת ל-API שלכם. קוד ההרשאה יכול להיות כל ערך מחרוזת, אבל הוא חייב לייצג באופן ייחודי את המשתמש, את הלקוח שאליו האסימון משויך ואת זמן התפוגה של הקוד, ואי אפשר לנחש אותו. בדרך כלל מנפיקים קודי הרשאה שתוקפם פג אחרי כ-10 דקות.
4. מוודאים שכתובת ה-URL שצוינה בפרמטר redirect_uri היא מהצורה הבאה:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. הפניית הדפדפן של המשתמש לכתובת ה-URL שצוינה בפרמטר redirect_uri. כשמפנים מחדש, צריך לצרף את הפרמטרים code ו-state, ולכלול את קוד ההרשאה שנוצר ואת ערך המצב המקורי שלא שונה. דוגמה לכתובת ה-URL שמתקבלת:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

טיפול בבקשות להחלפת טוקנים

נקודת הקצה של שירות החלפת הטוקנים אחראית לשני סוגים של החלפות טוקנים:

• המרת קודי הרשאה לאסימוני גישה ולאסימוני רענון
• המרת אסימוני רענון לאסימוני גישה

בקשות להחלפת אסימונים כוללות את הפרמטרים הבאים:

פרמטרים של נקודת קצה להחלפת טוקנים
client_id	מחרוזת שמזהה את מקור הבקשה כ-Google. המחרוזת הזו צריכה להיות רשומה במערכת שלכם כמזהה הייחודי של Google.
client_secret	מחרוזת סודית שרשמתם ב-Google לשירות שלכם.
grant_type	סוג הטוקן שמוחלף. הערך הזה צריך להיות authorization_code או refresh_token.
code	אם הערך הוא grant_type=authorization_code, הפרמטר הזה הוא הקוד ש-Google קיבלה מנקודת הקצה (endpoint) של הכניסה או של החלפת האסימונים.
redirect_uri	אם הערך הוא grant_type=authorization_code, הפרמטר הזה הוא כתובת ה-URL שמשמשת בבקשת ההרשאה הראשונית.
refresh_token	אם הערך הוא grant_type=refresh_token, הפרמטר הזה הוא טוקן הרענון ש-Google קיבלה מנקודת הקצה (endpoint) של החלפת הטוקנים.

המרת קודי הרשאה לאסימוני גישה ולאסימוני רענון

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

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

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

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

1. מוודאים שהפרמטר client_id מזהה את מקור הבקשה כמקור מורשה, ושהערך של הפרמטר client_secret תואם לערך הצפוי.
2. צריך לוודא שקוד ההרשאה תקף ולא פג התוקף שלו, ושמזהה הלקוח שצוין בבקשה זהה למזהה הלקוח שמשויך לקוד ההרשאה.
3. מוודאים שכתובת ה-URL שצוינה בפרמטר redirect_uri זהה לערך שנעשה בו שימוש בבקשת ההרשאה הראשונית.
4. אם אי אפשר לאמת את כל הקריטריונים הקודמים, צריך להחזיר שגיאת HTTP 400 Bad Request עם {"error": "invalid_grant"} כתוכן התגובה.
5. אחרת, משתמשים במזהה המשתמש מקוד ההרשאה כדי ליצור טוקן רענון וטוקן גישה. האסימונים האלה יכולים להיות כל ערך מחרוזת, אבל הם חייבים לייצג באופן ייחודי את המשתמש ואת הלקוח שאליו האסימון משויך, והם לא יכולים להיות ניתנים לניחוש. במקרה של אסימוני גישה, צריך גם לתעד את זמן התפוגה של האסימון, שהוא בדרך כלל שעה אחרי הנפקת האסימון. תוקף אסימוני הרענון לא פג.
6. מחזירים את אובייקט ה-JSON הבא בגוף התגובה של HTTPS:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

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

המרת אסימוני רענון לאסימוני גישה

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

בבקשות האלה, הערך של grant_type הוא refresh_token, והערך של refresh_token הוא הערך של טוקן הרענון שנתתם ל-Google בעבר. דוגמה לבקשה להחלפת טוקן רענון בטוקן גישה:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

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

1. מוודאים שהערך client_id מזהה את מקור הבקשה כ-Google, ושהערך client_secret תואם לערך הצפוי.
2. צריך לוודא שאסימון הרענון תקף, ומזהה הלקוח שצוין בבקשה זהה למזהה הלקוח שמשויך לאסימון הרענון.
3. אם אי אפשר לאמת את כל הקריטריונים הקודמים, צריך להחזיר שגיאת בקשה שגויה (HTTP 400) עם {"error": "invalid_grant"} כתוכן הבקשה.
4. אחרת, משתמשים במזהה המשתמש מאסימון הרענון כדי ליצור אסימון גישה. האסימונים האלה יכולים להיות כל ערך מחרוזת, אבל הם צריכים לייצג באופן ייחודי את המשתמש ואת הלקוח שאליהם האסימון משויך, ואי אפשר לנחש אותם. במקרה של אסימוני גישה, צריך לתעד גם את זמן התפוגה של האסימון, בדרך כלל שעה אחרי הנפקת האסימון.
5. מחזירים את אובייקט ה-JSON הבא בגוף התגובה של HTTPS:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

הערה: אפשר להחזיר refresh_token חדש בתשובה. למידע נוסף על המקרים שבהם עדיף להחזיר refresh_token חדש, אפשר לעיין במאמר עבודה עם אסימונים.

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

• Linked Account Sign-In with Google One Tap.
• Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

userinfo endpoint request headers
Authorization header	The access token of type Bearer.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.

אימות ההטמעה

כדי לאמת את ההטמעה, אפשר להשתמש בכלי 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. מוודאים שמופנים לפלטפורמה שלכם.