Praktik Terbaik

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, 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:

1. Pengguna melakukan autentikasi dengan aplikasi Anda
   1. Tidak ada cakupan tambahan yang diminta. Aplikasi menyediakan fungsi dasar untuk memungkinkan pengguna menjelajahi dan menggunakan fitur yang tidak memerlukan data atau akses tambahan.
2. Pengguna memilih fitur yang memerlukan akses ke data tambahan
   1. 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.
   2. 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.