Cara membagikan klien OAuth

Halaman ini menjelaskan cara membagikan klien OAuth dengan aplikasi lain dalam organisasi Anda.

Ringkasan

Membagikan klien OAuth antar-project berarti menggunakan satu klien OAuth kustom untuk beberapa aplikasi yang dilindungi Identity-Aware Proxy (IAP) bukan membuat klien OAuth baru untuk setiap aplikasi. Pendekatan ini menyederhanakan pengelolaan, terutama untuk organisasi dengan banyak aplikasi.

Saat mengonfigurasi IAP, Anda dapat menggunakan salah satu dari dua jenis klien OAuth:

  • Klien OAuth yang dikelola Google: IAP otomatis menggunakannya secara default. Opsi bawaan ini tidak memerlukan pembuatan klien manual, tetapi memiliki dua batasan utama:

    • Hanya mengizinkan akses ke pengguna dalam organisasi Anda (pengguna internal)
    • Menampilkan branding Google Cloud di layar izin, bukan branding organisasi Anda

  • Klien OAuth kustom: Anda membuat dan mengelolanya sendiri. Opsi ini:

    • Dapat dibagikan di beberapa aplikasi
    • Mengizinkan penyesuaian branding di layar izin
    • Mendukung akses untuk pengguna eksternal (di luar organisasi Anda)

Saat membuat klien OAuth kustom, Anda memiliki fleksibilitas untuk menggunakannya dengan satu aplikasi atau membagikannya di beberapa aplikasi. Membagikan klien OAuth kustom memberikan beberapa manfaat:

  • Mengurangi overhead administratif untuk mengelola beberapa klien
  • Menyederhanakan pengaktifan IAP untuk anggota tim yang tidak boleh memiliki akses ke halaman Kredensial
  • Memfasilitasi akses terprogram (non-browser) ke aplikasi yang dilindungi oleh IAP

Untuk informasi tentang cara membuat klien OAuth, lihat Membuat klien OAuth untuk IAP. Untuk mengetahui detail tentang klien OAuth yang dikelola Google, lihat Menyesuaikan konfigurasi OAuth untuk mengaktifkan IAP.

Sebelum memulai

Buat klien OAuth baru dengan menyelesaikan langkah-langkah di Pembuatan klien OAuth atau gunakan klien OAuth yang ada.

Akses terprogram

Konfigurasikan klien OAuth untuk akses terprogram guna mengizinkan aplikasi non-browser mengautentikasi dengan resource yang dilindungi IAP. Hal ini memungkinkan skrip, tugas otomatis, dan layanan backend untuk mengakses aplikasi Anda yang dilindungi dengan aman tanpa login pengguna interaktif.

Anda dapat menerapkan setelan autentikasi ini di level mana pun dalam hierarki resource: organisasi, folder, atau project.

Untuk mengetahui langkah-langkah penerapan, lihat dokumentasi panduan autentikasi terprogram dan pengelolaan setelan IAP.

gcloud

  1. Siapkan file setelan dengan client ID OAuth Anda:

    cat << EOF > SETTINGS_FILENAME
  access_settings:
    oauth_settings:
      programmatic_clients: [clientId1, clientId2, ..]
EOF

  2. Terapkan setelan menggunakan perintah gcloud iap settings set:

    gcloud iap settings set SETTINGS_FILENAME \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

    Contoh perintah:

    # Organization level
gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION

# Folder level
gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER

# Project level (web resources)
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=iap_web

# App Engine service in a project
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=app-engine \
  --service=SERVICE

    Dengan keterangan:

    • SETTINGS_FILENAME: File YAML yang Anda siapkan.
    • ORGANIZATION: ID organisasi
    • FOLDER: ID folder
    • PROJECT: ID project
    • RESOURCE_TYPE: Jenis resource IAP (app-engine, iap_web, compute, organization, atau folder)
    • SERVICE: Nama layanan (opsional untuk jenis resource compute atau app-engine)
    • VERSION: Nama versi (tidak berlaku untuk compute, opsional untuk app-engine)

API

  1. Siapkan file JSON setelan:

    cat << EOF > iap_settings.json
{
  "access_settings": {
    "oauth_settings": {
      programmatic_clients: [clientId1, clientId2, ..]
    }
  }
}
EOF

  2. Dapatkan nama resource:

    gcloud iap settings get \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

  3. Perbarui setelan menggunakan nama resource:

    curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"

    Dengan keterangan:

    • ORGANIZATION: ID organisasi
    • FOLDER: ID folder
    • PROJECT: ID project
    • RESOURCE_TYPE: Jenis resource IAP (app-engine, iap_web, compute, organization, atau folder)
    • SERVICE: Nama layanan (opsional untuk jenis resource compute atau app-engine)
    • VERSION: Nama versi (tidak berlaku untuk compute, opsional untuk app-engine)

Setelah konfigurasi, login ke aplikasi menggunakan salah satu ID klien OAuth yang Anda konfigurasi. Lihat Autentikasi terprogram untuk mengetahui detailnya.

Akses browser

Agar IAP dapat menggunakan client ID dan secret Anda melalui konsolGoogle Cloud , selesaikan petunjuk berikut:

Risiko

Meskipun berbagi klien antar-aplikasi Anda praktis, ada risikonya. Bagian ini menguraikan potensi risiko saat berbagi klien dan cara menguranginya.

Titik tunggal kegagalan

Menggunakan satu klien OAuth untuk banyak aplikasi akan membuat satu titik dependensi. Jika klien dihapus atau diubah secara tidak benar, setiap aplikasi yang menggunakan klien tersebut akan terpengaruh. Klien OAuth yang dihapus dapat dipulihkan dalam waktu 30 hari.

Untuk mengelola risiko operasional ini secara efektif:

  • Terapkan kontrol akses yang tepat untuk mencegah perubahan atau penghapusan yang tidak disengaja
  • Membatasi akses ke klien OAuth menggunakan izin clientauthconfig.clients.*
  • Gunakan Google Cloud Audit Logs untuk melacak aktivitas administratif yang melibatkan klien OAuth

Hal ini terutama merupakan risiko operasional, bukan risiko keamanan. Dengan kontrol dan pemantauan akses yang tepat, manfaat pengelolaan dan kemudahan klien OAuth bersama biasanya lebih besar daripada pertimbangan ini.

Kebocoran rahasia klien

Untuk membagikan klien, Anda harus membagikan secret klien kepada orang dan skrip. Hal ini meningkatkan risiko kebocoran secret klien Anda. IAP tidak dapat membedakan antara token yang dibuat dari aplikasi Anda dan token yang dibuat dari secret klien yang bocor.

Untuk mengurangi risiko ini:

  • Melindungi secret klien seperti sandi dan tidak pernah menyimpannya sebagai teks biasa
  • Mengimplementasikan pengelolaan kredensial yang aman menggunakan Secret Manager
  • Memantau akses ke resource IAP Anda dengan Cloud Audit Logging
  • Rahasia klien yang bocor hanya memengaruhi autentikasi, bukan otorisasi untuk mengakses resource. Jika Anda mencurigai secret Anda bocor, segera reset secret tersebut.

Untuk akses terprogram ke resource yang dilindungi IAP, sebaiknya gunakan autentikasi JWT akun layanan, bukan membagikan secret klien OAuth kepada pengguna perorangan. Pendekatan ini memberikan isolasi keamanan yang lebih baik sekaligus mempertahankan manfaat klien OAuth bersama untuk aplikasi Anda.

Pertimbangan cakupan izin

Saat berbagi klien OAuth, semua aplikasi menggunakan cakupan izin yang sama. Untuk IAP, openid dan email adalah satu-satunya cakupan yang diperlukan. Pertimbangan ini sendiri bukanlah risiko yang signifikan, tetapi penting untuk memahami:

  • OAuth hanya digunakan untuk autentikasi (memverifikasi identitas) di IAP; otorisasi (akses resource) ditangani secara terpisah melalui kebijakan IAM
  • Meskipun kredensial autentikasi disusupi, penyerang masih memerlukan izin IAM yang sesuai untuk mengakses resource yang dilindungi
  • Membatasi klien hanya ke cakupan openid dan email yang diperlukan membantu membatasi potensi dampak keamanan