Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Jika aplikasi Anda perlu mengakses data atas nama pengguna, hal ini disebut
alur OAuth tiga-tahap. Dalam alur OAuth tiga-tahap, aplikasi Anda mendapatkan
kredensial dari pengguna akhir, yang login ke akunnya untuk menyelesaikan
autentikasi. Kemudian, aplikasi Anda akan menggunakan kredensial pengguna akhir untuk
mengakses resource Cloud Storage atas nama pengguna. Berikut adalah contoh
skenario tempat pendekatan ini dapat digunakan:
Aplikasi server web
Aplikasi terinstal dan desktop
Aplikasi seluler
JavaScript sisi klien
Aplikasi pada perangkat input terbatas
Untuk mengetahui informasi selengkapnya tentang skenario ini, lihat Skenario OAuth 2.0.
Jika Anda merancang aplikasi untuk mendukung beberapa opsi autentikasi
bagi pengguna akhir, gunakan Firebase Authentication, yang mendukung
autentikasi email dan sandi, serta login gabungan dengan penyedia
identitas seperti Google, Facebook, Twitter, dan GitHub. Lihat
Mulai menggunakan Firebase Authentication untuk mengetahui detail tentang cara menyiapkan sistem autentikasi untuk berbagai kasus penggunaan.
Saat aplikasi diberi token akses oleh pengguna akhir untuk mengakses data atas
nama pengguna, token akses tersebut hanya memiliki izin yang tersedia untuk
pengguna yang memberikan token. Misalnya, jika jane@example.com memiliki akses read-only
ke example-bucket, aplikasi yang telah diberi akses read-write oleh Jane
tidak akan dapat menulis ke example-bucket atas namanya.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]
