با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
این راهنما به شما کمک می کند بین استفاده از کتابخانه خدمات هویت گوگل برای مجوز کاربر یا پیاده سازی کتابخانه جاوا اسکریپت خود یکی را انتخاب کنید. این به شما کمک می کند تصمیم بگیرید که کدام جریان مجوز OAuth 2.0 برای برنامه وب شما بهترین است.
پیش از خواندن این راهنما، فرض بر این است که با اصطلاحات و مفاهیم شرح داده شده در راهنمای نمای کلی و نحوه عملکرد مجوز کاربر آشنا هستید.
کتابخانه GIS در این مرورگرهای پشتیبانی شده در دستگاه کاربر اجرا می شود. این برای استفاده با چارچوب های جاوا اسکریپت سمت سرور مانند Node.js در نظر گرفته نشده است، در عوض از کتابخانه مشتری Node.js Google استفاده کنید.
تصمیم گیری در مورد اینکه آیا کتابخانه GIS برای شما مناسب است یا خیر
شما باید انتخاب کنید که آیا از کتابخانه Google استفاده می‌کنید یا اینکه بهترین مورد را برای نیازهایتان ایجاد کنید. مروری بر ویژگی ها و عملکردها:
کتابخانه جاوا اسکریپت خدمات هویت گوگل پیاده سازی می کند:
رضایت مبتنی بر پنجره بازشو جریان می یابد تا تغییر مسیرها را به حداقل برساند، بنابراین کاربران را قادر می سازد در طول فرآیند مجوز در سایت شما باقی بمانند.
ویژگی های امنیتی مانند جعل درخواست بین سایتی (CRSF).
روش های کمکی برای درخواست دامنه های فردی و تأیید رضایت کاربر.
پیوندهای مربوط به مدیریت خطا و مستندسازی برای استفاده مهندسان در طول توسعه و بعداً برای بازدیدکنندگان سایت شما.
هنگام پیاده سازی بدون کتابخانه خدمات هویت، شما مسئول موارد زیر هستید:
مدیریت درخواست‌ها و پاسخ‌ها با نقاط پایانی OAuth 2.0 Google، از جمله تغییر مسیرها.
بهینه سازی تجربه کاربری
پیاده سازی ویژگی های امنیتی برای اعتبارسنجی درخواست ها، پاسخ ها و جلوگیری از CSRF.
روش‌هایی برای تأیید رضایت کاربر برای هر دامنه درخواستی.
مدیریت کدهای خطای OAuth 2.0، ایجاد پیام های قابل خواندن توسط انسان، و پیوندهایی به کمک کاربر.
به طور خلاصه، Google کتابخانه GIS را برای کمک به شما در پیاده سازی سریع و ایمن مشتری OAuth 2.0 و بهینه سازی تجربه مجوز کاربر ارائه می دهد.
انتخاب یک جریان مجوز
شما باید یکی از دو جریان مجوز OAuth 2.0 را انتخاب کنید: کد ضمنی یا مجوز - صرف نظر از اینکه تصمیم دارید از کتابخانه جاوا اسکریپت خدمات هویت Google استفاده کنید یا کتابخانه خود را ایجاد کنید.
هر دو جریان منجر به یک نشانه دسترسی می شوند که می تواند برای فراخوانی API های Google استفاده شود.
تفاوت اصلی بین این دو جریان عبارتند از:
تعداد اقدامات کاربر،
آیا برنامه شما بدون حضور کاربر با Google API تماس خواهد گرفت،
اگر یک پلتفرم باطن برای میزبانی یک نقطه پایانی و ذخیره نشانه‌های تازه‌سازی هر کاربر برای حساب‌های کاربری فردی مورد نیاز است، و
سطوح بالاتر یا پایین تر امنیت کاربر
هنگام مقایسه جریان ها و ارزیابی الزامات امنیتی خود، فاکتوری که باید در نظر گرفت این است که سطح امنیت کاربر بسته به دامنه انتخابی شما متفاوت است. برای مثال، مشاهده دعوت‌های تقویم به‌عنوان فقط خواندنی ممکن است در مقایسه با استفاده از محدوده خواندن/نوشتن برای ویرایش فایل‌ها در Drive، خطر کمتری در نظر گرفته شود.
مقایسه جریان OAuth 2.0
جریان ضمنی
جریان کد مجوز
رضایت کاربر لازم است
برای هر درخواست توکن، از جمله جایگزینی توکن های منقضی شده.
فقط برای اولین درخواست رمز.
کاربر باید حضور داشته باشد
آره
خیر، از استفاده آفلاین پشتیبانی می کند.
امنیت کاربر
کمترین
اکثر آنها دارای احراز هویت مشتری هستند و از خطرات مدیریت توکن درون مرورگر جلوگیری می کنند.
رمز دسترسی صادر شد
آره
آره
نشانه Refresh صادر شد
خیر
آره
مرورگر پشتیبانی شده مورد نیاز است
آره
آره
رمز دسترسی که برای فراخوانی APIهای Google استفاده می شود
فقط از یک برنامه وب در حال اجرا در مرورگر کاربر.
یا از یک سرور در حال اجرا بر روی پلتفرم باطن، یا از یک برنامه وب در حال اجرا در مرورگر کاربر.
به پلتفرم باطن نیاز دارد
خیر
بله، برای میزبانی و ذخیره‌سازی نقطه پایانی.
ذخیره سازی ایمن مورد نیاز است
خیر
بله، برای ذخیره سازی رمز تازه.
به میزبانی یک نقطه پایانی کد مجوز نیاز دارد
خیر
بله، برای دریافت کدهای مجوز از Google.
به رفتار انقضای نشانه دسترسی داشته باشید
یک حرکت کاربر مانند فشار دادن دکمه یا کلیک کردن روی یک پیوند برای درخواست و دریافت یک نشانه دسترسی جدید و معتبر لازم است.
پس از درخواست اولیه کاربر، پلتفرم شما رمز تجدید ذخیره شده را مبادله می کند تا یک نشانه دسترسی جدید و معتبر لازم برای فراخوانی APIهای Google را به دست آورد.
تاریخ آخرین بهروزرسانی 2023-12-02 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2023-12-02 بهوقت ساعت هماهنگ جهانی."],[[["\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. |"]]
