Le credenziali client OAuth identificano l'identità della tua app e devono essere gestite con attenzione. Archivia queste credenziali solo in un archivio sicuro, ad esempio utilizzando un gestore dei 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 adatto alla 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, prendi in considerazione anche queste best practice per la tua piattaforma:
Per le applicazioni lato server che archiviano
token per molti utenti, criptali a riposo e assicurati che l'archivio dati non sia accessibile
pubblicamente a internet.
Per le app native per computer, l'utilizzo del
protocollo Proof Key for Code
Exchange (PKCE) è vivamente consigliato per ottenere codici di autorizzazione che possono
essere scambiati con token di accesso.
Gestire 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 gestirne l'invalidazione o la scadenza. I token
potrebbero essere invalidati per diversi motivi,
ad esempio potrebbero essere scaduti o l'accesso delle tue app potrebbe essere stato revocato dall'utente o
da un processo automatizzato. In questo caso, valuta attentamente come deve rispondere la tua applicazione,
incluso il prompt per l'utente al successivo accesso o la pulizia dei dati. Per ricevere una notifica
della revoca dei 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 alla 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 vengono richiesti ambiti aggiuntivi. L'app fornisce funzionalità di base per consentire all'utente
di 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 riportate di seguito.
Se l'utente rifiuta la richiesta, l'app disattiva la funzionalità e fornisce all'utente
un contesto aggiuntivo per richiedere nuovamente l'accesso.
Gestire il consenso per più ambiti
Quando richiedono 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 dell'app richiede più ambiti, spiegalo all'utente prima di
richiedere il consenso.
Puoi richiedere 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 un contesto e una giustificazione pertinenti
prima di richiedere gli ambiti OAuth.
Devi ridurre al minimo il numero di ambiti richiesti dalla tua app contemporaneamente. In alternativa,
utilizza 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 con tutte le funzionalità.
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, incluse le WebView su piattaforme mobile, come WebView su Android o WKWebView su iOS. Utilizza invece le librerie OAuth native
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 Developers per accettare esplicitamente i Termini di servizio, configurare
il client OAuth e prepararti per la verifica OAuth.
Per i workflow automatizzati, valuta la possibilità di utilizzare
service account.
Rimuovi i client OAuth inutilizzati
Controlla regolarmente i client OAuth 2.0 ed elimina in modo proattivo quelli che non sono più richiesti dalla tua applicazione o che sono diventati obsoleti. Se lasci configurati client non utilizzati, corri un potenziale rischio per la sicurezza, in quanto il client può essere utilizzato in modo improprio se le tue credenziali vengono compromesse.
Per ridurre ulteriormente i rischi derivanti da 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 non utilizzati. Questa pratica riduce al minimo l'area esposta agli attacchi della tua applicazione e garantisce
una buona igiene della sicurezza.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-08-31 UTC."],[[["\u003cp\u003eSecurely store and manage OAuth client credentials, avoiding hardcoding or public exposure.\u003c/p\u003e\n"],["\u003cp\u003eProtect user tokens (refresh and access) by storing them securely and revoking them when no longer needed.\u003c/p\u003e\n"],["\u003cp\u003eImplement proper handling of refresh token revocation and expiration scenarios, including user notification and data cleanup.\u003c/p\u003e\n"],["\u003cp\u003eUtilize incremental authorization to request only necessary OAuth scopes in context, minimizing initial requests and enhancing user privacy.\u003c/p\u003e\n"],["\u003cp\u003eEmploy secure browsing environments for OAuth authorization requests, avoiding embedded browsers like webviews and opting for native libraries or Google Sign-in.\u003c/p\u003e\n"]]],[],null,["This page covers some general best practices for integrating with OAuth 2.0. Consider these best\npractices in addition to any specific guidance for your type of application and development\nplatform. Also refer to the\n[advice for getting\nyour app ready for production](/identity/protocols/oauth2/production-readiness/policy-compliance) and [Google's\nOAuth 2.0 policies](/identity/protocols/oauth2/policies).\n\nHandle client credentials securely\n\n\nThe OAuth client credentials identify your app's identity and should be handled carefully. Only\nstore these credentials in secure storage, for example using a secret manager such as\n[Google Cloud Secret Manager](https://cloud.google.com/secret-manager/docs/overview).\nDo not hardcode the credentials, commit them to a code repository or publish them publicly.\n\nHandle user tokens securely\n\n\nUser tokens include both refresh tokens and access tokens used by your application. Store\ntokens securely [at rest](https://wikipedia.org/wiki/Data_at_rest)\nand never transmit them in plain text. Use a secure storage system appropriate for your\nplatform, such as\n[Keystore](https://developer.android.com/training/articles/keystore) on Android,\nKeychain Services on iOS and macOS, or Credential Locker on Windows.\n\n\n[Revoke tokens](/identity/protocols/oauth2/web-server#tokenrevoke) as soon as they\nare no longer needed and delete them permanently from your systems.\n\n\nIn addition, also consider these best practices for your platform:\n\n- For [server-side](/identity/protocols/oauth2/web-server) applications that store tokens for many users, encrypt them at rest and ensure that your data store is not publicly accessible to the Internet.\n- For native desktop apps, using the [Proof Key for Code\n Exchange (PKCE) protocol](/identity/protocols/oauth2/native-app#obtainingaccesstokens) is strongly recommended to obtain authorization codes that can be exchanged for access tokens.\n\nHandle refresh token revocation and expiration\n\n\nIf your app has requested a [refresh\ntoken for offline access](/identity/protocols/oauth2/web-server#offline), you must also handle their invalidation or expiration. Tokens\ncould be [invalidated for different reasons](/identity/protocols/oauth2#expiration),\nfor example it could have expired or your apps' access could have been revoked by the user or\nan automated process. In this case, consider carefully how your application should respond,\nincluding prompting the user at their next log in or cleaning up their data. To be notified of\ntoken revocation, integrate with the [Cross-Account\nProtection](/identity/protocols/risc) service.\n\nUse incremental authorization\n\n\nUse [incremental\nauthorization](/identity/protocols/oauth2/web-server#incrementalAuth) to request appropriate OAuth scopes when the functionality is needed by your\napplication.\n\n\nYou should not request access to data when the user first authenticates, unless it is essential\nfor the core functionality of your app. Instead, request only the specific scopes that are\nneeded for a task, following the principle to\n[select the smallest, most limited scopes possible](/identity/protocols/oauth2/production-readiness/policy-compliance#only-request-needed-scopes).\n\n\nAlways request scopes in context to help your users understand why your app is requesting access\nand how the data will be used.\n\n\nFor example, your application may follow this model:\n\n1. The user authenticates with your app\n 1. No additional scopes are requested. The app provides basic functionality to let the user explore and use features that do not require any additional data or access.\n2. The user selects a feature that requires access to additional data\n 1. Your application makes an authorization request for this specific OAuth scope required for this feature. If this feature requires multiple scopes, follow [the best practices below](#multiple-scopes).\n 2. If the user denies the request, the app disables the feature and gives the user additional context to request access again.\n\nHandle consent for multiple scopes\n\n\nWhen requesting multiple scopes at once, users may not grant all OAuth scopes you have\nrequested. Your app should handle the denial of scopes by disabling relevant functionality.\n\n\nIf your app's basic functionality requires multiple scopes, explain this to the user before\nprompting for consent.\n\n\nYou may only prompt the user again once they have clearly indicated an intent to use the\nspecific feature that requires the scope. Your app should provide the user with relevant context\nand justification before requesting OAuth scopes.\n\n\nYou should minimize the number of scopes your app requests at once. Instead,\n[utilize incremental authorization](#use-incremental-authorization) to request scopes\nin context of features and functionality.\n\nUse secure browsers\n\n\nOn the web, OAuth 2.0 authorization requests must only be made from full-featured web browsers.\nOn other platforms, make sure to select the\n[correct OAuth client type](/identity/protocols/oauth2#basicsteps) and integrate\nOAuth as appropriate for your platform. Do not redirect the request through embedded browsing\nenvironments, including webviews on mobile platforms, such as WebView on Android or WKWebView on\niOS. Instead, utilize [native OAuth libraries](/identity/protocols/oauth2/native-app)\nor [Google Sign-in](/identity/authorization) for your platform.\n\nManual creation and configuration of OAuth clients\n\n\nIn order to prevent abuse, OAuth clients cannot be created or modified programmatically. You\nmust use the Google Developers console to explicitly acknowledge the terms of service, configure\nyour OAuth client and prepare for OAuth verification.\n\n\nFor automated workflows, consider using\n[service accounts](/identity/protocols/oauth2/service-account) instead.\n\nRemove unused OAuth clients\n\n\nRegularly audit your OAuth 2.0 clients and proactively delete any that are no longer required by\nyour application or have become obsolete. Leaving unused clients configured represents a\npotential security risk as the client can be misused if your client credentials are ever\ncompromised.\n\n\nTo further mitigate risks from unused clients, OAuth 2.0 clients that have been inactive for six\nmonths are [automatically deleted](https://support.google.com/cloud/answer/15549257#unused-client-deletion).\n\n\nThe recommended best practice is to not wait for automatic deletion but rather proactively\nremove unused clients. This practice minimizes your application's attack surface and ensures\ngood security hygiene."]]