המדריך הזה יעזור לכם לבחור בין שימוש בספרייה של Google Identity Services להרשאת משתמש או הטמעה של ספריית JavaScript שלכם. הוא עוזר לך להחליט איזה תהליך אימות OAuth 2.0 הוא המתאים ביותר לאפליקציית האינטרנט שלך.
לפני קריאת המדריך הזה, אנחנו מניחים שאתם מכירים את המונחים והקונספטים המתוארים במדריך סקירה כללית ואיך פועלת הרשאת משתמש.
ספריית GIS פועלת בדפדפנים הנתמכים במכשיר של המשתמש. הוא לא מיועד לשימוש במסגרות JavaScript בצד השרת, כגון Node.js, אלא השתמש בספריית הלקוחות של Google'. Node.js.
מדריך זה עוסק רק בנושאים הקשורים להרשאות ולשיתוף נתונים. היא לא בודקת אימות של משתמש, אלא את כניסה באמצעות חשבון Google ואת מיגרציה מכניסה באמצעות חשבון Google לצורך הרשמה של משתמש וכניסה.
מחליטים אם ספריית GIS מתאימה לכם
אתם צריכים לבחור אם להשתמש בספרייה של Google, או ליצור תוכן משלכם, בהתאם לצרכים שלכם. סקירה כללית של תכונות ופונקציונליות:
- ספריית JavaScript של Google Services Services בהטמעה:
- תהליכי הסכמה שמבוססים על חלונות קופצים מאפשרים לצמצם מקרים של הפניות אוטומטיות, וכך מאפשרים למשתמשים להישאר באתר לאורך תהליך ההרשאה.
- תכונות אבטחה כגון Forssite Request Forgery (CRSF).
- שיטות סיוע לבקשת היקפים בודדים ולאישור הסכמת המשתמשים.
- טיפול ידידותי בני אדם לטיפול בשגיאות ומסמכי תיעוד לשימוש של מהנדסי תוכנה במהלך הפיתוח ומאוחר יותר למבקרים באתר.
- כשמטמיעים אפליקציות בלי הספרייה של שירותי הזהויות,
האחריות מוטלת עליך:
- ניהול בקשות ותגובות באמצעות נקודות הקצה של OAuth 2.0 ב-Google, כולל הפניות אוטומטיות.
- אופטימיזציה של חוויית המשתמש.
- הטמעה של תכונות אבטחה לצורך אימות בקשות, תגובות ומניעה של CSRF.
- שיטות לאישור משתמש שקיבל הסכמה להיקפים שהתבקשו.
- ניהול קודי שגיאה של OAuth 2.0, יצירת הודעות שניתן לקרוא אנושיות וקישורים לעזרה של משתמשים.
לסיכום, Google מציעה את ספריית GIS כדי לעזור לכם להטמיע לקוח OAuth 2.0 במהירות ובאופן מאובטח ולבצע אופטימיזציה של חוויית ההרשאה של המשתמש.
בחירת תהליך הרשאה
יהיה עליך לבחור באחד משני תהליכי ההרשאה של OAuth 2.0: קוד מרומז או הרשאה, גם אם תחליט להשתמש בספריית JavaScript של שירותי Google Identity או ליצור ספרייה משלך.
שני התהליכים מובילים לאסימון גישה שניתן להשתמש בו כדי להפעיל את Google APIs.
ההבדלים העיקריים בין שני התהליכים הם:
- מספר פעולות המשתמש,
- האם האפליקציה תקרא לממשקי Google API ללא הצגת המשתמש,
- אם יש צורך בפלטפורמת קצה עורפי כדי לארח נקודת קצה ולאחסן אסימונים לכל משתמש עבור חשבונות משתמש נפרדים,
- רמות אבטחה גבוהות או נמוכות יותר.
כשמשווים בין תהליכים ובוחנים את דרישות האבטחה, כדאי להביא בחשבון את רמת האבטחה של המשתמשים בהתאם להיקפים שבחרתם. לדוגמה, ייתכן שצפייה ביומן ביומן כקריאה בלבד עלולה להיות פחות מסוכנת מאשר להשתמש בהיקף קריאה/כתיבה כדי לערוך קבצים ב-Drive.
השוואה בין זרימת OAuth 2.0
| תהליך מרומז | תהליך קוד ההרשאה | |
| נדרשת הסכמת משתמש | לכל בקשת אסימון, כולל החלפת אסימונים שפג תוקפם. | רק לבקשת האסימון הראשונה. |
| המשתמש חייב להופיע | כן | לא, תמיכה בשימוש במצב אופליין. |
| אבטחת משתמשים | הכי פחות | רובם מאמתים זהות של לקוחות ונמנעים מסיכונים הקשורים לטיפול באסימונים בדפדפן. |
| הונפק אסימון גישה | כן | כן |
| רענון האסימון של האסימון | לא | כן |
| נדרש דפדפן נתמך | כן | כן |
| אסימון גישה המשמש לקריאה ל-Google APIs | רק מאפליקציית אינטרנט שפועלת בדפדפן המשתמש. | משרת שפועל בפלטפורמת קצה עורפי או מאפליקציית אינטרנט שפועלת בדפדפן המשתמש. |
| נדרשת פלטפורמה לקצה העורפי | לא | כן, לצורך אירוח ואחסון של נקודות קצה. |
| נדרש נפח אחסון מאובטח | לא | כן, אני רוצה לאחסן את אסימון האסימון. |
| נדרש אירוח של נקודת קצה (endpoint) של קוד הרשאה | לא | כן, כדי לקבל את קודי ההרשאה מ-Google. |
| התנהגות תפוגת אסימון גישה | תנועת משתמשים, כמו לחיצה על לחצן או לחיצה על קישור, נדרשת כדי לבקש אסימון גישה חדש וחוקי. | לאחר בקשת משתמש ראשונית, הפלטפורמה מחליפה את אסימון הרענון המאוחסן לצורך קבלת אסימון גישה חוקי וחדש המאפשר קריאה ל-Google APIs. |