تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يساعدك هذا الدليل في الاختيار بين استخدام مكتبة Google Identity Services لتفويض المستخدم أو تنفيذ مكتبة JavaScript الخاصة بك. كما يساعدك على تحديد تدفق تفويض OAuth 2.0 الأنسب لتطبيق الويب لديك.
تعمل مكتبة GIS في هذه المتصفحات المتوافقة على جهاز المستخدم. وليس مخصصًا للاستخدام مع إطارات عمل JavaScript من جهة الخادم مثل Node.js،
بدلاً من ذلك استخدم مكتبة عملاء Node.js
من Google.
يجب عليك اختيار ما إذا كنت تستخدم مكتبة Google، أو إنشاء مكتبة خاصة بك يناسب احتياجاتك. نظرة عامة على الميزات والوظائف:
تنفّذ مكتبة JavaScript لخدمات الهوية في Google ما يلي:
عمليات الموافقة المستندة إلى النوافذ المنبثقة لتقليل عمليات إعادة التوجيه، ما يتيح للمستخدمين
البقاء على موقعك الإلكتروني طوال عملية منح الإذن
ميزات الأمان مثل تزوير الطلبات من مواقع إلكترونية متعددة (CRSF)
طرق مساعدة لطلب نطاقات فردية وتأكيد موافقة المستخدم
التعامل مع الأخطاء الصديقة للبشر وروابط التوثيق ليستخدمها المهندسون أثناء التطوير أو لاحقًا لزائري موقعك.
عند التنفيذ بدون مكتبة "خدمات الهوية"، تكون مسؤولاً عن
ما يلي:
إدارة الطلبات والاستجابات باستخدام نقاط نهاية 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
فقط من تطبيق ويب يعمل في متصفح المستخدم.
إمّا من خادم يعمل على نظام أساسي خلفية أو من تطبيق ويب
يتم تشغيله في متصفّح المستخدم.
يتطلّب النظام الأساسي للخلفية
لا
نعم، لاستضافة نقاط النهاية وتخزينها.
مساحة تخزين آمنة مطلوبة
لا
نعم، لتخزين الرمز المميّز لإعادة التحميل.
يتطلب استضافة نقطة نهاية رمز التفويض
لا
نعم، للحصول على رموز تفويض من Google.
سلوك انتهاء صلاحية رمز الوصول المميّز
يجب استخدام إيماءة المستخدم، مثل الضغط على زر أو النقر على رابط،
لطلب رمز دخول صالح جديد والحصول عليه.
بعد طلب أولي من المستخدم، تتبادل المنصّة الرمز المميّز لإعادة التحميل
المخزَّن للحصول على رمز دخول جديد وصالح وضروري للاتصال بواجهات برمجة تطبيقات
Google.
تاريخ التعديل الأخير: 2023-12-01 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2023-12-01 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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. |"]]
