Halaman ini membahas beberapa praktik terbaik umum untuk berintegrasi dengan OAuth 2.0. Pertimbangkan praktik terbaik ini selain panduan khusus untuk jenis aplikasi dan platform pengembangan Anda. Lihat juga saran untuk menyiapkan aplikasi Anda untuk produksi dan kebijakan OAuth 2.0 Google.
Menangani kredensial klien dengan aman
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, meng-commitnya 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, sangat direkomendasikan untuk menggunakan Proof Key for Code Exchange (PKCE) protocol untuk mendapatkan kode otorisasi yang dapat ditukarkan dengan token akses.
Token yang dibatasi pengirim dengan DPoP
Untuk melindungi aplikasi Anda dari pencurian token dan serangan replay, pertimbangkan untuk membatasi pengirim token Anda menggunakan DPoP (Demonstrating Proof-of-Possession). Meskipun token Bearer standar dapat digunakan oleh pihak mana pun yang mencegatnya, token DPoP terikat secara kriptografis ke pasangan kunci unik yang dibuat dan dipegang oleh klien.
Saat menggunakan DPoP, klien akan memberikan bukti (Token Web JSON yang ditandatangani) ke endpoint token saat meminta atau memperbarui token. Bukti ini menunjukkan bahwa klien memiliki kunci pribadi yang sesuai dengan kunci publik yang terikat ke token. Jika token refresh yang terikat DPoP bocor, token tersebut tidak dapat diputar ulang oleh penyerang tanpa kunci pribadi tersebut.
DPoP bekerja bersama PKCE untuk memberikan perlindungan komprehensif:
- PKCE melindungi kode otorisasi selama alur pengalihan awal.
- DPoP melindungi token refresh yang berlaku lama, sehingga mencegah serangan replay jika token tersebut disusupi.
Sangat disarankan untuk menerapkan DPoP jika aplikasi Anda:
- Beroperasi sebagai klien publik (seperti aplikasi halaman tunggal atau aplikasi terinstal) yang token refresh-nya mungkin lebih rentan terhadap eksfiltrasi.
- Mengakses data yang sangat sensitif atau API bernilai tinggi, yang dampak kebocoran tokennya signifikan.
- Harus memenuhi standar kepatuhan atau keamanan ketat yang mewajibkan token yang dibatasi pengirim.
Untuk mengetahui petunjuk mendetail tentang cara membuat bukti DPoP dan meminta token terikat DPoP, lihat dokumentasi DPoP.
Menggunakan parameter status
Sebelum menangani respons OAuth 2.0, konfirmasi bahwa state yang diterima dari
Google cocok dengan state yang dikirim dalam permintaan otorisasi Anda. Parameter
state harus berupa nilai unik yang tidak dapat ditebak yang dihasilkan oleh
aplikasi Anda.
Penggunaan parameter state membantu memastikan bahwa pengguna, bukan skrip berbahaya, yang membuat permintaan dan mengurangi risiko serangan Pemalsuan Permintaan Lintas Situs (CSRF).
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 datanya. 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 spesifik 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 tersebut 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 untuk beberapa cakupan.
- 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 yang direkomendasikan 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 Cloud untuk menyetujui persyaratan layanan secara eksplisit, 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 dikonfigurasi menimbulkan potensi risiko keamanan karena klien dapat disalahgunakan jika kredensial klien Anda pernah disusupi.
Untuk lebih mengurangi 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.