Questa pagina illustra alcune best practice generali per l'integrazione con OAuth 2.0. Tieni presente queste best practice in aggiunta a eventuali indicazioni specifiche per il tipo di applicazione e piattaforma di sviluppo. Consulta anche i suggerimenti per preparare l'app per la produzione e le norme OAuth 2.0 di Google.
Gestire le credenziali del client in modo sicuro
Le credenziali del 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 codificare le credenziali, non eseguirne il commit in un repository di codice e non pubblicarle pubblicamente.
Gestire 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 a riposo e non trasmetterli mai in testo normale. Utilizza un sistema di archiviazione sicuro appropriato per la tua piattaforma, ad esempio Keystore su Android, Keychain Services 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 anche queste best practice per la tua piattaforma:
- Per le applicazioni lato server che archiviano i token per molti utenti, criptali a riposo e assicurati che il datastore non sia accessibile pubblicamente a internet.
- Per le app desktop, è vivamente consigliato l'utilizzo del protocollo PKCE (Proof Key for Code Exchange) per ottenere codici di autorizzazione che possono essere scambiati con token di accesso.
Limitare i token del mittente con DPoP
Per proteggere la tua applicazione dal furto di token e dagli attacchi di riproduzione, valuta la possibilità di limitare i token del mittente utilizzando DPoP (Demonstrating Proof-of-Possession). Mentre i token Bearer standard possono essere utilizzati da qualsiasi parte che li intercetta, i token DPoP sono associati crittograficamente a una coppia di chiavi univoca generata e detenuta 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. 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 compromesso, non può essere riprodotto da un autore di attacchi senza la chiave privata.
DPoP funziona insieme a PKCE per fornire una protezione completa:
- PKCE protegge il codice di autorizzazione durante il flusso di reindirizzamento iniziale.
- DPoP protegge il token di aggiornamento a lunga durata, impedendo attacchi di riproduzione in caso di compromissione.
L'adozione di DPoP è vivamente consigliata se la tua applicazione:
- Funziona come client pubblico (ad esempio un'applicazione a pagina singola o un'app installata) in cui i token di aggiornamento potrebbero essere più soggetti all'esfiltrazione.
- Accede a dati altamente sensibili o API di alto valore, in cui l'impatto della perdita di token è significativo.
- Deve soddisfare standard di conformità o sicurezza rigorosi che richiedono token limitati al mittente.
Per istruzioni dettagliate sulla creazione di prove DPoP e sulla richiesta di token associati a DPoP, consulta la documentazione di DPoP.
Utilizzare 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
state parametro deve essere un valore univoco e non prevedibile generato dalla tua
applicazione.
L'utilizzo del parametro state contribuisce a garantire che la richiesta venga effettuata dall'utente, non da uno script dannoso, e riduce il rischio di
attacchi di falsificazione delle richieste cross-site
(CSRF).
Gestire la revoca e la scadenza dei token di aggiornamento
Se la tua app ha richiesto un token di aggiornamento per l'accesso offline, devi anche gestirne l'invalidazione o la scadenza. I token potrebbero essere invalidati per diversi motivi, ad esempio potrebbero essere scaduti o l'accesso alle tue app potrebbe essere stato revocato dall'utente o da un processo automatico. In questo caso, valuta attentamente la risposta della tua applicazione, inclusa la richiesta all'utente al successivo accesso o la pulizia dei suoi dati. Per ricevere una notifica della revoca del token, esegui l'integrazione con il servizio Protezione su più account.
Utilizzare 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 esegue l'autenticazione con la tua app.
- Non vengono richiesti ambiti aggiuntivi. L'app fornisce funzionalità di base per consentire all'utente esplorare e utilizzare funzionalità che non richiedono dati o accesso 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 contesto aggiuntivo per richiedere nuovamente l'accesso.
Gestire 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 le funzionalità pertinenti.
Se la funzionalità di base della tua app richiede più ambiti, spiega all'utente prima di richiedere il consenso.
Puoi richiedere nuovamente 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 un contesto pertinente e una giustificazione prima di richiedere gli ambiti OAuth.
Dovresti ridurre al minimo il numero di ambiti richiesti dalla tua app contemporaneamente. Utilizza invece l'autorizzazione incrementale per richiedere gli ambiti nel contesto delle funzionalità.
Utilizzare 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 modo appropriato per la tua piattaforma. Non reindirizzare la richiesta tramite ambienti di navigazione incorporati, inclusi i WebView 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 evitare abusi, i client OAuth non possono essere creati o modificati a livello di programmazione. Devi utilizzare la console Google Cloud per accettare esplicitamente i Termini di servizio, configurare il client OAuth e prepararti per la verifica OAuth.
Per i flussi di lavoro automatizzati, valuta la possibilità di utilizzare gli account di servizio invece.
Rimuovere i client OAuth inutilizzati
Controlla regolarmente i client OAuth 2.0 ed elimina in modo proattivo quelli non più richiesti da lla tua applicazione o diventati obsoleti. Se lasci configurati i client inutilizzati, si crea 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 inattivi da sei mesi vengono eliminati automaticamente.
La best practice consigliata è di non attendere l'eliminazione automatica, ma di rimuovere in modo proattivo i client inutilizzati. Questa pratica riduce al minimo la superficie di attacco della tua applicazione e garantisce buona igiene della sicurezza.