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 prevede l'utilizzo di un unico client OAuth personalizzato per più applicazioni protette da Identity-Aware Proxy (IAP) anziché la creazione di 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 della tua organizzazione (utenti interni)

    • Mostra il branding di Google Cloud nella schermata per il consenso anziché quello della tua organizzazione

  • Client OAuth personalizzato: viene creato e gestito da te. Questa opzione:

    • Può essere condiviso tra più applicazioni

    • Consente la personalizzazione del branding nella schermata per il consenso

    • Supporta l'accesso per gli utenti esterni (all'esterno 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 l'overhead amministrativo della gestione di più clienti

  • Semplifica l'abilitazione di IAP per i membri del team che non dovrebbero 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 Creazione di client OAuth per IAP. Per informazioni dettagliate sui client OAuth gestiti da Google, consulta Personalizza una configurazione OAuth per abilitare IAP.

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 tue risorse protette da IAP. In questo modo, script, job automatizzati e servizi di backend possono accedere in modo sicuro alle tue applicazioni protette senza l'accesso interattivo dell'utente.

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

  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]
    

    Esempi di comandi:

    # 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 della 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 della 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 che hai configurato. Per maggiori dettagli, consulta Autenticazione programmatica.

Accesso al browser

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

Rischi

Sebbene la condivisione di un client tra le tue applicazioni sia comoda, esistono dei rischi. Questa sezione descrive i potenziali rischi legati alla condivisione dei client e come mitigarli.

Single point of failure

L'utilizzo di un client OAuth per molte applicazioni crea un unico punto di dipendenza. Se un client viene eliminato o modificato in modo errato, l'errore interessa ogni applicazione che utilizza quel client. I client OAuth eliminati possono essere ripristinati entro 30 giorni.

Per gestire efficacemente questo rischio operativo:

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

Fuga di client secret

La condivisione di un client richiede la condivisione del client secret con persone e script. In questo modo, aumenta il rischio di fuga del client secret. IAP non è in grado di distinguere tra i token creati dalla tua applicazione e quelli creati da un client secret trapelato.

Per mitigare 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 Logs

  • La fuga di un client secret influisce solo sull'autenticazione, non sull'autorizzazione ad accedere alle risorse. Se sospetti che il tuo secret sia stato divulgato, reimpostalo immediatamente.

Per l'accesso programmatico alle risorse protette da IAP, valuta la possibilità di utilizzare l'autenticazione JWT del service account anziché condividere i client secret OAuth con 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 di autorizzazione. Per IAP, openid e email sono gli unici ambiti obbligatori. Questa considerazione di per sé non rappresenta un rischio significativo, ma è importante comprendere che:

  • 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 vengono compromesse, un malintenzionato avrebbe comunque bisogno delle autorizzazioni IAM appropriate per accedere alle risorse protette

  • Limitare il client solo agli ambiti openid e email richiesti aiuta a limitare il potenziale impatto sulla sicurezza