בחירת סוג הקישור לחשבון

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

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

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

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

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

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

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

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

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

קישור 'מייעל' לכניסה באמצעות OAuth

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

שיפור סוג הקישור 'יעיל' לכניסה באמצעות OAuth שמבוסס על OAuth

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

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

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

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

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

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

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

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

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

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

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

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

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

קישור OAuth

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

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

שיפור התהליך

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

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

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

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

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