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 progetti significa utilizzare un unico 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 l'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)
    • Nella schermata per il consenso viene visualizzato il Google Cloud branding dell'app anziché quello della tua organizzazione

  • Client OAuth personalizzato: lo crei e lo gestisci autonomamente. Questa opzione:

    • Può essere condiviso tra più applicazioni
    • Consente la personalizzazione del branding nella schermata del consenso
    • Supporta l'accesso per gli utenti esterni (all'esterno dell'organizzazione)

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

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

Per informazioni sulla creazione di client OAuth, consulta Creare client OAuth per gli acquisti in-app. Per informazioni dettagliate sui client OAuth gestiti da Google, consulta Personalizzare una configurazione OAuth per abilitare gli acquisti in-app.

Prima di iniziare

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

Accesso programmatico

Configura i client OAuth per l'accesso programmatico per consentire alle applicazioni non browser di autenticarsi con le risorse protette da IAP. In questo modo, script, job automatici e servizi di backend possono accedere in sicurezza alle tue applicazioni protette senza l'accesso interattivo degli utenti.

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

Per la procedura di implementazione, consulta la guida all'autenticazione programmatica e la documentazione relativa alla gestione delle impostazioni dell'IAP.

gcloud

  1. Prepara un file di impostazioni con i tuoi ID client OAuth:

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

  2. Applica le impostazioni utilizzando il comando gcloud iap settings set:

    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 i tipi di risorse compute o app-engine)
    • VERSION: il nome della versione (non applicabile per compute, facoltativo per app-engine)

API

  1. Prepara un file JSON delle impostazioni:

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

  2. Recupera il nome della risorsa:

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

  3. 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 i tipi di risorse compute o app-engine)
    • 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 maggiori dettagli, consulta Autenticazione programmatica.

Accesso da browser

Per consentire a IAP di utilizzare il tuo ID client e il tuo secret tramite la consoleGoogle Cloud , segui le istruzioni riportate di seguito:

Rischi

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

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 sono interessate. I client OAuth eliminati possono essere ripristinati entro 30 giorni.

Per gestire efficacemente questo rischio operativo:

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

Fughe di client secret

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

Per ridurre questo rischio:

  • Proteggi i client secret come le password e non memorizzarli mai come testo normale
  • Implementa la gestione sicura delle credenziali utilizzando Secret Manager
  • Monitora l'accesso alle risorse IAP con Cloud Audit Logging
  • Un client secret compromesso influisce solo sull'autenticazione, non sull'autorizzazione per accedere alle risorse. Se sospetti che il tuo segreto sia stato divulgato, reimpostalo immediatamente.

Per l'accesso programmatico alle risorse protette da IAP, ti consigliamo di utilizzare l'autenticazione JWT dell'account di servizio anziché condividere i client secret OAuth con i singoli utenti. Questo approccio offre un isolamento della sicurezza migliore, 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 di autorizzazione. Per IAP, openid e email sono gli unici ambiti obbligatori. Questa considerazione non rappresenta di per sé un rischio significativo, ma è importante comprendere quanto segue:

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