במדריך הזה תוכלו לבחור אם להשתמש בספרייה של Google Identity Services לצורך הרשאת משתמשים או להטמיע ספריית JavaScript משלכם. תוכלו להיעזר בנתון הזה כדי להחליט איזה תהליך הרשאה של OAuth 2.0 הוא המתאים ביותר לאפליקציית האינטרנט שלכם.
לפני שתקראו את המדריך, ההנחה היא שאתם מכירים את המונחים והמושגים המתוארים במדריך סקירה כללית ואיך פועלת הרשאת משתמש.
ספריית GIS פועלת בדפדפנים הנתמכים האלה במכשיר של המשתמש. הוא לא מיועד לשימוש במסגרות JavaScript בצד השרת, כמו Node.js, במקום להשתמש בספריית הלקוח Node.js של Google.
המדריך הזה עוסק רק בנושאים של הרשאות ושיתוף נתונים. היא לא בודקת את אימות המשתמשים. במקום זאת, תוכלו לעיין במאמר כניסה באמצעות חשבון Google ובמדריך העברה מכניסה באמצעות חשבון Google להרשמה ולכניסה של משתמשים.
החלטה אם ספריית GIS מתאימה לך
עליכם לבחור אם להשתמש בספרייה של Google, או ליצור תוכן משלכם שמתאים לצרכים שלכם. סקירה כללית של תכונות ופונקציונליות:
- ספריית ה-JavaScript של Identity Services מטמיעה:
- תהליך ההסכמה מבוסס-חלון קופץ מאפשר לצמצם את ההפניות האוטומטיות, וכך מאפשר למשתמשים להישאר באתר לכל אורך תהליך ההרשאה.
- תכונות אבטחה כמו Cross-Site Request Forgery (CRSF).
- שיטות עוזרות לבקש היקפים נפרדים ולאשר את הסכמת המשתמשים.
- קישורים לתיעוד ולטיפול בשגיאות ידידותיים לסביבה, לשימוש על ידי מהנדסים במהלך הפיתוח ולאחר מכן למבקרים באתר.
- בהטמעה ללא הספרייה של Identity Services באחריותך:
- ניהול בקשות ותגובות באמצעות נקודות הקצה של OAuth 2.0 של Google, כולל הפניות אוטומטיות.
- אופטימיזציה של חוויית המשתמש.
- הטמעה של תכונות אבטחה כדי לאמת בקשות ותשובות ולמנוע 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. |