İstemci kimlik bilgilerini güvenli bir şekilde işleme
OAuth istemci kimlik bilgileri, uygulamanızın kimliğini tanımlar ve dikkatli bir şekilde kullanılmalıdır. Bu kimlik bilgilerini yalnızca güvenli depolama alanında saklayın. Örneğin, Google Cloud Secret Manager gibi bir Secret Manager kullanın.
Kimlik bilgilerini sabit kodlamayın, bir kod deposuna işlemeyin veya herkese açık olarak yayınlamayın.
Kullanıcı jetonlarını güvenli bir şekilde işleme
Kullanıcı jetonları, uygulamanız tarafından kullanılan hem yenileme jetonlarını hem de erişim jetonlarını içerir. Jetonları dinlenirken güvenli bir şekilde saklayın ve hiçbir zaman düz metin olarak iletmeyin. Platformunuza uygun güvenli bir depolama sistemi kullanın. Örneğin, Android'de Keystore, iOS ve macOS'te Keychain Services veya Windows'da Credential Locker.
Artık ihtiyaç duyulmayan jetonları iptal edin ve sistemlerinizden kalıcı olarak silin.
Ayrıca platformunuz için aşağıdaki en iyi uygulamaları da göz önünde bulundurun:
Birçok kullanıcının jetonlarını depolayan sunucu tarafı uygulamaları için jetonları dinlenme sırasında şifreleyin ve veri deponuzun internete herkese açık olarak erişilebilir olmadığından emin olun.
Yenileme jetonu iptalini ve geçerlilik bitişini işleme
Uygulamanız çevrimdışı erişim için yenileme jetonu istiyorsa bu jetonların geçersiz kılınmasını veya süresinin dolmasını da yönetmeniz gerekir. Jetonlar, farklı nedenlerle geçersiz kılınabilir. Örneğin, jetonun süresi dolmuş olabilir veya uygulamalarınızın erişimi kullanıcı ya da otomatik bir süreç tarafından iptal edilmiş olabilir. Bu durumda, uygulamanızın nasıl yanıt vermesi gerektiğini dikkatlice düşünün. Örneğin, kullanıcının bir sonraki girişinde istemde bulunabilir veya verilerini temizleyebilirsiniz. Jeton iptali hakkında bildirim almak için Hesaplar Arası Koruma hizmetiyle entegrasyon yapın.
Artımlı yetkilendirme kullanma
Uygulamanızın işlevselliğe ihtiyacı olduğunda uygun OAuth kapsamlarını istemek için artımlı yetkilendirme kullanın.
Uygulamanızın temel işlevi için gerekli olmadığı sürece, kullanıcı ilk kez kimlik doğrulaması yaptığında verilere erişim isteğinde bulunmamalısınız. Bunun yerine, mümkün olan en küçük ve en sınırlı kapsamları seçme ilkesine uyarak yalnızca bir görev için gereken belirli kapsamları isteyin.
Kullanıcılarınızın uygulamanızın neden erişim istediğini ve verilerin nasıl kullanılacağını anlamalarına yardımcı olmak için kapsamları her zaman bağlam içinde isteyin.
Örneğin, uygulamanız şu modeli izleyebilir:
Kullanıcı, uygulamanızla kimliğini doğrular.
Başka kapsam istenmiyor. Uygulama, kullanıcının ek veri veya erişim gerektirmeyen özellikleri keşfetmesine ve kullanmasına olanak tanıyan temel işlevler sunuyor.
Kullanıcı, ek verilere erişim gerektiren bir özellik seçer.
Uygulamanız, bu özellik için gerekli olan bu belirli OAuth kapsamı için yetkilendirme isteğinde bulunuyor. Bu özellik birden fazla kapsam gerektiriyorsa aşağıdaki en iyi uygulamaları uygulayın.
Kullanıcı isteği reddederse uygulama özelliği devre dışı bırakır ve kullanıcıya tekrar erişim isteğinde bulunması için ek bağlam bilgisi verir.
Birden fazla kapsam için izni işleme
Kullanıcılar, tek seferde birden fazla kapsam isteğinde bulunurken istediğiniz tüm OAuth kapsamlarını vermeyebilir. Uygulamanız, ilgili işlevleri devre dışı bırakarak kapsamların reddedilmesini ele almalıdır.
Uygulamanızın temel işlevleri için birden fazla kapsam gerekiyorsa izin istemeden önce bunu kullanıcıya açıklayın.
Kullanıcı, kapsam gerektiren belirli bir özelliği kullanma niyetini açıkça belirttikten sonra kullanıcıya tekrar istemde bulunabilirsiniz. Uygulamanız, OAuth kapsamları istemeden önce kullanıcıya alakalı bağlam ve gerekçe sağlamalıdır.
Uygulamanızın aynı anda istediği kapsam sayısını en aza indirmeniz gerekir. Bunun yerine, artımlı yetkilendirmeyi kullanarak özellikler ve işlevler bağlamında kapsam isteyin.
Güvenli tarayıcılar kullanın
Web'de, OAuth 2.0 yetkilendirme istekleri yalnızca tam özellikli web tarayıcılarından yapılmalıdır.
Diğer platformlarda doğru OAuth istemci türünü seçtiğinizden ve OAuth'u platformunuza uygun şekilde entegre ettiğinizden emin olun. İsteği, Android'deki WebView veya iOS'teki WKWebView gibi mobil platformlardaki WebView'lar da dahil olmak üzere yerleştirilmiş tarama ortamları üzerinden yönlendirmeyin. Bunun yerine, platformunuz için yerel OAuth kitaplıklarını veya Google ile oturum açma'yı kullanın.
OAuth istemcilerinin manuel olarak oluşturulması ve yapılandırılması
Kötüye kullanımı önlemek için OAuth istemcileri programatik olarak oluşturulamaz veya değiştirilemez. Hizmet şartlarını açıkça kabul etmek, OAuth istemcinizi yapılandırmak ve OAuth doğrulamasına hazırlanmak için Google Developers Console'u kullanmanız gerekir.
Otomatik iş akışları için bunun yerine hizmet hesaplarını kullanabilirsiniz.
Kullanılmayan OAuth istemcilerini kaldırma
OAuth 2.0 istemcilerinizi düzenli olarak denetleyin ve uygulamanızın artık ihtiyaç duymadığı veya eskimiş olanları proaktif bir şekilde silin. Kullanılmayan istemcilerin yapılandırılmış olarak bırakılması, istemci kimlik bilgilerinizin güvenliği ihlal edilirse istemcinin kötüye kullanılabileceği için olası bir güvenlik riski oluşturur.
Kullanılmayan istemcilerden kaynaklanan riskleri daha da azaltmak için altı aydır etkin olmayan OAuth 2.0 istemcileri
otomatik olarak silinir.
Önerilen en iyi uygulama, otomatik silme işlemini beklemek yerine kullanılmayan istemcileri proaktif olarak kaldırmaktır. Bu uygulama, uygulamanızın saldırı yüzeyini en aza indirir ve iyi bir güvenlik hijyeni sağlar.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
