אם לא השתמשתם בהרשאה או ב-Google Identity Services בפעם הראשונה, תחילה כדאי לקרוא את הסקירה הכללית.
Google מציעה ספריית JavaScript שכוללת תכונות הרשאה, כדי לעזור לכם לנהל היקפים, לקבל הסכמה מהמשתמשים ולעבוד בקלות רבה יותר עם תהליכי OAuth 2.0 סטנדרטיים. אפליקציית האינטרנט שלכם, שפועלת בדפדפן של המשתמש, משתמשת בספרייה הזו כדי לנהל את התהליך המשתמע של OAuth 2.0 או כדי להתחיל את תהליך קוד ההרשאה שמסתיים בפלטפורמת הקצה העורפי.
היקפים לאימות בלבד
יש כמה היקפי הרשאות שמשמשים רק לאימות משתמשים: email, profile ו-openid. אם באפליקציה שלכם נעשה שימוש רק בהיקפים האלה, כדאי לבדוק אם אסימון מזהה של JWT וכניסה באמצעות חשבון Google להרשמה ולכניסה של משתמשים עונים על הצרכים שלכם. ברוב המקרים, זו השיטה הפשוטה והפשוטה ביותר לאימות על ידי משתמשים.
מונחי מפתח ומושגים
המדריכים האלה מבוססים על ההנחה שיש לכם הבנה בסיסית במושגים של OAuth 2.0 ובתקנים של IETF, כמו RFC6749. המונחים הבאים מופיעים במדריכים בנושא הרשאות:
- אסימון גישה הוא אסימון לטווח קצר ש-Google מנפיקה לכל פרטי כניסה של משתמש, ומשמש לקריאה מאובטחת ל-Google APIs ולגישה לנתוני משתמשים.
- Authorization code היא קוד זמני ש-Google מנפיקה כדי לזהות באופן מאובטח משתמשים שנכנסים לחשבון Google שלהם מדפדפן. הקוד הזה ממיר את הקוד לאסימוני גישה ורענון באמצעות פלטפורמת הקצה העורפי.
- אסימון רענון הוא אסימון ארוך טווח לכל משתמש. פרטי הכניסה ש-Google מנפיקה הם פרטי כניסה של משתמשים ששמורים באופן מאובטח בפלטפורמה שלכם. אפשר להשתמש בו כדי לקבל אסימון גישה חדש ותקף, גם אם המשתמש לא נוכח.
- ההיקף מגביל את האסימונים למספר מוגדר ומוגבל של נתוני משתמשים. מידע נוסף זמין במאמר היקפים של OAuth 2.0 ל-Google APIs.
- מצב חלון קופץ הוא תהליך של קוד הרשאה שמבוסס על קריאה חוזרת (callback) של JavaScript שפועל בדפדפן של המשתמש. Google מפעילה את ה-handler של הקריאה החוזרת (callback) שאחראי לשליחת קוד ההרשאה לפלטפורמה שלכם. אתם בוחרים איך לעשות זאת.
- מצב הפניה אוטומטית הוא תהליך של קוד הרשאה המבוסס על הפניות אוטומטיות מסוג HTTP. הסוכן המשתמש מופנה תחילה אל Google, וההפניה השנייה מ-Google לנקודת הקצה (endpoint) של קוד ההרשאה של הפלטפורמה כוללת את הקוד.
משך החיים של האסימון מוגדר על ידי Google בתור המנפיק. בגלל גורמים שונים, משך הזמן המדויק עשוי להשתנות.
תהליכי OAuth 2.0
נדון בשני זרימות, קוד משתמע וקוד הרשאה. שתיהן מחזירות אסימון גישה שמתאים לשימוש עם Google APIs.
מומלץ להשתמש בתהליך של קוד ההרשאה כי הוא מספק למשתמשים אבטחה משופרת. התהליך הזה מחזיר גם אסימון רענון שיכול לשמש לקבלת אסימוני גישה ללא נוכחות המשתמש, וכך הפלטפורמה יכולה לבצע בקלות פעולות אסינכרוניות כמו שליחת תזכורת ב-SMS לפגישה שתוזמנה בדקה ה-90. במאמר בחירה של מודל הרשאה מוסבר בפירוט על ההבדלים בין שני התהליכים.
ספריית ה-JavaScript של Google Identity Services פועלת לפי תקן OAuth 2.0 כדי:
- לנהל את התהליך המשתמע כדי לאפשר לאפליקציית האינטרנט בדפדפן לקבל במהירות ובקלות מ-Google אסימון גישה שנדרש כדי לקרוא ל-Google APIs.
- להתחיל את תהליך קוד ההרשאה מהדפדפן של המשתמש.
שלבים נפוצים
התהליך של קוד ההרשאה והקוד המשתמע מתחיל באותו אופן:
- האפליקציה שלך מבקשת גישה להיקף הרשאות אחד או יותר.
- Google מציגה למשתמש תיבת דו-שיח להבעת הסכמה, ובמידת הצורך תכניס אותו תחילה לחשבון Google שלו.
- המשתמש מאשר בנפרד כל אחד מההיקפים המבוקשים.
כל תהליך מסתיים בשלבים שונים.
כשמשתמשים בזרימה משתמעת
- Google משתמשת ב-handler של קריאה חוזרת (callback) כדי לעדכן את האפליקציה לגבי תוצאת ההסכמה ולהחזיר אסימון גישה לכל ההיקפים שאושרו.
כשמשתמשים בתהליך קוד ההרשאה
- Google מגיבה עם קוד הרשאה לכל משתמש:
- במצב הפניה אוטומטית, הקוד מוחזר לנקודת הקצה של קוד ההרשאה של הפלטפורמה.
- במצב חלון קופץ, הקוד מוחזר לגורם ה-handler של הקריאה החוזרת (callback) באפליקציה שבדפדפן, בלי שהמשתמשים יצטרכו לצאת מהאתר.
- החל משלב 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 לדלג על התצוגה של Account Chooser ולחסוך למשתמשים שלב. פרטי הכניסה לאסימון המזהה שהוחזרו על ידי התכונה 'כניסה באמצעות חשבון Google' מכילים את כתובת האימייל של המשתמש.
אפליקציות אינטרנט שפועלות רק בדפדפן עשויות להסתמך אך ורק על Google לאימות המשתמשים, ולבחור שלא להטמיע מערכת לניהול חשבונות משתמשים. בתרחיש הזה, שנקרא 'זרם משתמע', אין צורך לשייך אסימון רענון לחשבון משתמש ולאחסון מאובטח לניהול.
לחלופין, נדרשת מערכת של חשבונות משתמשים על ידי זרימת קוד ההרשאה. אסימוני הרענון לכל משתמש חייבים להיות משויכים לחשבון פרטי בפלטפורמת הקצה העורפי שלך, ונשמרים לשימוש במועד מאוחר יותר. אופן ההטמעה, העבודה והניהול של מערכת חשבונות משתמשים הוא ייחודי לפלטפורמה שלכם, ולא נדון בהרחבה.
הצגת ההסכמה וביטולה
המשתמשים יכולים לראות או לבטל את ההסכמה בכל שלב בהגדרות חשבון Google שלהם.
אפליקציית האינטרנט או הפלטפורמה שלכם יכולות להפעיל את google.accounts.oauth2.revoke כדי לבטל אסימונים ולהסיר את הסכמת המשתמשים. הפעולה הזו שימושית כשמשתמש מוחק את החשבון שלו מהפלטפורמה.
אפשרויות הרשאה אחרות
לחלופין, דפדפנים עשויים לקבל אסימוני גישה באמצעות זרימה מרומזת על ידי קריאה ישירה לנקודות הקצה של OAuth 2.0 של Google, כפי שמתואר על ידי OAuth 2.0 לאפליקציות אינטרנט בצד הלקוח.
באופן דומה, לתהליך קוד ההרשאה תוכלו ליישם שיטות משלכם ולבצע את השלבים המפורטים במאמר שימוש ב-OAuth 2.0 לאפליקציות של שרת אינטרנט.
בשני המקרים, מומלץ מאוד להשתמש בספרייה של Google Identity Services כדי לקצר את זמן הפיתוח ולצמצם את סיכוני האבטחה, כמו אלה שמתוארים במאמר השיטות המומלצות לאבטחה ב-OAuth 2.0.