Questa pagina illustra alcune best practice generali per l'integrazione con OAuth 2.0. Considera queste best practice oltre alle indicazioni specifiche per il tuo tipo di applicazione e piattaforma di sviluppo. Consulta anche i consigli per preparare la tua app per la produzione e le policy OAuth 2.0 di Google.
Gestisci le credenziali client in modo sicuro
Le credenziali client OAuth identificano l'identità della tua app e devono essere gestite con attenzione. Archivia queste credenziali solo in uno spazio di archiviazione sicuro, ad esempio utilizzando un gestore di secret come Google Cloud Secret Manager. Non impostare le credenziali come hardcoded, non eseguirne il commit in un repository di codice e non pubblicarle pubblicamente.
Gestisci i token utente in modo sicuro
I token utente includono sia i token di aggiornamento sia i token di accesso utilizzati dalla tua applicazione. Archivia i token in modo sicuro at-rest e non trasmetterli mai in testo normale. Utilizza un sistema di archiviazione sicuro appropriato per la tua piattaforma, ad esempio Keystore su Android, i servizi Keychain su iOS e macOS o Credential Locker su Windows.
Revoca i token non appena non sono più necessari ed eliminali definitivamente dai tuoi sistemi.
Inoltre, tieni presente queste best practice per la tua piattaforma:
- Per le applicazioni lato server che memorizzano i token per molti utenti, criptali at-rest e assicurati che il tuo datastore non sia accessibile pubblicamente su internet.
- Per le app desktop, è vivamente consigliato l'utilizzo del protocollo PKCE (Proof Key for Code Exchange) per ottenere i codici di autorizzazione che possono essere scambiati con i token di accesso.
Token con vincolo del mittente con DPoP
Per proteggere la tua applicazione dal furto di token e dagli attacchi di replay, valuta la possibilità di limitare i token al mittente utilizzando DPoP (Demonstrating Proof-of-Possession). Mentre i token di connessione standard possono essere utilizzati da qualsiasi parte che li intercetta, i token DPoP sono associati in modo crittografico a una coppia di chiavi univoca generata e conservata dal client.
Quando utilizza DPoP, il client presenta una prova (un token web JSON firmato) all'endpoint del token quando richiede o aggiorna i token di aggiornamento. Questa prova dimostra che il client è in possesso della chiave privata corrispondente alla chiave pubblica associata al token. Se un token di aggiornamento associato a DPoP viene divulgato, non può essere riprodotto da un malintenzionato senza la chiave privata.
DPoP funziona insieme a PKCE per fornire una protezione completa:
- L'estensione PKCE protegge il codice di autorizzazione durante il flusso di reindirizzamento iniziale.
- DPoP protegge il token di aggiornamento di lunga durata, impedendo attacchi di replay in caso di compromissione.
L'adozione di DPoP è vivamente consigliata se la tua applicazione:
- Funziona come un'applicazione installata o desktop (o un'applicazione a pagina singola accoppiata a un server Backend-for-Frontend) in cui i token di aggiornamento potrebbero essere più suscettibili di esfiltrazione.
- Accede a dati altamente sensibili o ad API di alto valore, dove l'impatto della fuga di token è significativo.
- Devi soddisfare standard di conformità o sicurezza rigorosi che impongono l'uso di token vincolati al mittente.
Per istruzioni dettagliate sulla creazione di prove DPoP e sulla richiesta di token associati a DPoP, consulta la guida all'adozione di DPoP.
Utilizza il parametro state
Prima di gestire una risposta OAuth 2.0, verifica che il state ricevuto da Google corrisponda al state inviato nella richiesta di autorizzazione. Il parametro state deve essere un valore univoco e non indovinabile generato dalla tua applicazione.
L'utilizzo del parametro state contribuisce a garantire che la richiesta venga effettuata dall'utente e non da uno script dannoso, riducendo il rischio di attacchi di tipo richiesta cross-site (CSRF).
Gestisci la revoca e la scadenza del token di aggiornamento
Se la tua app ha richiesto un token di aggiornamento per l'accesso offline, devi anche gestire l'annullamento della convalida o la scadenza. I token potrebbero essere annullati per diversi motivi, ad esempio potrebbero essere scaduti o l'accesso alle tue app potrebbe essere stato revocato dall'utente o da un processo automatizzato. In questo caso, valuta attentamente come deve rispondere la tua applicazione, ad esempio chiedendo all'utente di accedere di nuovo o eliminando i suoi dati. Per ricevere una notifica della revoca del token, esegui l'integrazione con il servizio di Protezione su più account.
Utilizza l'autorizzazione incrementale
Utilizza l'autorizzazione incrementale per richiedere gli ambiti OAuth appropriati quando la funzionalità è necessaria per la tua applicazione.
Non devi richiedere l'accesso ai dati quando l'utente esegue l'autenticazione per la prima volta, a meno che non sia essenziale per la funzionalità di base della tua app. Richiedi invece solo gli ambiti specifici necessari per un'attività, seguendo il principio di selezionare gli ambiti più piccoli e limitati possibili.
Richiedi sempre gli ambiti nel contesto per aiutare gli utenti a capire perché la tua app richiede l'accesso e come verranno utilizzati i dati.
Ad esempio, la tua applicazione potrebbe seguire questo modello:
- L'utente si autentica con la tua app
- Non sono richiesti altri ambiti. L'app fornisce funzionalità di base per consentire all'utente di esplorare e utilizzare funzionalità che non richiedono dati o accessi aggiuntivi.
- L'utente seleziona una funzionalità che richiede l'accesso a dati aggiuntivi
- La tua applicazione effettua una richiesta di autorizzazione per questo ambito OAuth specifico richiesto per questa funzionalità. Se questa funzionalità richiede più ambiti, segui le best practice per più ambiti.
- Se l'utente nega la richiesta, l'app disattiva la funzionalità e fornisce all'utente un contesto aggiuntivo per richiedere nuovamente l'accesso.
Gestisci il consenso per più ambiti
Quando richiedi più ambiti contemporaneamente, gli utenti potrebbero non concedere tutti gli ambiti OAuth che hai richiesto. La tua app deve gestire il rifiuto degli ambiti disattivando la funzionalità pertinente.
Se la funzionalità di base della tua app richiede più ambiti, spiegalo all'utente prima di richiedere il consenso.
Puoi chiedere nuovamente l'autorizzazione all'utente solo dopo che ha indicato chiaramente l'intenzione di utilizzare la funzionalità specifica che richiede l'ambito. La tua app deve fornire all'utente il contesto e la motivazione pertinenti prima di richiedere gli ambiti OAuth.
Devi ridurre al minimo il numero di ambiti richiesti contemporaneamente dalla tua app. Utilizza invece l'autorizzazione incrementale per richiedere gli ambiti nel contesto di caratteristiche e funzionalità.
Utilizza browser sicuri
Sul web, le richieste di autorizzazione OAuth 2.0 devono essere effettuate solo da browser web completi. Su altre piattaforme, assicurati di selezionare il tipo di client OAuth corretto e di integrare OAuth in base alla tua piattaforma. Non reindirizzare la richiesta tramite ambienti di navigazione incorporati, incluse le visualizzazioni web su piattaforme mobile, come WebView su Android o WKWebView su iOS. Utilizza invece le librerie OAuth consigliate o Accedi con Google per la tua piattaforma.
Creazione e configurazione manuale dei client OAuth
Per prevenire comportamenti illeciti, i client OAuth non possono essere creati o modificati in modo programmatico. Devi utilizzare la console Google Cloud per accettare esplicitamente i Termini di servizio, configurare il client OAuth e prepararti alla verifica OAuth.
Per i workflow automatizzati, ti consigliamo di utilizzare i service account.
Rimuovi i client OAuth inutilizzati
Controlla regolarmente i tuoi client OAuth 2.0 ed elimina in modo proattivo quelli che non sono più richiesti dalla tua applicazione o che sono diventati obsoleti. Lasciare configurati client inutilizzati rappresenta un potenziale rischio per la sicurezza, in quanto il client può essere utilizzato in modo improprio se le credenziali del client vengono compromesse.
Per ridurre ulteriormente i rischi derivanti dai client inutilizzati, i client OAuth 2.0 che sono rimasti inattivi per sei mesi vengono eliminati automaticamente.
La best practice consigliata è non attendere l'eliminazione automatica, ma rimuovere in modo proattivo i client inutilizzati. Questa pratica riduce al minimo la superficie di attacco dell'applicazione e garantisce una buona igiene della sicurezza.