אם חדשים או לא מוכרים לך השירותים או ההרשאות של Google Identity, כדאי לקרוא תחילה את הסקירה הכללית.
Google מציעה ספריית JavaScript עם תכונות הרשאה שעוזרות לנהל היקפים, לקבל את הסכמת המשתמשים ולעבוד בקלות רבה יותר בתהליך OAuth 2.0 רגיל. אפליקציית האינטרנט שלך, שפועלת בדפדפן המשתמש, משתמשת בספרייה זו כדי לנהל את התהליך המשתמע של OAuth 2.0, או כדי להתחיל את תהליך קוד ההרשאה המסתיים בפלטפורמת הקצה העורפי.
היקפי אימות בלבד
יש מספר היקפים המשמשים לאימות משתמשים בלבד: email, profile וopenid. אם האפליקציה שלך משתמשת בהיקף הזה בלבד, יש לשקול אם אסימון JWT ID וכניסה באמצעות חשבון Google להרשמה של משתמשים, והכניסה לחשבון עונה על הצרכים שלך. ברוב המקרים, זו השיטה הפשוטה והפשוטה ביותר
שזמינה לאימות המשתמשים.
מונחים ומושגים מרכזיים
מדריכים אלה מניחים שיש לכם הבנה בסיסית במושגים של OAuth 2.0 וסטנדרטים של IETF כמו RFC6749. אנחנו משתמשים במונחים הבאים במדריכי הרשאות:
- אסימון גישה הוא אישור כניסה לטווח קצר לכל משתמש ש-Google הנפיקה. הוא משמש לקריאה מאובטחת ל-Google APIs ולגישה לנתוני משתמשים.
- קוד הרשאה הוא קוד זמני ש-Google מנפיקה כדי לזהות באופן מאובטח משתמשים פרטיים שנכנסים לחשבון Google שלהם מדפדפן. פלטפורמת הקצה העורפי מחליפה את הקוד הזה לגישה ולרענון.
- רענון אסימון הוא אישור כניסה ותיק לכל משתמש ש-Google מנפיקה באופן מאובטח וניתן להשתמש בו כדי לקבל אסימון גישה חדש וחוקי, גם אם המשתמש לא נמצא.
- היקף מגביל את האסימונים לסכום מוגדר ומוגבל של נתוני משתמש. מידע נוסף זמין בקטע היקפי OAuth 2.0 ל-Google APIs.
- מצב חלון קופץ הוא זרימת קוד הרשאה המבוסס על קריאה חוזרת (callback) של JavaScript שפועלת בדפדפן המשתמש. Google מפעילה את ה-callback שלכם, האחראי על שליחת קוד האימות לפלטפורמה שלכם, וההחלטה הזו תלויה בכם.
- מצב הפניה אוטומטית הוא זרימת קוד הרשאה המבוסס על הפניות HTTP. הסוכן המשתמש מופנה תחילה ל-Google, הפניה שנייה מ-Google לנקודת הקצה של קוד ההרשאה בפלטפורמה שלכם.
משך החיים של האסימון מוגדר כמנפיק של Google. בשל גורמים שונים, משך הזמן המדויק עשוי להשתנות.
תהליכי OAuth 2.0
שני תהליכי עבודה, קוד מרומז וקוד הרשאה מתקיימים בדיון. שניהם מחזירים אסימון גישה שמתאים לשימוש ב-Google APIs.
התהליך של קוד ההרשאה מומלץ כי הוא מספק אבטחת משתמש משופרת. התהליך הזה מחזיר גם אסימון רענון שיכול לשמש כדי לקבל אסימוני גישה בלי שהמשתמש נמצא, כך שהפלטפורמה שלך יכולה לבצע בקלות רבה יותר פעולות אסינכרוניות, כמו שליחת תזכורת ב-SMS לפגישה קרובה שתוזמנה ברגע האחרון. בחירת מודל הרשאה הסבר מפורט על ההבדלים בין שני התהליכים.
ספריית JavaScript של Google Identity Services עומדת בתקן OAuth 2.0 כדי:
- נהל את התהליך המשתמע כדי לאפשר לאפליקציית האינטרנט של הדפדפן לקבל במהירות ובקלות אסימון גישה מ-Google, הנדרש כדי להפעיל ממשקי API של Google.
- מתחילים בתהליך קוד ההרשאה בדפדפן של המשתמש.
שלבים נפוצים
הזרימה המשתמעת וקוד ההרשאה מתחילים באותו אופן:
- האפליקציה שלך מבקשת גישה להיקף אחד או יותר.
- Google מציגה למשתמש תיבת דו-שיח להבעת הסכמה, ואם יש צורך, מעבירה אותו לחשבון Google שלו.
- המשתמש מאשר כל היקף בנפרד.
לאחר מכן, כל רצף מסתיים בשלבים שונים.
כשמשתמשים בתהליך המשתמע
- Google משתמשת ב-handler של קריאה חוזרת (callback) כדי להודיע לאפליקציה על תוצאת ההסכמה ולהחזיר אסימון גישה להיקפים שאושרו.
כשמשתמשים בתהליך של קוד האימות
- Google מגיבה באמצעות קוד הרשאה למשתמש:
- במצב הפניה אוטומטית, הקוד מוחזר לנקודת הקצה של קוד ההרשאה שלך.
- במצב חלון קופץ, הקוד מוחזר למטפל החוזר של האפליקציה בדפדפן, בלי שהמשתמשים יצטרכו לצאת מהאתר.
- החל שלב 4: טיפול בתגובת שרת OAuth 2.0 פלטפורמת הקצה העורפי משלים החלפה בין שרת לשרת ב-Google, ובסופו של דבר חוזר אסימון האסימון לכל משתמש ואסימון גישה לפלטפורמה שלך.
הסכמת משתמשים
לפני השגת אסימון גישה, משתמשים ספציפיים חייבים לתת את הסכמת המשתמשים לאפליקציה שלך כדי לגשת להיקפי ההרשאות הנדרשים. לשם כך, Google מציגה תיבת דו-שיח להבעת הסכמה במהלך שלב 2 שלמעלה, ומתעדת את התוצאה בכתובת myaccount.google.com/permissions.
השם, הלוגו, מדיניות הפרטיות, התנאים וההגבלות וההיקפים המבוקשים של האפליקציה שלך מוצגים למשתמש יחד עם האפשרות לאשר או לבטל את הבקשה.
באיור 1 מוצגת תיבת הדו-שיח להבעת הסכמה להיקף יחיד. כשמוצגת בקשה להיקף אחד, אין צורך לסמן תיבות סימון כדי לאשר או לדחות היקף מסוים.
איור 1: תיבת דו-שיח בנושא הסכמת משתמשים עם היקף יחיד.
באיור 2 מוצגת תיבת הדו-שיח להבעת הסכמה לכמה היקפים. כאשר יש יותר מהיקף אחד שנדרש תיבות סימון בודדות, כדי לאפשר למשתמש לאשר או לדחות כל היקף.
איור 2: תיבת דו-שיח להבעת הסכמה של משתמשים עם מספר היקפים.
חשבונות משתמש
יש צורך בחשבון Google כדי לתעד הסכמה ולהנפיק אסימון גישה. לפני כן, משתמשים בודדים היו צריכים לאמת את עצמם ב-Google על ידי כניסה לחשבון Google.
אמנם זו לא דרישה, אבל מומלץ להשתמש ב'כניסה באמצעות חשבון Google' כדי להירשם ולהיכנס לאפליקציית האינטרנט או לפלטפורמת הקצה העורפי. כך תוכלו לצמצם את רמת החיכוך של המשתמש על ידי צמצום מספר השלבים הנדרשים ומאפשרים לשייך בקלות אסימוני גישה לחשבונות נפרדים בפלטפורמה.
לדוגמה, כשמשתמשים ב'כניסה באמצעות חשבון Google', נוצרת סשן פעיל של חשבון Google, ולכן אין צורך לבקש מהמשתמש להיכנס לחשבון Google בעת בקשת הרשאה. אם בחרת לאמת את המשתמשים באפליקציה באמצעים אחרים, כמו שם משתמש וסיסמה או עם ספקי זהות אחרים, הם עדיין יידרשו להיכנס לחשבון Google ולקבל את הסכמתם.
הוספת רמז במהלך אתחול ההרשאה – בדרך כלל כתובת האימייל של חשבון Google של המשתמש – מאפשרת ל-Google לדלג על התצוגה של בוחר חשבון וחוסכת למשתמשים שלב. פרטי הכניסה למזהה האסימון שהוחזרו על ידי 'כניסה באמצעות' Google כוללים את כתובת האימייל של המשתמש.
אפליקציות אינטרנט שפועלות רק בדפדפן עשויות להסתמך רק על Google לצורך אימות משתמשים, ולבחור לא ליישם מערכת לניהול חשבון משתמש. בתרחיש הזה, שנקרא תהליך מרומז, אין צורך לשייך אסימון רענון לחשבון משתמש ולניהול אחסון מאובטח.
לחלופין, יש צורך במערכת חשבון משתמש בתהליך קוד ההרשאה. אסימוני הרענון של כל משתמש חייבים להיות משויכים לחשבון בודד בפלטפורמת הקצה העורפי, והם מאוחסנים לשימוש מאוחר יותר. איך להטמיע, לעבוד עם מערכת ולנהל אותה, היא ייחודית לפלטפורמה שלך ולא מתוארת בה פרטים נוספים.
הצגה וביטול של הסכמה
המשתמשים יכולים להציג או לבטל את הסכמתם בכל שלב בהגדרות חשבון Google שלהם.
לחלופין, אפליקציית האינטרנט או הפלטפורמה יכולות להתקשר אל
google.accounts.oauth2.revoke
כדי לבטל את האסימונים ולהסיר את הסכמת המשתמשים, שמועילה כאשר המשתמש מוחק
את החשבון שלו מהפלטפורמה.
אפשרויות הרשאה אחרות
לחלופין, דפדפנים יכולים לקבל אסימוני גישה באמצעות התהליך המשתמע, על ידי קריאה ישירה של נקודות הקצה של OAuth 2.0 של Google כפי שמתואר ב-OAuth 2.0 לאפליקציות אינטרנט בצד הלקוח.
באופן דומה, בתהליך קוד ההרשאה, אפשר ליישם שיטות משלך, ולפעול לפי השלבים בקטע שימוש ב-OAuth 2.0 לאפליקציות אינטרנט.
בשני המקרים, מומלץ מאוד להשתמש בספרייה של Google Identity Services כדי לקצר את זמן הפיתוח והמאמצים שלך ולצמצם את סיכוני האבטחה כמו אלו המתוארים בשיטות המומלצות הנוכחיות לאבטחת OAuth 2.0.