מדריך לקונספט של קישור לכניסה באמצעות חשבון OAuth "תהליך יעיל"

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

יצירת קישור יעילה היא הפתרון המומלץ לקישור חשבונות, אם אחד התנאים הבאים חלים עליהן:

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

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

מונחי מפתח

לפני שתקראו על האופן שבו פועלים הקישורים ביעילות, כדאי להכיר אותם. בתנאים הבאים:

• אסימון מזהה של Google: טענת נכוֹנוּת (assertion) חתומה של זהות המשתמש שמכילה פרטים בסיסיים בפרופיל של המשתמש (השם, כתובת האימייל והכתובת שלו תמונת פרופיל). אסימון מזהה של Google הוא אסימון אינטרנט מסוג JSON (JWT). זאת דוגמה לאסימון מפוענח:

{
  "sub": 1234567890,        // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The token's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Client ID assigned to your Actions project
  "iat": 233366400,         // Unix timestamp of the token's creation time
  "exp": 233370000,         // Unix timestamp of the token's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "[e-mail]", // If present, the user's email address
  "locale": "en_US"
}

• user.verificationStatus: מאפיין שהמערכת מגדירה כדי לציין אם בסשן הנוכחי יש משתמש מאומת.

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

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

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

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

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

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

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

דרישות מוקדמות

כדי להשתמש בסוג הקישור יעיל יותר, צריך:

• שרת OAuth 2.0

• נקודת קצה להחלפת אסימונים

  צריך להרחיב את נקודת הקצה (endpoint) של המרת האסימון כדי להוסיף תמיכה פרוטוקולים לקישור אוטומטי וליצירת חשבון מאסימון מזהה (כלומר, להוסיף את הפרמטרים intent=get ו-intent=create בבקשות אל בנקודת הקצה הזו).

איך זה עובד

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

התהליך היסודי הוא:

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

תהליכי קישור יעילים יותר

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

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

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

בתהליך שלמעלה, עוברים לסצנת המערכת של קישור החשבונות ומספקים נימוק מותאם אישית. הסצנה מבקשת מהמשתמש/ת הרשאת גישה את הפרטים שלהם מפרופיל Google. אחרי שהמשתמש מביע הסכמה, Assistant שולחת בקשה שמכילה את פרטי הפרופיל של [e-mail].

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

תהליכים עם יצירת חשבון קולי מופעלת

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

הערה: התרשימים הבאים מבוססים על תרשים השלבים הנפוצים שלמעלה.

תהליך 1: פרטי המשתמש קיימים במערכת שלכם

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

במקרה הזה, המשתמש שמיוצג על ידי [e-mail] קיים בקצה העורפי, כך שנקודת הקצה של המרת אסימון תחזיר אסימון למשתמש. השם של המשתמש הזהות בפעולה שלכם מקושרת עכשיו לחשבון Google שלו. השם של המשתמש הבקשה המקורית ("Order myההגדרות") תואמת לכוונת המשתמש order_drink. לאחר מכן, התגובה לפעולה מאתר אחר (webhook) מטפלת במימוש של הכוונה התואמת והשאילתות מסד נתונים לסדר הרגיל של [e-mail]. לאחר מכן המשתמש יכול להמשיך שיחה עם Assistant.

תהליך 2: פרטי המשתמש לא קיימים והמשתמש יוצר חשבון

בגלל שהפעלת את יצירת החשבונות באמצעות הקול, ו[e-mail] לא מאפשר זאת קיימות בקצה העורפי, Assistant שואלת את המשתמש אם הוא רוצה לעשות אחד מהתנאים הבאים:

א) ליצור חשבון חדש במערכת באמצעות פרטי הפרופיל שלו ב-Google, באמצעות הקול

ב) כניסה למערכת באמצעות חשבון אחר

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

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

אחרי יצירת החשבון, השירות מחזיר אסימון גישה ומרענן את החשבון של החשבון החדש שנוצר. זהות המשתמש בפעולה היא עכשיו שמקושר לחשבון Google. הבקשה המקורית של המשתמש ("הזמנה רגילה") תואם לכוונת המשתמש order_drink. ה-webhook שלך מטפל מילוי של הכוונה התואמת ושאילתות למסד הנתונים שלך ההזמנה הרגילה של [e-mail], שעדיין לא קיימת כי המשתמש חדש. הפעולה יכולה לשאול את המשתמש מה הוא רוצה להזמין.

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

תהליך 3: פרטי המשתמש לא קיימים והמשתמש נכנס באמצעות חשבון אחר

הפעלת את יצירת החשבון באמצעות הקול, לכן Assistant שואלת את המשתמש אם הוא רוצה לבצע אחת מהפעולות הבאות:

א) ליצור חשבון חדש במערכת באמצעות פרטי הפרופיל שלו ב-Google, באמצעות הקול

ב) כניסה למערכת באמצעות חשבון אחר

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

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

אחרי אימות פרטי הכניסה של המשתמש, השירות מחזיר אסימון גישה. ואסימון רענון ל-Google. זהות המשתמש בפעולה מקושרת עכשיו לחשבון שהוא לא של Google. הבקשה המקורית של המשתמש ("Order my active") תואמת כוונת המשתמש order_drink. לאחר מכן התגובה לפעולה מאתר אחר (webhook) תטפל את הכוונה שנמצאה לה התאמה ושאילתות למסד הנתונים שלך לגבי הסדר הרגיל של [e-mail], שעדיין לא קיים כי המשתמש חדש. הפעולה יכולה לבקש את לחפש את מה שהוא רוצה להזמין או לבקש ממנו להגדיר את ההזמנה הרגילה שלו.

האפשרות ליצור חשבון ב-Voice מושבתת

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

הערה: התרשימים הבאים מבוססים על תרשים השלבים הנפוצים שלמעלה.

תהליך 4: פרטי המשתמש לא קיימים

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

אחרי אימות פרטי הכניסה של המשתמש, השירות מחזיר אסימון גישה. ואסימון רענון ל-Google. זהות המשתמש בפעולה מקושרת עכשיו לחשבון שהוא לא של Google. הבקשה המקורית של המשתמש ("הזמנה רגילה") תואמת כוונת המשתמש order_drink. לאחר מכן התגובה לפעולה מאתר אחר (webhook) תטפל את הכוונה שנמצאה לה התאמה ושאילתות למסד הנתונים שלך לגבי הסדר הרגיל של [e-mail], שעדיין לא קיים כי המשתמש חדש. הפעולה יכולה לבקש את משתמש יכול להגדיר את ההזמנה הרגילה שלו.