با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
این صفحه برخی از بهترین روش‌های عمومی را برای ادغام با OAuth 2.0 پوشش می‌دهد. این بهترین شیوه ها را علاوه بر هر راهنمایی خاص برای نوع برنامه کاربردی و پلت فرم توسعه خود در نظر بگیرید. همچنین به توصیه برای آماده کردن برنامه خود برای تولید و خط‌مشی‌های Google OAuth 2.0 مراجعه کنید.
به طور ایمن اعتبار مشتری را مدیریت کنید
اعتبارنامه مشتری OAuth هویت برنامه شما را شناسایی می کند و باید با دقت مورد استفاده قرار گیرد. این اعتبارنامه‌ها را فقط در فضای ذخیره‌سازی ایمن ذخیره کنید، برای مثال با استفاده از یک مدیر مخفی مانند Google Cloud Secret Manager . اعتبارنامه ها را کد سختی نکنید، آنها را به یک مخزن کد و یا به صورت عمومی منتشر نکنید.
توکن های کاربر را ایمن مدیریت کنید
توکن‌های کاربر هم شامل نشانه‌های تازه‌سازی و هم نشانه‌های دسترسی مورد استفاده برنامه شما هستند. توکن ها را به صورت ایمن در حالت استراحت ذخیره کنید و هرگز آنها را به صورت متن ساده ارسال نکنید. از یک سیستم ذخیره سازی امن مناسب برای پلتفرم خود استفاده کنید، مانند Keystore در Android، Keychain Services در iOS و macOS، یا Credential Locker در Windows.
علاوه بر این، این بهترین شیوه ها را برای پلتفرم خود نیز در نظر بگیرید:
برای برنامه‌های سمت سرور که توکن‌ها را برای بسیاری از کاربران ذخیره می‌کنند، آنها را در حالت استراحت رمزگذاری کنید و اطمینان حاصل کنید که فروشگاه داده‌های شما برای عموم در دسترس اینترنت نیست.
برای برنامه‌های دسک‌تاپ بومی، استفاده از پروتکل Proof Key for Code Exchange (PKCE) برای دریافت کدهای مجوزی که می‌توانند با نشانه‌های دسترسی مبادله شوند، اکیداً توصیه می‌شود.
ابطال و انقضای نشانه رفرش را مدیریت کنید
اگر برنامه شما برای دسترسی آفلاین توکن به‌روزرسانی درخواست کرده است، باید ابطال یا انقضای آن را نیز رسیدگی کنید. نشانه‌ها ممکن است به دلایل مختلف باطل شوند، برای مثال ممکن است منقضی شده باشد یا دسترسی برنامه‌های شما توسط کاربر لغو شده باشد یا یک فرآیند خودکار. در این مورد، به دقت در نظر بگیرید که برنامه شما چگونه باید پاسخ دهد، از جمله درخواست کاربر در ورود به سیستم بعدی یا پاک کردن داده های او. برای اطلاع از لغو توکن، با سرویس محافظت از حساب‌های متقابل ادغام شوید.
از مجوز افزایشی استفاده کنید
از مجوز افزایشی برای درخواست دامنه های OAuth مناسب زمانی که برنامه شما به عملکرد نیاز دارد استفاده کنید.
وقتی کاربر برای اولین بار احراز هویت می شود، نباید درخواست دسترسی به داده ها را بدهید، مگر اینکه برای عملکرد اصلی برنامه شما ضروری باشد. در عوض، فقط دامنه‌های خاصی را که برای یک کار مورد نیاز است، درخواست کنید، و از اصل انتخاب کوچک‌ترین و محدودترین محدوده ممکن پیروی کنید.
همیشه دامنه‌ها را در زمینه درخواست کنید تا به کاربران خود کمک کنید بفهمند چرا برنامه شما درخواست دسترسی می‌کند و چگونه از داده‌ها استفاده می‌شود.
به عنوان مثال، برنامه شما ممکن است از این مدل پیروی کند:
کاربر با برنامه شما احراز هویت می کند
هیچ محدوده اضافی درخواست نمی شود. این برنامه عملکردهای اساسی را ارائه می دهد تا به کاربر امکان می دهد ویژگی هایی را که نیازی به داده یا دسترسی اضافی ندارند کاوش و استفاده کند.
کاربر یک ویژگی را انتخاب می کند که نیاز به دسترسی به داده های اضافی دارد
برنامه شما یک درخواست مجوز برای این محدوده OAuth خاص مورد نیاز برای این ویژگی می کند. اگر این ویژگی به چندین حوزه نیاز دارد، بهترین روش‌های زیر را دنبال کنید.
اگر کاربر درخواست را رد کند، برنامه این ویژگی را غیرفعال می کند و به کاربر زمینه اضافی برای درخواست دسترسی مجدد می دهد.
رسیدگی به رضایت برای حوزه های متعدد
هنگام درخواست چندین دامنه به طور همزمان، کاربران ممکن است همه دامنه های OAuth را که درخواست کرده اید اعطا نکنند. برنامه شما باید با غیرفعال کردن عملکرد مربوطه، انکار دامنه ها را کنترل کند.
اگر عملکرد اصلی برنامه شما به چندین حوزه نیاز دارد، قبل از درخواست رضایت، این موضوع را برای کاربر توضیح دهید.
تنها زمانی می‌توانید از کاربر درخواست کنید که به وضوح قصد استفاده از ویژگی خاصی را که به محدوده نیاز دارد، نشان دهد. برنامه شما باید پیش از درخواست دامنه های OAuth، زمینه و توجیه مرتبط را در اختیار کاربر قرار دهد.
در وب، درخواست های مجوز OAuth 2.0 فقط باید از مرورگرهای وب با امکانات کامل انجام شود. در سایر پلتفرم‌ها، مطمئن شوید که نوع مشتری OAuth صحیح را انتخاب کرده و OAuth را متناسب با پلتفرم خود ادغام کنید. درخواست را از طریق محیط‌های مرور تعبیه‌شده، از جمله مشاهده‌های وب در پلتفرم‌های تلفن همراه، مانند WebView در Android یا WKWebView در iOS، هدایت نکنید. در عوض، از کتابخانه های بومی OAuth یا Google Sign-in برای پلتفرم خود استفاده کنید.
ایجاد و پیکربندی دستی مشتریان OAuth
به منظور جلوگیری از سوء استفاده، سرویس گیرندگان OAuth را نمی توان به صورت برنامه ریزی شده ایجاد یا تغییر داد. برای تأیید صریح شرایط خدمات، پیکربندی مشتری OAuth و آماده شدن برای تأیید OAuth، باید از کنسول توسعه دهندگان Google استفاده کنید.
برای گردش کار خودکار، به جای آن از حساب های خدماتی استفاده کنید.
کلاینت های استفاده نشده OAuth را حذف کنید
به طور منظم مشتریان OAuth 2.0 خود را بررسی کنید و به طور فعال هر کدام را که دیگر مورد نیاز برنامه شما نیست یا منسوخ شده است حذف کنید. پیکربندی نشدن کلاینت‌های استفاده نشده نشان‌دهنده یک خطر امنیتی بالقوه است، زیرا اگر اعتبار مشتری شما به خطر بیفتد، ممکن است از مشتری سوء استفاده شود.
برای کاهش بیشتر خطرات ناشی از مشتریان استفاده نشده، مشتریان OAuth 2.0 که به مدت شش ماه غیرفعال بوده اند به طور خودکار حذف می شوند.
بهترین روش توصیه شده این است که منتظر حذف خودکار نباشید، بلکه به طور فعال کلاینت های استفاده نشده را حذف کنید. این عمل سطح حمله برنامه شما را به حداقل می رساند و بهداشت امنیتی خوبی را تضمین می کند.
تاریخ آخرین به‌روزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین به‌روزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی."],[[["\u003cp\u003eSecurely store and manage OAuth client credentials, avoiding hardcoding or public exposure.\u003c/p\u003e\n"],["\u003cp\u003eProtect user tokens (refresh and access) by storing them securely and revoking them when no longer needed.\u003c/p\u003e\n"],["\u003cp\u003eImplement proper handling of refresh token revocation and expiration scenarios, including user notification and data cleanup.\u003c/p\u003e\n"],["\u003cp\u003eUtilize incremental authorization to request only necessary OAuth scopes in context, minimizing initial requests and enhancing user privacy.\u003c/p\u003e\n"],["\u003cp\u003eEmploy secure browsing environments for OAuth authorization requests, avoiding embedded browsers like webviews and opting for native libraries or Google Sign-in.\u003c/p\u003e\n"]]],[],null,["This page covers some general best practices for integrating with OAuth 2.0. Consider these best\npractices in addition to any specific guidance for your type of application and development\nplatform. Also refer to the\n[advice for getting\nyour app ready for production](/identity/protocols/oauth2/production-readiness/policy-compliance) and [Google's\nOAuth 2.0 policies](/identity/protocols/oauth2/policies).\n\nHandle client credentials securely\n\n\nThe OAuth client credentials identify your app's identity and should be handled carefully. Only\nstore these credentials in secure storage, for example using a secret manager such as\n[Google Cloud Secret Manager](https://cloud.google.com/secret-manager/docs/overview).\nDo not hardcode the credentials, commit them to a code repository or publish them publicly.\n\nHandle user tokens securely\n\n\nUser tokens include both refresh tokens and access tokens used by your application. Store\ntokens securely [at rest](https://wikipedia.org/wiki/Data_at_rest)\nand never transmit them in plain text. Use a secure storage system appropriate for your\nplatform, such as\n[Keystore](https://developer.android.com/training/articles/keystore) on Android,\nKeychain Services on iOS and macOS, or Credential Locker on Windows.\n\n\n[Revoke tokens](/identity/protocols/oauth2/web-server#tokenrevoke) as soon as they\nare no longer needed and delete them permanently from your systems.\n\n\nIn addition, also consider these best practices for your platform:\n\n- For [server-side](/identity/protocols/oauth2/web-server) applications that store tokens for many users, encrypt them at rest and ensure that your data store is not publicly accessible to the Internet.\n- For native desktop apps, using the [Proof Key for Code\n Exchange (PKCE) protocol](/identity/protocols/oauth2/native-app#obtainingaccesstokens) is strongly recommended to obtain authorization codes that can be exchanged for access tokens.\n\nHandle refresh token revocation and expiration\n\n\nIf your app has requested a [refresh\ntoken for offline access](/identity/protocols/oauth2/web-server#offline), you must also handle their invalidation or expiration. Tokens\ncould be [invalidated for different reasons](/identity/protocols/oauth2#expiration),\nfor example it could have expired or your apps' access could have been revoked by the user or\nan automated process. In this case, consider carefully how your application should respond,\nincluding prompting the user at their next log in or cleaning up their data. To be notified of\ntoken revocation, integrate with the [Cross-Account\nProtection](/identity/protocols/risc) service.\n\nUse incremental authorization\n\n\nUse [incremental\nauthorization](/identity/protocols/oauth2/web-server#incrementalAuth) to request appropriate OAuth scopes when the functionality is needed by your\napplication.\n\n\nYou should not request access to data when the user first authenticates, unless it is essential\nfor the core functionality of your app. Instead, request only the specific scopes that are\nneeded for a task, following the principle to\n[select the smallest, most limited scopes possible](/identity/protocols/oauth2/production-readiness/policy-compliance#only-request-needed-scopes).\n\n\nAlways request scopes in context to help your users understand why your app is requesting access\nand how the data will be used.\n\n\nFor example, your application may follow this model:\n\n1. The user authenticates with your app\n 1. No additional scopes are requested. The app provides basic functionality to let the user explore and use features that do not require any additional data or access.\n2. The user selects a feature that requires access to additional data\n 1. Your application makes an authorization request for this specific OAuth scope required for this feature. If this feature requires multiple scopes, follow [the best practices below](#multiple-scopes).\n 2. If the user denies the request, the app disables the feature and gives the user additional context to request access again.\n\nHandle consent for multiple scopes\n\n\nWhen requesting multiple scopes at once, users may not grant all OAuth scopes you have\nrequested. Your app should handle the denial of scopes by disabling relevant functionality.\n\n\nIf your app's basic functionality requires multiple scopes, explain this to the user before\nprompting for consent.\n\n\nYou may only prompt the user again once they have clearly indicated an intent to use the\nspecific feature that requires the scope. Your app should provide the user with relevant context\nand justification before requesting OAuth scopes.\n\n\nYou should minimize the number of scopes your app requests at once. Instead,\n[utilize incremental authorization](#use-incremental-authorization) to request scopes\nin context of features and functionality.\n\nUse secure browsers\n\n\nOn the web, OAuth 2.0 authorization requests must only be made from full-featured web browsers.\nOn other platforms, make sure to select the\n[correct OAuth client type](/identity/protocols/oauth2#basicsteps) and integrate\nOAuth as appropriate for your platform. Do not redirect the request through embedded browsing\nenvironments, including webviews on mobile platforms, such as WebView on Android or WKWebView on\niOS. Instead, utilize [native OAuth libraries](/identity/protocols/oauth2/native-app)\nor [Google Sign-in](/identity/authorization) for your platform.\n\nManual creation and configuration of OAuth clients\n\n\nIn order to prevent abuse, OAuth clients cannot be created or modified programmatically. You\nmust use the Google Developers console to explicitly acknowledge the terms of service, configure\nyour OAuth client and prepare for OAuth verification.\n\n\nFor automated workflows, consider using\n[service accounts](/identity/protocols/oauth2/service-account) instead.\n\nRemove unused OAuth clients\n\n\nRegularly audit your OAuth 2.0 clients and proactively delete any that are no longer required by\nyour application or have become obsolete. Leaving unused clients configured represents a\npotential security risk as the client can be misused if your client credentials are ever\ncompromised.\n\n\nTo further mitigate risks from unused clients, OAuth 2.0 clients that have been inactive for six\nmonths are [automatically deleted](https://support.google.com/cloud/answer/15549257#unused-client-deletion).\n\n\nThe recommended best practice is to not wait for automatic deletion but rather proactively\nremove unused clients. This practice minimizes your application's attack surface and ensures\ngood security hygiene."]]
