בחירת סוג הקישור של החשבונות (Dialogflow)

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

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

כדי לברר מהו סוג הקישור האידיאלי לחשבון, פועלים לפי השלבים הבאים:

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

זיהוי סוג הכניסה המועדף עליך

לפני שתפנו לעץ ההחלטות, כדאי שתביאו בחשבון את השאלות הבאות:

• האם אתה מצפה שלכל המשתמשים שלך יהיה חשבון Google?
  • אם הפעולה מטרגטת רק את Assistant, סביר להניח שלכל המשתמשים יהיה חשבון Google. אם הפעולה מטרגטת פלטפורמות נוספות מלבד Assistant, לא ניתן לצפות שלכל המשתמשים יהיה חשבון Google.
  • אם כבר יש משתמשים בשירות שלכם, סביר להניח שלחלק מהם אין חשבון Google או שלא נכנסו לשירות שלכם באמצעות חשבון Google.
• אם יש לך הטמעה של OAuth, האם אפשר להרחיב אותה כדי לתמוך בפרוטוקול של Google?
  • כדי לתמוך בפרוטוקול של Google, צריכה להיות לכם אפשרות להוסיף את הפונקציונליות intent=get ו-intent=create לנקודת הקצה של המרת האסימונים. הפונקציונליות הזו מאפשרת ל-Google לבדוק אם המשתמש כבר קיים בקצה העורפי שלכם, ולבקש ממנו ליצור חשבון חדש בשירות שלכם.

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

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

OAuth וכניסה באמצעות חשבון Google

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

שיפור של סוג הקישור ל-OAuth ולכניסה באמצעות חשבון Google

אם משתמשים בסוג הקישור בין חשבון OAuth ל-GSI ב-Action, צריך לציין את התשובות לשאלות הבאות במסוף Actions כדי להגדיר את אופן הפעולה:

1. האם אתם רוצים לאפשר יצירת חשבון קולי או לאפשר רק יצירת חשבון באתר שלכם?

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

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

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

2. האם ברצונך להשתמש בתהליך קוד ההרשאה או בתהליך המשתמע?

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

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

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

אחרי שתבדקו את נקודות ההחלטות האלה, עיינו בעץ ההחלטות הבא:

כניסה באמצעות חשבון Google

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

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

OAuth

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

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

שיפור התהליך

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

1. האם ברצונך להשתמש בתהליך קוד ההרשאה או בתהליך המשתמע?

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

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

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