קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
במדריך הזה תוכלו לבחור אם להשתמש בספרייה של Google Identity Services לצורך הרשאת משתמשים או להטמיע ספריית JavaScript משלכם. תוכלו להיעזר בנתון הזה כדי להחליט איזה תהליך הרשאה של OAuth 2.0 הוא המתאים ביותר לאפליקציית האינטרנט שלכם.
ספריית GIS פועלת בדפדפנים הנתמכים האלה במכשיר של המשתמש. הוא לא מיועד לשימוש במסגרות JavaScript בצד השרת, כמו Node.js, במקום להשתמש בספריית הלקוח Node.js של Google.
עליכם לבחור אם להשתמש בספרייה של 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.
[null,null,["עדכון אחרון: 2023-12-01 (שעון UTC)."],[[["\u003cp\u003eThis guide helps developers choose between Google Identity Services or a custom JavaScript library for OAuth 2.0 authorization in their web applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services offers pre-built security features, optimized user experience, and easier implementation compared to building a custom solution.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers need to select between the Implicit or Authorization Code flow based on security, user presence requirements, and backend needs.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization Code flow is recommended for enhanced security, offline access, and refresh token management through a backend server.\u003c/p\u003e\n"],["\u003cp\u003eThe guide assumes prior knowledge of OAuth 2.0 concepts and focuses solely on authorization and data sharing, not user authentication.\u003c/p\u003e\n"]]],[],null,["# Choose a user authorization model\n\nThis guide helps you to choose between using the Google Identity Services\nlibrary for user authorization or implementing your own JavaScript library. It\nhelps you decide which OAuth 2.0 authorization flow is best for your web\napplication.\n\nPrior to reading this guide it is assumed that you are familiar with the terms\nand concepts described in the [Overview](/identity/oauth2/web/guides/overview) and\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) guide.\n\nThe GIS library runs in these [supported browsers](/identity/gsi/web/guides/supported-browsers) on the user's device. It\nis not intended for use with server-side JavaScript frameworks such as Node.js,\ninstead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nThis guide only covers authorization and data sharing topics. It does not review\nuser authentication, instead see [Sign In With Google](/identity/gsi/web) and the [Migrating\nfrom Google Sign-In](/identity/gsi/web/guides/migration) guide for user sign-up and sign-in.\n\nDeciding if the GIS library is right for you\n--------------------------------------------\n\nYou must choose if using Google's library, or creating your own best fits your\nneeds. An overview of features and functionality:\n\n- Google's Identity Services JavaScript library implements:\n - Popup based consent flows to minimize redirects, thus enabling users to remain on your site throughout the authorization process.\n - Security features such as Cross-site Request Forgery (CRSF).\n - Helper methods to request individual scopes and confirm user consent.\n - Human friendly error handling and documentation links for use by engineers during development and later for visitors to your site.\n- When implementing without the Identity Services library you are responsible for:\n - Managing requests and responses with Google's OAuth 2.0 endpoints, including redirects.\n - Optimizing the user experience.\n - Implementation of security features to validate requests, responses, and to prevent CSRF.\n - Methods to confirm a user has granted consent for any requested scopes.\n - Managing OAuth 2.0 error codes, creating human readable messages, and links to user help.\n\nIn summary, Google offers the GIS library to help you to quickly, and securely\nimplement an OAuth 2.0 client and optimize the user's authorization experience.\n\nChoosing an authorization flow\n------------------------------\n\nYou will need to choose one of two OAuth 2.0 authorization flows: implicit or\nauthorization code -- regardless if you decide to use the Google Identity\nServices JavaScript library or to create your own library.\n\nBoth flows result in an access token which can be used to call Google APIs.\n\nThe primary differences between the two flows are:\n\n- the number of user actions,\n- whether your app will call Google APIs without the user present,\n- if a backend platform is needed to host an endpoint and to store per-user refresh tokens for individual user accounts, and\n- higher or lower levels of user security.\n\nWhen comparing flows and evaluating your security requirements, a factor to\nconsider is that the level of user security varies depending on the scopes you\nchoose. For example, viewing calendar invites as read-only might be considered\nless risky than using a read/write scope to edit files in Drive.\n| **Key Point:** Authorization code flow is recommended because it provides a more secure flow.\n\nOAuth 2.0 flow comparison\n-------------------------\n\n|--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Implicit flow** | **Authorization code flow** |\n| **User consent required** | For every token request, including replacing expired tokens. | Only for the first token request. |\n| **User must be present** | Yes | No, supports offline use. |\n| **User security** | Least | Most, has client authentication and avoids in-browser token handling risks. |\n| **Access token issued** | Yes | Yes |\n| **Refresh token issued** | No | Yes |\n| **Supported browser required** | Yes | Yes |\n| **Access token used to call Google APIs** | only from a web app running in the user's browser. | either from a server running on backend platform, or from a web app running in the user's browser. |\n| **Requires backend platform** | No | Yes, for endpoint hosting and storage. |\n| **Secure storage needed** | No | Yes, for refresh token storage. |\n| **Requires hosting of an authorization code endpoint** | No | Yes, to receive authorization codes from Google. |\n| **Access token expiration behavior** | A user gesture such as button press or clicking on a link is required to request and obtain a new, valid access token. | After an initial user request, your platform exchanges the stored refresh token to obtain a new, valid access token necessary to call Google APIs. |"]]
