פרטי הכניסה של לקוח OAuth מזהים את הזהות של האפליקציה שלכם, ולכן חשוב לטפל בהם בזהירות. אחסנו את פרטי הכניסה האלה רק באחסון מאובטח, למשל באמצעות כלי לניהול סודות כמו Google Cloud Secret Manager.
אל תקודדו את פרטי הכניסה באופן קשיח, אל תעלו אותם למאגר קוד ואל תפרסמו אותם באופן ציבורי.
טיפול מאובטח בטוקנים של משתמשים
אסימוני משתמשים כוללים גם אסימוני רענון וגם אסימוני גישה שבהם נעשה שימוש באפליקציה שלכם. אחסון אסימונים בצורה מאובטחת במנוחה, ולעולם לא להעביר אותם כטקסט פשוט. משתמשים במערכת אחסון מאובטחת שמתאימה לפלטפורמה שלכם, כמו Keystore ב-Android, Keychain Services ב-iOS וב-macOS, או Credential Locker ב-Windows.
לבטל את האסימונים ברגע שאין בהם יותר צורך ולמחוק אותם באופן סופי מהמערכות.
בנוסף, כדאי להשתמש בשיטות המומלצות הבאות בפלטפורמה שלכם:
באפליקציות בצד השרת שמאחסנות טוקנים של משתמשים רבים, צריך להצפין אותם במצב מנוחה ולוודא שמאגר הנתונים לא נגיש לציבור באינטרנט.
אם האפליקציה שלכם ביקשה אסימון רענון לגישה אופליין, אתם צריכים לטפל גם בביטול או בפקיעת התוקף שלו. יכול להיות שאסימונים יבוטלו מסיבות שונות, למשל אם תוקפם פג או שהמשתמש או תהליך אוטומטי ביטלו את הגישה של האפליקציות שלכם. במקרה כזה, חשוב לחשוב היטב איך האפליקציה צריכה להגיב, כולל הצגת בקשה למשתמש בכניסה הבאה שלו או ניקוי הנתונים שלו. כדי לקבל הודעה על ביטול טוקן, צריך לבצע שילוב עם השירות הגנה על כל החשבונות.
שימוש בהרשאה מצטברת
כדי לבקש את היקפי ההרשאות המתאימים ל-OAuth כשנדרשת פונקציונליות מסוימת באפליקציה, צריך להשתמש בהרשאה מצטברת.
לא מומלץ לבקש גישה לנתונים כשהמשתמש מאמת את עצמו בפעם הראשונה, אלא אם זה חיוני לפונקציונליות העיקרית של האפליקציה. במקום זאת, כדאי לבקש רק את היקפי ההרשאות הספציפיים שנדרשים למשימה, בהתאם לעיקרון של בחירת היקפי ההרשאות הכי קטנים והכי מוגבלים שאפשר.
תמיד צריך לבקש היקפי הרשאות בהקשר כדי לעזור למשתמשים להבין למה האפליקציה מבקשת גישה ואיך הנתונים ישמשו.
לדוגמה, האפליקציה שלכם יכולה לפעול לפי המודל הבא:
המשתמש מאומת באפליקציה שלכם
לא נדרשים היקפי הרשאות נוספים. האפליקציה מספקת פונקציונליות בסיסית שמאפשרת למשתמש לחקור ולהשתמש בתכונות שלא דורשות נתונים נוספים או גישה נוספת.
המשתמש בוחר תכונה שנדרשת גישה לנתונים נוספים
האפליקציה שולחת בקשת הרשאה להיקף ה-OAuth הספציפי הזה שנדרש לתכונה הזו. אם התכונה הזו דורשת כמה היקפי הרשאה, כדאי לפעול לפי השיטות המומלצות שבהמשך.
אם המשתמש ידחה את הבקשה, האפליקציה תשבית את התכונה ותספק למשתמש הקשר נוסף כדי לבקש גישה שוב.
איך מטפלים בהסכמה למספר היקפי גישה
כשמבקשים כמה היקפים בבת אחת, יכול להיות שהמשתמשים לא יאשרו את כל היקפי ה-OAuth שביקשתם. האפליקציה צריכה לטפל בדחייה של היקפי הרשאות על ידי השבתה של פונקציונליות רלוונטית.
אם הפונקציונליות הבסיסית של האפליקציה דורשת כמה היקפי הרשאות, צריך להסביר זאת למשתמש לפני שמבקשים ממנו להביע הסכמה.
אפשר להציג למשתמש את ההנחיה שוב רק אחרי שהוא מציין באופן ברור כוונה להשתמש בתכונה הספציפית שדורשת את ההיקף. האפליקציה צריכה לספק למשתמש הקשר רלוונטי והצדקה לפני בקשת היקפי OAuth.
מומלץ לצמצם את מספר ההיקפים שהאפליקציה מבקשת בבת אחת. במקום זאת,
משתמשים בהרשאה מצטברת כדי לבקש היקפי גישה
בהקשר של תכונות ופונקציונליות.
שימוש בדפדפנים מאובטחים
באינטרנט, בקשות הרשאה של OAuth 2.0 חייבות להישלח רק מדפדפני אינטרנט עם תכונות מלאות.
בפלטפורמות אחרות, חשוב לבחור את סוג לקוח ה-OAuth הנכון ולשלב את OAuth בהתאם לפלטפורמה. אל תפנו את הבקשה דרך סביבות גלישה מוטמעות, כולל תצוגות אינטרנט בפלטפורמות לנייד, כמו WebView ב-Android או WKWebView ב-iOS. במקום זאת, צריך להשתמש בספריות OAuth מקוריות או בכניסה באמצעות חשבון Google בפלטפורמה.
יצירה והגדרה ידניות של לקוחות OAuth
כדי למנוע שימוש לרעה, אי אפשר ליצור או לשנות לקוחות OAuth באופן אוטומטי. אתם צריכים להשתמש במסוף Google Developers כדי לאשר באופן מפורש את התנאים וההגבלות, להגדיר את לקוח OAuth ולהתכונן לאימות OAuth.
לזרימות עבודה אוטומטיות, כדאי להשתמש במקום זאת בחשבונות שירות.
הסרה של לקוחות OAuth שלא בשימוש
מומלץ לבצע ביקורת באופן קבוע על לקוחות OAuth 2.0 ולמחוק באופן יזום לקוחות שכבר לא נדרשים על ידי האפליקציה או שהפכו ללא רלוונטיים. השארת לקוחות לא בשימוש מוגדרים מייצגת סיכון אבטחה פוטנציאלי, כי יכול להיות שייעשה שימוש לרעה בלקוח אם פרטי הכניסה של הלקוח ייפגעו.
כדי לצמצם עוד יותר את הסיכונים מלקוחות לא פעילים, לקוחות OAuth 2.0 שלא היו פעילים במשך שישה חודשים
נמחקים אוטומטית.
השיטה המומלצת היא לא לחכות למחיקה אוטומטית, אלא להסיר באופן יזום לקוחות שלא נמצאים בשימוש. השיטה הזו מצמצמת את שטח הפנים של האפליקציה להתקפה ומבטיחה
שמירה על היגיינת אבטחה טובה.
[[["התוכן קל להבנה","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-08-31 (שעון UTC)."],[[["\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."]]
