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

Come condividere i client OAuth

Questa pagina spiega come condividere un client OAuth con un'altra applicazione all'interno della tua organizzazione.

Panoramica

La condivisione dei client OAuth tra i progetti significa utilizzare un singolo client OAuth personalizzato per più applicazioni protette da Identity-Aware Proxy (IAP) anziché creare un nuovo client OAuth per ogni applicazione. Questo approccio semplifica la gestione, soprattutto per le organizzazioni con molte applicazioni.

Quando configuri IAP, puoi utilizzare uno dei due tipi di client OAuth:

Client OAuth gestito da Google: IAP lo utilizza automaticamente per impostazione predefinita. Questa opzione integrata non richiede la creazione manuale del client, ma presenta due limitazioni principali:
- Consente l'accesso solo agli utenti all'interno della tua organizzazione (utenti interni)
- Visualizzail Google Cloud branding nella schermata per il consenso anziché il branding della tua organizzazione
Client OAuth personalizzato: lo crei e lo gestisci tu. Questa opzione:
- Può essere condivisa tra più applicazioni
- Consente di personalizzare il branding nella schermata per il consenso
- Supporta l'accesso per gli utenti esterni (al di fuori della tua organizzazione)

Quando crei un client OAuth personalizzato, hai la flessibilità di utilizzarlo con una singola applicazione o di condividerlo tra più applicazioni. La condivisione di un client OAuth personalizzato offre diversi vantaggi:

Riduce il sovraccarico amministrativo della gestione di più client
Semplifica l'abilitazione di IAP per i membri del team che non devono avere accesso alla pagina Credenziali
Facilita l'accesso programmatico (non tramite browser) alle applicazioni protette da IAP

Per informazioni sulla creazione di client OAuth, consulta Creare client OAuth per IAP. Per i dettagli sui client OAuth gestiti da Google, consulta Personalizzare una configurazione OAuth per abilitare IAP.

Prima di iniziare

Crea un nuovo client OAuth completando i passaggi descritti in Creazione di client OAuth o utilizza un client OAuth esistente.

Accesso programmatico

Configura i client OAuth per l'accesso programmatico per consentire alle applicazioni non basate su browser di eseguire l'autenticazione con le risorse protette da IAP. In questo modo, gli script, i job automatici e i servizi di backend possono accedere in modo sicuro alle applicazioni protette senza che gli utenti debbano accedere in modo interattivo.

Puoi applicare queste impostazioni di autenticazione a qualsiasi livello della gerarchia delle risorse: organizzazione, cartella, o progetto.

Per i passaggi di implementazione, consulta la guida all'autenticazione programmatica e la documentazione sulla gestione delle impostazioni di IAP.

gcloud

Prepara un file di impostazioni con gli ID client OAuth:

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

Applica le impostazioni utilizzando il gcloud iap settings set comando:

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

Comandi di esempio:

# 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

Dove:

SETTINGS_FILENAME: il file YAML che hai preparato.
ORGANIZATION: l'ID organizzazione
FOLDER: l'ID cartella
PROJECT: l'ID progetto
RESOURCE_TYPE: il tipo di risorsa IAP (app-engine, iap_web, compute, organization o folder)
SERVICE: il nome del servizio (facoltativo per compute o app-engine tipi di risorse)
VERSION: il nome della versione (non applicabile per compute, facoltativo per app-engine)

API

Prepara un file JSON di impostazioni:

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

Recupera il nome della risorsa:

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

Aggiorna le impostazioni utilizzando il nome della risorsa:
```
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"
```
Dove:
- ORGANIZATION: l'ID organizzazione
- FOLDER: l'ID cartella
- PROJECT: l'ID progetto
- RESOURCE_TYPE: il tipo di risorsa IAP (app-engine, iap_web, compute, organization o folder)
- SERVICE: il nome del servizio (facoltativo per compute o app-engine tipi di risorse)
- VERSION: il nome della versione (non applicabile per compute, facoltativo per app-engine)

Dopo la configurazione, accedi all'applicazione utilizzando uno degli ID client OAuth configurati. Per i dettagli, consulta Autenticazione programmatica.

Accesso al browser

Per consentire a IAP di utilizzare l'ID client e il client secret tramite la Google Cloud console, completa le seguenti istruzioni:

Rischi

Sebbene la condivisione di un client tra le applicazioni sia comoda, comporta dei rischi. Questa sezione illustra i potenziali rischi della condivisione dei client e come mitigarli.

Single point of failure

L'utilizzo di un client OAuth per molte applicazioni crea un singolo punto di dipendenza. Se un client viene eliminato o modificato in modo errato, tutte le applicazioni che lo utilizzano ne risentono. I client OAuth eliminati possono essere ripristinati entro 30 giorni.

Per gestire efficacemente questo rischio operativo:

Implementa controlli dell'accesso appropriati per impedire modifiche o eliminazioni accidentali
Limita l'accesso ai client OAuth utilizzando clientauthconfig.clients.* autorizzazioni
Utilizza gli Google Cloud audit log per monitorare le attività amministrative che coinvolgono i client OAuth

Si tratta principalmente di un rischio operativo anziché di un rischio per la sicurezza. Con controlli dell'accesso e monitoraggio appropriati, i vantaggi di praticità e gestione dei client OAuth condivisi in genere superano questa considerazione.

Perdita del client secret

La condivisione di un client richiede la condivisione del client secret con persone e script. Ciò aumenta il rischio di perdita del client secret. IAP non è in grado di distinguere tra i token creati dalla tua applicazione e i token creati da un client secret perso.

Per mitigare questo rischio:

Proteggi i client secret come le password e non memorizzarli mai come testo non crittografato
Implementa la gestione sicura delle credenziali utilizzando Secret Manager
Monitora l'accesso alle risorse IAP con l'audit logging di Cloud
Un client secret perso influisce solo sull'autenticazione, non sull'autorizzazione ad accedere alle risorse. Se sospetti che il tuo secret sia stato perso, reimpostalo immediatamente.

Per l'accesso programmatico alle risorse protette da IAP, valuta la possibilità di utilizzare l'autenticazione JWT dell'account di servizio anziché condividere i client secret OAuth con i singoli utenti. Questo approccio offre un migliore isolamento della sicurezza, mantenendo al contempo i vantaggi di un client OAuth condiviso per le tue applicazioni.

Considerazioni sull'ambito delle autorizzazioni

Quando condividi i client OAuth, tutte le applicazioni utilizzano gli stessi ambiti delle autorizzazioni. Per IAP, openid ed email sono gli unici ambiti obbligatori. Questa considerazione di per sé non rappresenta un rischio significativo, ma è importante capire:

OAuth viene utilizzato solo per l'autenticazione (verifica dell'identità) in IAP; l'autorizzazione (accesso alle risorse) viene gestita separatamente tramite le policy IAM
Anche se le credenziali di autenticazione sono compromesse, un utente malintenzionato avrebbe comunque bisogno delle autorizzazioni IAM appropriate per accedere alle risorse protette
Limitare il client solo agli ambiti openid ed email richiesti contribuisce a limitare il potenziale impatto sulla sicurezza

Come condividere i client OAuth Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.