Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Quando o aplicativo precisa acessar dados em nome de um usuário, isso é chamado de
fluxo OAuth de três etapas. Em um fluxo de três etapas do OAuth, seu aplicativo recebe
as credenciais de um usuário final, que faz login na conta para concluir
a autenticação. O aplicativo usa as credenciais do usuário final para
acessar os recursos do Cloud Storage em nome dele. Confira alguns exemplos
de cenários em que essa abordagem pode ser usada:
Caso você esteja criando um aplicativo que seja compatível com várias opções de autenticação de usuários finais, use o Firebase Authentication, que aceita a autenticação de e-mail e senha, além login federado com provedores de identidade, como Google, Facebook, Twitter e GitHub. Consulte Por onde começar com Firebase Authentication para ver detalhes sobre como configurar sistemas de autenticação para diferentes casos de uso.
Quando um usuário final concede um token de acesso a um aplicativo para acessar dados
em nome do usuário, esse token de acesso só tem as permissões disponíveis para o
usuário que o concede. Por exemplo, se jane@example.com tiver acesso read-only a example-bucket, um aplicativo que recebeu o acesso read-write de Jane poderá fazer gravações em example-bucket no nome dela.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 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)."]]
