Stay organized with collections
Save and categorize content based on your preferences.
When your application needs to access data on a user's behalf, this is called a
three-legged OAuth flow. In a three-legged OAuth flow, your application obtains
credentials from an end user, who signs into their account to complete
authentication. Your application then uses the end user's credentials to
access Cloud Storage resources on the user's behalf. Here are examples
of scenarios where this approach can be used:
If you are designing an application to support multiple authentication options
for end users, then use Firebase Authentication, which supports
email and password authentication as well as federated sign in with identity
providers such as Google, Facebook, Twitter, and GitHub. See
Where do I start with Firebase Authentication
for details on how to set up authentication systems for different use cases.
When an application is granted an access token by an end user to access data on
the user's behalf, that access token only has the permissions available to the
user who grants the token. For example, if jane@example.com has read-only
access to example-bucket, an application which Jane has granted read-write
access to will be unable to write to example-bucket on her behalf.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 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)."]]
