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