أفضل الممارسات
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تتناول هذه الصفحة بعض أفضل الممارسات العامة المتعلّقة بالتكامل مع بروتوكول OAuth 2.0. ننصحك باتّباع أفضل الممارسات التالية بالإضافة إلى أي إرشادات خاصة بنوع تطبيقك ومنصة التطوير التي تستخدمها. يُرجى أيضًا الرجوع إلى
النصائح حول إعداد
تطبيقك للإصدار العلني وسياسات
بروتوكول OAuth 2.0 من Google.
التعامل مع بيانات اعتماد العميل بأمان
تحدّد بيانات اعتماد عميل OAuth هوية تطبيقك ويجب التعامل معها بعناية. يجب تخزين بيانات الاعتماد هذه في مساحة تخزين آمنة فقط، مثلاً باستخدام مدير أسرار مثل Google Cloud Secret Manager.
لا تضع بيانات الاعتماد في الرمز البرمجي بشكل ثابت أو ترسِلها إلى مستودع الرموز البرمجية أو تنشرها بشكل علني.
التعامل مع رموز المستخدمين المميزة بشكل آمن
تتضمّن رموز المستخدمين المميزة كلاً من رموز التحديث ورموز الدخول التي يستخدمها تطبيقك. تخزين الرموز المميزة بشكل آمن في حالة عدم الاستخدام وعدم إرسالها مطلقًا كنص عادي استخدِم نظام تخزين آمنًا مناسبًا للنظام الأساسي الذي تستخدمه، مثل Keystore على Android أو Keychain Services على iOS وmacOS أو Credential Locker على Windows.
إبطال الرموز المميزة فور الاستغناء عنها وحذفها نهائيًا من أنظمتك
بالإضافة إلى ذلك، ننصحك أيضًا باتّباع أفضل الممارسات التالية لمنصتك:
- بالنسبة إلى التطبيقات من جهة الخادم التي تخزّن الرموز المميزة للعديد من المستخدمين، يجب ترميزها أثناء عدم النشاط والتأكّد من أنّ مخزن البيانات غير متاح للجميع على الإنترنت.
- بالنسبة إلى تطبيقات سطح المكتب الأصلية، يُنصح بشدة باستخدام بروتوكول مفتاح حماية تبادل الرموز (PKCE) للحصول على رموز تفويض يمكن استبدالها برموز الدخول.
التعامل مع إبطال الرمز المميز لإعادة التحميل وانتهاء صلاحيته
إذا طلب تطبيقك رمزًا مميزًا لإعادة التحميل
للوصول بلا إنترنت، عليك أيضًا التعامل مع إبطاله أو انتهاء صلاحيته. يمكن إبطال الرموز المميزة لأسباب مختلفة،
مثل انتهاء صلاحيتها أو إلغاء المستخدم أو عملية مبرمَجة إذن الوصول إلى تطبيقاتك. في هذه الحالة، يجب التفكير مليًا في كيفية استجابة تطبيقك،
بما في ذلك مطالبة المستخدم بتسجيل الدخول في المرة التالية أو تنظيف بياناته. لتلقّي إشعارات بشأن إبطال الرموز المميّزة، يجب الدمج مع خدمة الحماية العابرة للحساب.
استخدام التفويض التدريجي
استخدِم التفويض
التزايدي لطلب نطاقات OAuth المناسبة عندما يحتاج تطبيقك إلى الوظيفة.
يجب عدم طلب الوصول إلى البيانات عند مصادقة المستخدم لأول مرة، إلا إذا كان ذلك ضروريًا للوظيفة الأساسية لتطبيقك. بدلاً من ذلك، اطلب فقط النطاقات المحدّدة اللازمة لإنجاز مهمة، مع اتّباع مبدأ اختيار أصغر النطاقات وأكثرها محدودية.
يجب دائمًا طلب النطاقات في السياق لمساعدة المستخدمين على فهم سبب طلب تطبيقك للوصول إلى البيانات وكيفية استخدامها.
على سبيل المثال، قد يتبع تطبيقك النموذج التالي:
- يصادق المستخدم على هويته باستخدام تطبيقك
- لا يتم طلب أي نطاقات إضافية. يوفّر التطبيق وظائف أساسية تتيح للمستخدم
استكشاف الميزات التي لا تتطلّب أي بيانات أو أذونات إضافية واستخدامها.
- يختار المستخدم ميزة تتطلّب الوصول إلى بيانات إضافية
- يرسل تطبيقك طلب تفويض لنطاق OAuth المحدّد المطلوب لهذه الميزة. إذا كانت هذه الميزة تتطلّب نطاقات متعدّدة، اتّبِع أفضل الممارسات أدناه.
- إذا رفض المستخدم الطلب، سيوقف التطبيق الميزة ويقدّم للمستخدم سياقًا إضافيًا لطلب الإذن بالوصول مرة أخرى.
التعامل مع الموافقة على نطاقات متعددة
عند طلب نطاقات متعددة في آنٍ واحد، قد لا يمنح المستخدمون جميع نطاقات OAuth التي طلبتها. يجب أن يتعامل تطبيقك مع رفض النطاقات من خلال إيقاف الوظائف ذات الصلة.
إذا كانت الوظيفة الأساسية لتطبيقك تتطلّب نطاقات متعدّدة، عليك توضيح ذلك للمستخدم قبل طلب الموافقة.
لا يجوز أن تطلب من المستخدم الموافقة مرة أخرى إلا بعد أن يوضّح بشكل جلي نيّته استخدام الميزة المحدّدة التي تتطلّب النطاق. يجب أن يقدّم تطبيقك للمستخدم سياقًا ذا صلة
وتبريرًا قبل طلب نطاقات OAuth.
عليك تقليل عدد النطاقات التي يطلبها تطبيقك في المرة الواحدة. بدلاً من ذلك،
استخدِم المصادقة المتزايدة لطلب النطاقات
في سياق الميزات والوظائف.
استخدام متصفّحات آمنة
على الويب، يجب إجراء طلبات تفويض OAuth 2.0 فقط من متصفّحات الويب الكاملة الميزات.
على المنصات الأخرى، احرص على اختيار نوع عميل OAuth الصحيح ودمج OAuth بما يتناسب مع منصتك. يجب عدم إعادة توجيه الطلب من خلال بيئات التصفّح المضمّنة، بما في ذلك عروض الويب على المنصات المتوافقة مع الأجهزة الجوّالة، مثل WebView على Android أو WKWebView على iOS. بدلاً من ذلك، استخدِم مكتبات OAuth الأصلية
أو تسجيل الدخول باستخدام حساب Google لمنصتك.
إنشاء عملاء OAuth وإعدادهم يدويًا
لمنع إساءة الاستخدام، لا يمكن إنشاء برامج تعتمد على بروتوكول OAuth أو تعديلها آليًا. يجب استخدام "وحدة تحكّم مطوّري Google" للإقرار صراحةً ببنود الخدمة، وإعداد عميل OAuth، والاستعداد لعملية التحقّق من OAuth.
بالنسبة إلى مهام سير العمل المبرمَجة، ننصحك باستخدام حسابات الخدمة بدلاً من ذلك.
إزالة عملاء OAuth غير المستخدَمين
راجِع عملاء OAuth 2.0 بانتظام واحذف بشكل استباقي أي عملاء لم يعُد تطبيقك بحاجة إليهم أو أصبحوا قديمين. يُعدّ ترك البرامج غير المستخدَمة مضبوطة يمثّل خطرًا أمنيًا محتملاً لأنّه يمكن إساءة استخدام البرنامج إذا تم اختراق بيانات اعتمادك.
للمساعدة في الحدّ من المخاطر الناتجة عن العملاء غير المستخدَمين، يتم
تلقائيًا حذف عملاء OAuth 2.0 الذين ظلّوا غير نشطين لمدة ستة أشهر.
ننصحك بعدم انتظار الحذف التلقائي، بل إزالة العملاء غير المستخدَمين بشكل استباقي. تساهم هذه الممارسة في تقليل مساحة الهجوم في تطبيقك وتضمن
مستوى جيدًا من الأمان.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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."]]
