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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השוואה בין זרימה של OAuth 2.0

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