Kredensial klien OAuth mengidentifikasi identitas aplikasi Anda dan harus ditangani dengan hati-hati. Hanya
simpan kredensial ini di penyimpanan yang aman, misalnya menggunakan pengelola secret seperti
Google Cloud Secret Manager.
Jangan meng-hardcode kredensial, melakukan commit ke repositori kode, atau memublikasikannya.
Menangani token pengguna dengan aman
Token pengguna mencakup token refresh dan token akses yang digunakan oleh aplikasi Anda. Simpan token dengan aman saat tidak digunakan dan jangan pernah mengirimkannya dalam teks biasa. Gunakan sistem penyimpanan aman yang sesuai untuk platform Anda, seperti
Keystore di Android,
Keychain Services di iOS dan macOS, atau Credential Locker di Windows.
Cabut token segera setelah
tidak diperlukan lagi dan hapus secara permanen dari sistem Anda.
Selain itu, pertimbangkan juga praktik terbaik berikut untuk platform Anda:
Untuk aplikasi sisi server yang menyimpan
token untuk banyak pengguna, enkripsi token saat tidak digunakan dan pastikan penyimpanan data Anda tidak dapat diakses secara publik di Internet.
Untuk aplikasi desktop native, penggunaan
Proof Key for Code
Exchange (PKCE) protocol sangat direkomendasikan untuk mendapatkan kode otorisasi yang dapat
ditukarkan dengan token akses.
Menangani pencabutan dan masa berlaku token refresh
Jika aplikasi Anda telah meminta token
refresh untuk akses offline, Anda juga harus menangani pembatalan atau masa berlakunya. Token
dapat dibatalkan karena berbagai alasan,
misalnya, token mungkin telah habis masa berlakunya atau akses aplikasi Anda mungkin telah dicabut oleh pengguna atau
proses otomatis. Dalam hal ini, pertimbangkan dengan cermat cara aplikasi Anda harus merespons,
termasuk meminta pengguna untuk login lagi atau membersihkan data mereka. Untuk mendapatkan notifikasi tentang
pencabutan token, integrasikan dengan layanan Perlindungan
Lintas Akun.
Menggunakan otorisasi inkremental
Gunakan otorisasi
inkremental untuk meminta cakupan OAuth yang sesuai saat fungsi diperlukan oleh
aplikasi Anda.
Anda tidak boleh meminta akses ke data saat pengguna pertama kali melakukan autentikasi, kecuali jika hal tersebut penting
untuk fungsi inti aplikasi Anda. Sebagai gantinya, minta hanya cakupan tertentu yang
diperlukan untuk suatu tugas, dengan mengikuti prinsip untuk
memilih cakupan terkecil dan paling terbatas yang memungkinkan.
Selalu minta cakupan sesuai konteks untuk membantu pengguna Anda memahami alasan aplikasi Anda meminta akses
dan cara data akan digunakan.
Misalnya, aplikasi Anda dapat mengikuti model ini:
Pengguna melakukan autentikasi dengan aplikasi Anda
Tidak ada cakupan tambahan yang diminta. Aplikasi menyediakan fungsi dasar untuk memungkinkan pengguna
menjelajahi dan menggunakan fitur yang tidak memerlukan data atau akses tambahan.
Pengguna memilih fitur yang memerlukan akses ke data tambahan
Aplikasi Anda membuat permintaan otorisasi untuk cakupan OAuth spesifik yang diperlukan
untuk fitur ini. Jika fitur ini memerlukan beberapa cakupan, ikuti
praktik terbaik di bawah.
Jika pengguna menolak permintaan, aplikasi akan menonaktifkan fitur dan memberikan
konteks tambahan kepada pengguna untuk meminta akses lagi.
Menangani izin untuk beberapa cakupan
Saat meminta beberapa cakupan sekaligus, pengguna mungkin tidak memberikan semua cakupan OAuth yang telah Anda minta. Aplikasi Anda harus menangani penolakan cakupan dengan menonaktifkan fungsi yang relevan.
Jika fungsi dasar aplikasi Anda memerlukan beberapa cakupan, jelaskan hal ini kepada pengguna sebelum
meminta izin.
Anda hanya dapat meminta pengguna lagi setelah mereka dengan jelas menunjukkan niat untuk menggunakan
fitur tertentu yang memerlukan cakupan. Aplikasi Anda harus memberikan konteks dan justifikasi yang relevan kepada pengguna sebelum meminta cakupan OAuth.
Anda harus meminimalkan jumlah cakupan yang diminta aplikasi Anda sekaligus. Sebagai gantinya,
gunakan otorisasi inkremental untuk meminta cakupan
dalam konteks fitur dan fungsi.
Menggunakan browser yang aman
Di web, permintaan otorisasi OAuth 2.0 hanya boleh dilakukan dari browser web berfitur lengkap.
Di platform lain, pastikan untuk memilih
jenis klien OAuth yang benar dan mengintegrasikan
OAuth sebagaimana mestinya untuk platform Anda. Jangan mengalihkan permintaan melalui lingkungan penjelajahan yang disematkan, termasuk WebView di platform seluler, seperti WebView di Android atau WKWebView di iOS. Sebagai gantinya, gunakan library OAuth native
atau Login dengan Google untuk platform Anda.
Pembuatan dan konfigurasi klien OAuth secara manual
Untuk mencegah penyalahgunaan, klien OAuth tidak dapat dibuat atau diubah secara terprogram. Anda
harus menggunakan konsol Google Developer untuk secara eksplisit menyetujui persyaratan layanan, mengonfigurasi
klien OAuth, dan bersiap untuk verifikasi OAuth.
Untuk alur kerja otomatis, sebaiknya gunakan
akun layanan.
Menghapus klien OAuth yang tidak digunakan
Audit klien OAuth 2.0 Anda secara rutin dan hapus secara proaktif klien yang tidak lagi diperlukan oleh
aplikasi Anda atau sudah tidak berlaku. Membiarkan klien yang tidak digunakan tetap dikonfigurasi merupakan
potensi risiko keamanan karena klien dapat disalahgunakan jika kredensial klien Anda pernah
disusupi.
Untuk lebih meminimalkan risiko dari klien yang tidak digunakan, klien OAuth 2.0 yang tidak aktif selama enam
bulan akan
dihapus secara otomatis.
Praktik terbaik yang direkomendasikan adalah tidak menunggu penghapusan otomatis, tetapi secara proaktif
menghapus klien yang tidak digunakan. Praktik ini meminimalkan permukaan serangan aplikasi Anda dan memastikan
praktik keamanan yang baik.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
