חשבונות מקושרים באמצעות תהליך המשתמע וקוד הרשאה רגיל של OAuth 2.0. השירות חייב לתמוך בנקודות קצה (endpoint) מסוג הרשאה ו-Token Exchange התואמות ל-OAuth 2.0.
בתהליך המשתמע, Google פותחת את נקודת הקצה של ההרשאה בדפדפן של המשתמש. לאחר כניסה מוצלחת, מחזירים ל-Google אסימון גישה לטווח ארוך. אסימון הגישה הזה כלול עכשיו בכל בקשה שנשלחה מ-Google.
בתהליך קוד ההרשאה צריך שתי נקודות קצה:
נקודת הקצה הרשאה, שמציגה את ממשק המשתמש לכניסה למשתמשים שלך שאינם מחוברים לחשבון. נקודת הקצה לאישור יוצרת גם קוד הרשאה לטווח קצר כדי לתעד משתמשים' מסכים לגישה המבוקשת.
נקודת הקצה של החלפת אסימונים, שאחראית לשני סוגים של בורסות:
- מתבצעת העברה של קוד הרשאה לאסימון רענון לטווח ארוך ולאסימון גישה לטווח קצר. ההחלפה הזו מתרחשת כשהמשתמש עובר את תהליך קישור החשבון.
- העברה של אסימון רענון לטווח ארוך עבור אסימון גישה לטווח קצר (LTS). ההחלפה הזו מתרחשת כש-Google צריכה אסימון גישה חדש כי תוקפו פג.
בחירת זרימת OAuth 2.0
אומנם קל יותר להטמיע את התהליך המשתמע, אבל Google ממליצה שפג התוקף של אסימוני הגישה שהונפקו על ידי התהליך המשתמע. הסיבה לכך היא שהמשתמש מאלץ קישור מחדש של החשבון שלו לאחר שפג תוקפו של אסימון עם התהליך המשתמע. אם אתם צריכים תפוגה של אסימון מסיבות אבטחה, מומלץ מאוד להשתמש בתהליך קוד ההרשאה במקום זאת.
הנחיות עיצוב
בקטע הזה מתוארות הדרישות וההמלצות בנוגע לעיצוב של מסך המשתמש שאתם מארחים בתהליכי קישור OAuth. אחרי שהאפליקציה נקראת על ידי האפליקציה של Google, היא מציגה למשתמש מסך כניסה לדף Google ולמסך ההסכמה לקישור חשבון. המשתמש מופנה בחזרה לאפליקציה של Google אחרי שהוא נותן את הסכמתו לקשר חשבונות.
דרישות
- עליך להודיע שהחשבון של המשתמש יקושר ל-Google, לא למוצר ספציפי של Google כגון Google Home או Google Assistant.
המלצות
מומלץ לבצע את הפעולות הבאות:
הצגת מדיניות הפרטיות של Google. במסך הקישור יש לציין את מדיניות הפרטיות של Google.
הנתונים לשיתוף. השתמש בשפה ברורה ותמציתית כדי לספר למשתמש אילו נתונים הוא דורש ומדוע.
קריאה ברורה לפעולה. יש לציין במסך קריאה ברורה פעולה, כמו "הסכמה וקישור", כי המשתמשים צריכים להבין אילו נתונים הם נדרשים לשתף עם Google כדי לקשר את החשבונות שלהם.
יכולת לבטל. למשתמשים תהיה אפשרות לחזור אחורה או לבטל את המינוי אם הם יבחרו שלא לקשר.
ניקוי תהליך הכניסה. חשוב לוודא שהמשתמשים מקבלים שיטה ברורה להיכנס לחשבון Google שלהם, כמו השדות של שם המשתמש והסיסמה שלהם, או כניסה באמצעות חשבון Google.
יכולת לבטל את הקישור. צריך להציע למשתמשים מנגנון לביטול הקישור, כמו כתובת URL להגדרות החשבון בפלטפורמה שלהם. לחלופין, אפשר לכלול קישור לחשבון Google, שבו המשתמשים יכולים לנהל את החשבון המקושר שלהם.
היכולת לשנות את חשבון המשתמש. להציע למשתמשים שיטה להחלפת החשבונות שלהם. אפשרות זו שימושית במיוחד אם למשתמשים יש מספר חשבונות.
- אם משתמש צריך לסגור את מסך ההסכמה כדי להחליף חשבון, צריך לשלוח ל-Google הודעת שגיאה ניתנת לשחזור. כך הוא יוכל להיכנס לחשבון הרצוי באמצעות קישור OAuth ותהליך המשתמע.
הלוגו צריך לכלול. הצגת הלוגו של החברה במסך ההסכמה. היעזרו בהנחיות הסגנון כדי למקם את הלוגו. אם ברצונך להציג גם את הלוגו של Google, יש לעיין בלוגו ובסימנים מסחריים.
יצירת הפרויקט
כדי ליצור פרויקט באמצעות קישור חשבונות:
- Go to the Google API Console.
- לחץ על צור פרויקט .
- הזן שם או קבל את ההצעה שנוצרה.
- אשר או ערוך את כל השדות שנותרו.
- לחץ על צור .
לצפייה במזהה הפרוייקט שלך:
- Go to the Google API Console.
- מצא את הפרוייקט שלך בטבלה בדף הנחיתה. מזהה הפרויקט מופיע בעמודה מזהה .
הגדרה של מסך ההסכמה ל-OAuth
תהליך הקישור של חשבון Google כולל מסך הסכמה שמציין למשתמשים את האפליקציה שמבקשת גישה לנתונים שלהם, אילו סוגי נתונים הם מבקשים והתנאים החלים. צריך להגדיר את מסך ההסכמה ל-OAuth לפני שיוצרים מזהה לקוח ב-Google API.
- פותחים את הדף מסך ההסכמה של OAuth במסוף Google APIs.
- אם מתבקשים, בוחרים את הפרויקט שיצרתם.
בדף 'מסך הסכמה של OAuth', ממלאים את הטופס ולוחצים על הלחצן 'שמירה'.
שם האפליקציה: השם של האפליקציה שמבקשת הסכמה. השם צריך לשקף את האפליקציה באופן מדויק ולהיות תואם לשם האפליקציה שהמשתמשים רואים במקומות אחרים. שם האפליקציה יוצג במסך ההסכמה לקישור חשבונות.
הלוגו של האפליקציה: תמונה במסך ההסכמה שתעזור למשתמשים לזהות את האפליקציה. הלוגו מוצג במסך ההסכמה לקישור חשבון ובהגדרות החשבון
כתובת אימייל לתמיכה: מאפשר למשתמשים ליצור איתכם קשר אם יש להם שאלות לגבי ההסכמה שלהם.
היקפים עבור Google APIs: היקפי הרשאות מאפשרים לאפליקציה לגשת לנתוני Google הפרטיים של המשתמשים. בתרחיש לדוגמה של 'קישור חשבון Google', היקף ברירת המחדל (אימייל, פרופיל, מזהה פתוח) מספיק. אין צורך להוסיף היקפים רגישים. בדרך כלל מומלץ לבקש היקפים באופן מצטבר, בזמן שנדרשת גישה, ולא מראש. מידע נוסף
דומיינים מורשים: כדי להגן עליכם ועל המשתמשים שלכם, Google מאפשרת רק לאפליקציות שמבצעות אימות באמצעות OAuth להשתמש בדומיינים מורשים. הקישורים לאפליקציות שלכם חייבים להתארח ב'דומיינים מורשים'. מידע נוסף
קישור לדף הבית של האפליקציה: דף הבית של האפליקציה. חייב להתארח בדומיין מורשה.
קישור למדיניות הפרטיות של האפליקציה: מוצג במסך ההסכמה לקישור חשבון Google. חייב להתארח בדומיין מורשה.
קישור לתנאים ולהגבלות של האפליקציה (אופציונלי): חייב להתארח בדומיין מורשה.
איור 1. מסך הסכמה לקישור חשבון Google לאפליקציה פיקטיבית, Tunery
מסמנים את 'סטטוס אימות'. אם צריך לאמת את הבקשה, לוחצים על הלחצן 'שליחה לאימות' כדי לשלוח את הבקשה לאימות. לפרטים, יש לעיין בדרישות לאימות OAuth.
הטמעה של שרת ה-OAuth
כדי לתמוך בזרימת מרומזת 2.0 OAuth, השירות שלך עושה נקודה סיום אישור זמין ידי HTTPS. נקודת קצה זו אחראית לאימות וקבלת הסכמה מהמשתמשים לגישה לנתונים. נקודת הקצה של ההרשאה מציגה ממשק משתמש כניסה למשתמשים שלך שעדיין לא התחברו ורושמת הסכמה לגישה המבוקשת.
כאשר יישום Google צריך להתקשר לאחד מממשקי ה-API המורשים של השירות שלך, Google משתמשת בנקודת קצה זו כדי לקבל הרשאה מהמשתמשים שלך להתקשר לממשקי ה-API הללו בשמם.
הפעלת זרימה מרומזת טיפוסית של OAuth 2.0 שיזמה Google כוללת את הזרימה הבאה:
- Google פותחת את נקודת קצה ההרשאה שלך בדפדפן של המשתמש. המשתמש נכנס, אם עדיין לא נכנס, ומעניק ל-Google הרשאה לגשת לנתונים שלו באמצעות ה-API שלך, אם הוא עדיין לא העניק הרשאה.
- השירות שלך יוצר גישת אסימון וחוזר אותו ל- Google. לשם כך, הפנה את הדפדפן של המשתמש בחזרה לגוגל עם אסימון הגישה המצורף לבקשה.
- Google מתקשרת לממשקי ה-API של השירות שלך ומצרפת את אסימון הגישה לכל בקשה. השירות שלך מאמת שאסימון הגישה מעניק ל-Google הרשאה לגשת ל-API ולאחר מכן משלים את קריאת ה-API.
טיפול בבקשות הרשאה
כאשר אפליקציה של Google צריכה לבצע קישור חשבון באמצעות זרימה מרומזת של OAuth 2.0, Google שולחת את המשתמש לנקודת הקצה של ההרשאה שלך עם בקשה הכוללת את הפרמטרים הבאים:
| פרמטרים של נקודת קצה של הרשאה | |
|---|---|
client_id | מזהה הלקוח שהקצית ל-Google. |
redirect_uri | כתובת האתר שאליה אתה שולח את התגובה לבקשה זו. |
state | ערך הנהלת חשבונות המועבר בחזרה ל-Google ללא שינוי ב-URI להפניה מחדש. |
response_type | סוג הערך להחזיר בתגובה. עבור זרימת מרומזת 2.0 OAuth, את סוג התגובה היא תמיד 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
כדי שנקודת הקצה של ההרשאה שלך יטפל בבקשות כניסה, בצע את הצעדים הבאים:
בדוק את
client_idוredirect_uriערכים כדי למנוע להעניק גישה לאפליקציות לקוח מכוונת או שאינו מוגדר כראוי:- מאשרים כי
client_idתואם את זיהוי הלקוח שהקצית Google. - אשר שכתובת האתר שצוין על ידי
redirect_uriפרמטר יש את הטופס הבא:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- מאשרים כי
בדוק אם המשתמש מחובר לשירות שלך. אם המשתמש אינו מחובר, השלם את תהליך הכניסה או ההרשמה של השירות שלך.
צור אסימון גישה ש-Google תשתמש בו כדי לגשת ל-API שלך. אסימון הגישה יכול להיות כל ערך מחרוזת, אך עליו לייצג באופן ייחודי את המשתמש והלקוח שהאסימון מיועד עבורו ואסור שיהיה ניתן לניחוש.
שלח תגובת HTTP, אשר מפנה את הדפדפן של המשתמש לכתובת שצוינה על ידי
redirect_uriפרמטר. כלול את כל הפרמטרים הבאים בקטע כתובת האתר:-
access_token: אסימון הגישה אתה פשוט שנוצר -
token_type: המחרוזתbearer -
state: ערך המדינה ללא שינוי מן הבקשה המקורית
להלן דוגמא של האתר שמתקבל:
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
-
מטפל OAuth 2.0 ההפניה של גוגל מקבל אסימון הגישה ומאשר כי state הערך לא השתנה. לאחר ש-Google השיגה אסימון גישה לשירות שלך, Google מצרף את האסימון לקריאות עוקבות לממשקי ה-API של השירות שלך.
处理用户信息请求
该用户信息终端是一个OAuth 2.0保护的资源，对链接的用户返回的权利要求。实现和托管 userinfo 端点是可选的，以下用例除外：
从您的令牌端点成功检索访问令牌后，Google 会向您的 userinfo 端点发送请求，以检索有关链接用户的基本个人资料信息。
| userinfo 端点请求标头 | |
|---|---|
Authorization header | Bearer 类型的访问令牌。 |
例如，如果你的用户信息终端可在https://myservice.example.com/userinfo ，请求看起来像下面这样：
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
要让您的 userinfo 端点处理请求，请执行以下步骤：
- 从 Authorization 标头中提取访问令牌并返回与访问令牌关联的用户的信息。
- 如果访问令牌无效，返回HTTP 401错误未经授权使用的
WWW-Authenticate响应头。下面是一个userinfo的错误响应的一个示例：HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
如果一个401未经授权，或任何其它不成功错误响应在关联过程返回时，误差将是不可恢复的，所检索的令牌将被丢弃，并且用户将必须再次启动链接过程。 如果访问令牌是有效的，回国与以下JSON对象在HTTPS响应的身体HTTP 200回应：
{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }如果你的用户信息端点返回一个HTTP 200成功响应，检索到的令牌和索赔登记针对用户的谷歌帐户。用户信息端点响应 sub标识系统中用户的唯一 ID。 email用户的电子邮件地址。 given_name可选：用户的名字。 family_name可选：用户的姓氏。 name可选：用户的全名。 picture可选：用户的档案图片。
אימות ההטמעה
אתה יכול לאמת את הביצוע שלך באמצעות מגרש 2.0 OAuth הכלי.
בצע את הפעולות הבאות בכלי:
- לחץ תצורת כדי לפתוח את חלון תצורת 2.0 OAuth.
- בתחום זרימת OAuth, בחר בצד הלקוח.
- בתחום נקודות קצה OAuth, בחר Custom.
- ציין את נקודת הקצה של OAuth 2.0 ואת מזהה הלקוח שהקצית ל- Google בשדות המתאימים.
- במקטע שלב 1, לא יבחר אף היקפי Google. במקום זאת, השאר שדה זה ריק או הקלד טווח תקף עבור השרת שלך (או מחרוזת שרירותית אם אינך משתמש בהיקפי OAuth). כשתסיים, לחץ על הרשה APIs.
- בסעיפים שלב 2 ושלב 3, לעבור את זרימת 2.0 OAuth ולוודא כי כל צעד עובד כמתוכנן.
אתה יכול לאמת את הביצוע שלך באמצעות קישור הדגמת חשבון Google הכלי.
בצע את הפעולות הבאות בכלי:
- לחץ על כניסה עם כפתור גוגל.
- בחר את החשבון שברצונך לקשר.
- הזן את מזהה השירות.
- לחלופין, הזן אחד או יותר טווחים שאליהם תבקש גישה.
- לחץ על התחל הדגמה.
- כשתתבקש, אשר שאתה רשאי להסכים ולדחות את בקשת הקישור.
- אשר שהפנית לפלטפורמה שלך.