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