Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Cara membagikan klien OAuth

Halaman ini menjelaskan cara membagikan klien OAuth kepada 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), bukan membuat klien OAuth baru untuk setiap aplikasi. Pendekatan ini menyederhanakan pengelolaan, terutama bagi 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 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 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 seharusnya memiliki akses ke halaman Credentials
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

Konfigurasikan klien OAuth untuk akses terprogram agar aplikasi non-browser dapat melakukan autentikasi dengan resource yang dilindungi IAP. Hal ini memungkinkan skrip, tugas otomatis, dan layanan backend mengakses aplikasi 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 penerapannya, 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: Project ID
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: Project ID
- 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 client ID OAuth yang Anda konfigurasi. Lihat Autentikasi terprogram untuk mengetahui detailnya.

Akses browser

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

Risiko

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

Titik tunggal kegagalan

Menggunakan satu klien OAuth untuk banyak aplikasi akan menciptakan 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:

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 kontrol akses dan pemantauan yang tepat, manfaat kemudahan dan pengelolaan klien OAuth bersama biasanya lebih besar daripada pertimbangan ini.

Kebocoran rahasia klien

Berbagi klien memerlukan berbagi rahasia klien Anda dengan orang dan skrip. Hal 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
Menerapkan pengelolaan kredensial keamanan 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 rahasia Anda bocor, segera reset.

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 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 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 akan membantu membatasi potensi dampak keamanan

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