בחירת מודל הרשאה למשתמשים

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

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

ספריית ה-GIS פועלת בדפדפנים נתמכים במכשיר של המשתמש. היא לא מיועדת לשימוש עם מסגרות JavaScript בצד השרת, כמו Node.js. במקום זאת, צריך להשתמש בספריית הלקוח של Node.js של Google.

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

איך מחליטים אם ספריית ה-GIS מתאימה לכם

אתם צריכים לבחור אם להשתמש בספרייה של Google או ליצור ספרייה משלכם, בהתאם למה שמתאים לכם. סקירה כללית של התכונות והפונקציות:

  • ספריית JavaScript של Google Identity Services כוללת את ההטמעות הבאות:
    • תהליכי הסכמה מבוססי-דיאלוג מצמצמים את ההפניות האוטומטיות, ומאפשרים למשתמשים להישאר באתר שלכם לאורך תהליך ההרשאה.
    • תכונות אבטחה כמו בקשה בין אתרים מזויפת (CRSF).
    • שיטות עזר לבקשת היקפי הרשאות נפרדים ולאישור הסכמת המשתמש.
    • טיפול בשגיאות בצורה ידידותית למשתמש וקישורים למסמכי תיעוד לשימוש מהנדסים במהלך הפיתוח, ובהמשך לשימוש מבקרים באתר.
  • כשמטמיעים את התכונה בלי ספריית שירותי הזהויות, אתם אחראים ל:
    • ניהול בקשות ותגובות באמצעות נקודות הקצה של Google OAuth 2.0, כולל הפניות אוטומטיות.
    • אופטימיזציה של חוויית המשתמש.
    • הטמעה של תכונות אבטחה לאימות בקשות ותגובות ולמניעת CSRF.
    • שיטות לאישור שמשתמש העניק הסכמה לכל היקפי ההרשאות המבוקשים.
    • ניהול קודי שגיאה של OAuth 2.0, יצירת הודעות שקל להבין וקישורים לעזרה למשתמשים.

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

בחירת תהליך הרשאה

תצטרכו לבחור אחד משני תהליכי הרשאה של OAuth 2.0: מרומז או קוד הרשאה – לא משנה אם תבחרו להשתמש בספריית JavaScript של Google Identity Services או ליצור ספרייה משלכם.

שני התהליכים האלה מסתיימים באסימון גישה שאפשר להשתמש בו כדי להפעיל ממשקי Google API.

ההבדלים העיקריים בין שני התהליכים הם:

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

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

השוואה בין תהליכי OAuth 2.0

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