Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Quando la tua applicazione deve accedere ai dati per conto di un utente, si parla di
flusso OAuth a tre vie. In un flusso OAuth a tre vie, la tua applicazione ottiene le credenziali da un utente finale, che accede al proprio account per completare l'autenticazione. L'applicazione utilizza quindi le credenziali dell'utente finale per accedere alle risorse di Cloud Storage per suo conto. Ecco alcuni esempi di scenari in cui è possibile utilizzare questo approccio:
Applicazioni server web
Applicazioni installate e desktop
Applicazioni mobili
JavaScript lato client
Applicazioni su dispositivi con input limitato
Per ulteriori informazioni su questi scenari, consulta la sezione Scenari OAuth 2.0.
Se stai progettando un'applicazione per supportare più opzioni di autenticazione per gli utenti finali, utilizza Firebase Authentication, che supporta l'autenticazione tramite email e password, nonché l'accesso federato con provider di identità come Google, Facebook, Twitter e GitHub. Consulta
Da dove iniziare con Firebase Authentication
per informazioni dettagliate su come configurare i sistemi di autenticazione per diversi casi d'uso.
Quando un utente finale concede a un'applicazione un token di accesso per accedere ai dati per suo conto, questo token di accesso ha solo le autorizzazioni disponibili per l'utente che lo concede. Ad esempio, se jane@example.com ha read-only
accesso a example-bucket, un'applicazione a cui Jane ha concesso read-write
accesso non potrà scrivere a example-bucket per suo conto.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-11 UTC."],[],[],null,["# Accessing data on a user's behalf\n\nWhen your application needs to access data on a user's behalf, this is called a\nthree-legged OAuth flow. In a three-legged OAuth flow, your application obtains\ncredentials from an end user, who signs into their account to complete\nauthentication. Your application then uses the end user's credentials to\naccess Cloud Storage resources on the user's behalf. Here are examples\nof scenarios where this approach can be used:\n\n- Web server applications\n- Installed and desktop applications\n- Mobile applications\n- Client-side JavaScript\n- Applications on limited-input devices\n\nFor more information on these scenarios, see [OAuth 2.0 scenarios](https://developers.google.com/identity/protocols/OAuth2#scenarios).\n\nFor other scenarios, you might want to use [service account credentials](/iam/docs/service-account-overview#credentials).\n\nIf you are designing an application to support multiple authentication options\nfor end users, then use [Firebase Authentication](https://firebase.google.com/docs/auth/), which supports\nemail and password authentication as well as federated sign in with identity\nproviders such as Google, Facebook, Twitter, and GitHub. See\n[Where do I start with Firebase Authentication](https://firebase.google.com/docs/auth/where-to-start)\nfor details on how to set up authentication systems for different use cases.\n\nWhen an application is granted an access token by an end user to access data on\nthe user's behalf, that access token only has the permissions available to the\nuser who grants the token. For example, if jane@example.com has `read-only`\naccess to `example-bucket`, an application which Jane has granted `read-write`\naccess to will be unable to write to `example-bucket` on her behalf.\n\nWhat's next\n-----------\n\n- Learn more about [authentication in Cloud Storage](/storage/docs/authentication)."]]
