Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Cara membagikan klien OAuth

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

Ringkasan

Berbagi klien OAuth antar-project berarti menggunakan satu klien OAuth kustom untuk beberapa aplikasi yang dilindungi Identity-Aware Proxy (IAP) daripada 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 menggunakan klien ini 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 di layar izin, bukan branding organisasi Anda Google Cloud
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 ke beberapa aplikasi. Membagikan klien OAuth kustom memberikan beberapa manfaat:

Mengurangi overhead administratif dalam 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 mengetahui 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

Konfigurasi klien OAuth untuk akses terprogram agar aplikasi non-browser dapat melakukan autentikasi dengan resource yang dilindungi IAP Anda. Hal ini memungkinkan skrip, tugas otomatis, dan layanan backend untuk mengakses aplikasi yang dilindungi secara aman tanpa login pengguna interaktif.

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

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

gcloud

Siapkan file setelan dengan client ID OAuth Anda:

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

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:

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

Siapkan file JSON setelan:

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

Dapatkan nama resource:

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

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

Untuk mengaktifkan IAP agar menggunakan ID klien dan rahasia Anda melalui konsolGoogle Cloud , selesaikan petunjuk berikut:

Risiko

Meskipun berbagi klien antar-aplikasi Anda terasa praktis, ada risiko yang perlu dipertimbangkan. Bagian ini menguraikan potensi risiko saat membagikan klien dan cara menguranginya.

Titik tunggal kegagalan

Menggunakan satu klien OAuth untuk banyak aplikasi akan menciptakan satu titik dependensi. Jika klien dihapus atau diubah dengan 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:

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

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

Kebocoran rahasia klien

Membagikan klien memerlukan pembagian rahasia klien Anda kepada orang dan skrip. Tindakan ini meningkatkan risiko kebocoran rahasia klien Anda. IAP tidak dapat membedakan antara token yang dibuat dari aplikasi Anda dan token yang dibuat dari rahasia klien yang bocor.

Untuk mengurangi risiko ini:

Lindungi rahasia klien seperti sandi dan jangan pernah menyimpannya sebagai teks biasa
Terapkan pengelolaan kredensial yang aman menggunakan Secret Manager
Pantau akses ke resource IAP Anda dengan Cloud Audit Logging
Rahasia klien yang bocor hanya memengaruhi autentikasi, bukan otorisasi untuk mengakses resource. Jika Anda mencurigai bahwa rahasia Anda bocor, segera reset rahasia Anda.

Untuk akses terprogram ke resource yang dilindungi IAP, pertimbangkan untuk menggunakan autentikasi JWT akun layanan, bukan membagikan rahasia 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 membagikan 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 dipahami:

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

Cara membagikan klien OAuth Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.