Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Panduan ini membantu Anda memilih antara menggunakan library Google Identity Services untuk otorisasi pengguna atau menerapkan library JavaScript Anda sendiri. Fitur ini
membantu Anda memutuskan alur otorisasi OAuth 2.0 yang terbaik untuk aplikasi
web Anda.
Library GIS berjalan di browser yang didukung ini pada perangkat pengguna. Library ini tidak dimaksudkan untuk digunakan dengan framework JavaScript sisi server seperti Node.js. Sebagai gantinya, gunakan library klien Node.js Google.
Panduan ini hanya membahas topik otorisasi dan berbagi data. Bagian ini tidak meninjau autentikasi pengguna. Sebagai gantinya, lihat panduan Login dengan Google dan Bermigrasi dari Login dengan Google untuk proses pendaftaran dan login pengguna.
Memutuskan apakah library GIS tepat untuk Anda
Anda harus memilih apakah akan menggunakan library Google, atau membuat sendiri yang paling sesuai
dengan kebutuhan Anda. Ringkasan fitur dan fungsi:
Library JavaScript Layanan Identitas Google menerapkan:
Alur izin berbasis pop-up untuk meminimalkan pengalihan, sehingga pengguna dapat tetap berada di situs Anda selama proses otorisasi.
Fitur keamanan seperti Pemalsuan Permintaan Lintas Situs (CRSF).
Metode helper untuk meminta cakupan individual dan mengonfirmasi izin pengguna.
Link dokumentasi dan penanganan error yang mudah digunakan oleh engineer selama pengembangan dan selanjutnya bagi pengunjung situs Anda.
Saat menerapkan tanpa library Layanan Identitas, Anda bertanggung jawab
untuk:
Mengelola permintaan dan respons dengan endpoint OAuth 2.0 Google,
termasuk pengalihan.
Mengoptimalkan pengalaman pengguna.
Implementasi fitur keamanan untuk memvalidasi permintaan, respons, dan
untuk mencegah CSRF.
Metode untuk mengonfirmasi bahwa pengguna telah memberikan izin untuk cakupan apa pun yang diminta.
Mengelola kode error OAuth 2.0, membuat pesan yang dapat dibaca manusia, dan
link ke bantuan pengguna.
Singkatnya, Google menawarkan library GIS untuk membantu Anda menerapkan klien OAuth 2.0 dengan cepat dan aman, serta mengoptimalkan pengalaman otorisasi pengguna.
Memilih alur otorisasi
Anda harus memilih salah satu dari dua alur otorisasi OAuth 2.0: kode implisit atau otorisasi -- terlepas dari apakah Anda memutuskan untuk menggunakan library JavaScript Google Identity Services atau membuat library Anda sendiri.
Kedua alur menghasilkan token akses yang dapat digunakan untuk memanggil Google API.
Perbedaan utama antara kedua alur tersebut adalah:
jumlah tindakan pengguna,
apakah aplikasi Anda akan memanggil Google API tanpa kehadiran pengguna,
apakah platform backend diperlukan untuk menghosting endpoint dan menyimpan token refresh
per pengguna untuk masing-masing akun pengguna, dan
tingkat keamanan pengguna yang lebih tinggi atau lebih rendah.
Saat membandingkan alur dan mengevaluasi persyaratan keamanan, faktor yang perlu
dipertimbangkan adalah tingkat keamanan pengguna bervariasi bergantung pada cakupan yang
Anda pilih. Misalnya, melihat undangan kalender sebagai hanya baca mungkin dianggap
tidak terlalu berisiko dibandingkan menggunakan cakupan baca/tulis untuk mengedit file di Drive.
Perbandingan alur OAuth 2.0
Alur implisit
Alur kode otorisasi
Perlu izin pengguna
Untuk setiap permintaan token, termasuk mengganti token yang sudah tidak berlaku.
Hanya untuk permintaan token pertama.
Pengguna harus ada
Ya
Tidak, mendukung penggunaan offline.
Keamanan pengguna
Paling sedikit
Sebagian besar, memiliki autentikasi klien dan menghindari risiko penanganan token dalam browser.
Token akses diterbitkan
Ya
Ya
Token refresh dikeluarkan
Tidak
Ya
Perlu browser yang didukung
Ya
Ya
Token akses yang digunakan untuk memanggil Google API
hanya dari aplikasi web yang
berjalan di {i>browser<i} pengguna.
baik dari server yang berjalan di platform backend, atau dari aplikasi web
yang berjalan di browser pengguna.
Memerlukan platform backend
Tidak
Ya, untuk hosting dan penyimpanan endpoint.
Perlu penyimpanan aman
Tidak
Ya, untuk penyimpanan token refresh.
Memerlukan hosting endpoint kode otorisasi
Tidak
Ya, untuk menerima kode otorisasi dari Google.
Perilaku akhir masa berlaku token akses
Gestur pengguna seperti menekan tombol atau mengklik link diperlukan untuk
meminta dan mendapatkan token akses baru yang valid.
Setelah ada permintaan awal dari pengguna, platform Anda akan menukar token refresh yang disimpan untuk mendapatkan token akses valid baru yang diperlukan untuk memanggil Google API.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2023-12-01 UTC."],[[["\u003cp\u003eThis guide helps developers choose between Google Identity Services or a custom JavaScript library for OAuth 2.0 authorization in their web applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services offers pre-built security features, optimized user experience, and easier implementation compared to building a custom solution.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers need to select between the Implicit or Authorization Code flow based on security, user presence requirements, and backend needs.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization Code flow is recommended for enhanced security, offline access, and refresh token management through a backend server.\u003c/p\u003e\n"],["\u003cp\u003eThe guide assumes prior knowledge of OAuth 2.0 concepts and focuses solely on authorization and data sharing, not user authentication.\u003c/p\u003e\n"]]],[],null,["# Choose a user authorization model\n\nThis guide helps you to choose between using the Google Identity Services\nlibrary for user authorization or implementing your own JavaScript library. It\nhelps you decide which OAuth 2.0 authorization flow is best for your web\napplication.\n\nPrior to reading this guide it is assumed that you are familiar with the terms\nand concepts described in the [Overview](/identity/oauth2/web/guides/overview) and\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) guide.\n\nThe GIS library runs in these [supported browsers](/identity/gsi/web/guides/supported-browsers) on the user's device. It\nis not intended for use with server-side JavaScript frameworks such as Node.js,\ninstead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nThis guide only covers authorization and data sharing topics. It does not review\nuser authentication, instead see [Sign In With Google](/identity/gsi/web) and the [Migrating\nfrom Google Sign-In](/identity/gsi/web/guides/migration) guide for user sign-up and sign-in.\n\nDeciding if the GIS library is right for you\n--------------------------------------------\n\nYou must choose if using Google's library, or creating your own best fits your\nneeds. An overview of features and functionality:\n\n- Google's Identity Services JavaScript library implements:\n - Popup based consent flows to minimize redirects, thus enabling users to remain on your site throughout the authorization process.\n - Security features such as Cross-site Request Forgery (CRSF).\n - Helper methods to request individual scopes and confirm user consent.\n - Human friendly error handling and documentation links for use by engineers during development and later for visitors to your site.\n- When implementing without the Identity Services library you are responsible for:\n - Managing requests and responses with Google's OAuth 2.0 endpoints, including redirects.\n - Optimizing the user experience.\n - Implementation of security features to validate requests, responses, and to prevent CSRF.\n - Methods to confirm a user has granted consent for any requested scopes.\n - Managing OAuth 2.0 error codes, creating human readable messages, and links to user help.\n\nIn summary, Google offers the GIS library to help you to quickly, and securely\nimplement an OAuth 2.0 client and optimize the user's authorization experience.\n\nChoosing an authorization flow\n------------------------------\n\nYou will need to choose one of two OAuth 2.0 authorization flows: implicit or\nauthorization code -- regardless if you decide to use the Google Identity\nServices JavaScript library or to create your own library.\n\nBoth flows result in an access token which can be used to call Google APIs.\n\nThe primary differences between the two flows are:\n\n- the number of user actions,\n- whether your app will call Google APIs without the user present,\n- if a backend platform is needed to host an endpoint and to store per-user refresh tokens for individual user accounts, and\n- higher or lower levels of user security.\n\nWhen comparing flows and evaluating your security requirements, a factor to\nconsider is that the level of user security varies depending on the scopes you\nchoose. For example, viewing calendar invites as read-only might be considered\nless risky than using a read/write scope to edit files in Drive.\n| **Key Point:** Authorization code flow is recommended because it provides a more secure flow.\n\nOAuth 2.0 flow comparison\n-------------------------\n\n|--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Implicit flow** | **Authorization code flow** |\n| **User consent required** | For every token request, including replacing expired tokens. | Only for the first token request. |\n| **User must be present** | Yes | No, supports offline use. |\n| **User security** | Least | Most, has client authentication and avoids in-browser token handling risks. |\n| **Access token issued** | Yes | Yes |\n| **Refresh token issued** | No | Yes |\n| **Supported browser required** | Yes | Yes |\n| **Access token used to call Google APIs** | only from a web app running in the user's browser. | either from a server running on backend platform, or from a web app running in the user's browser. |\n| **Requires backend platform** | No | Yes, for endpoint hosting and storage. |\n| **Secure storage needed** | No | Yes, for refresh token storage. |\n| **Requires hosting of an authorization code endpoint** | No | Yes, to receive authorization codes from Google. |\n| **Access token expiration behavior** | A user gesture such as button press or clicking on a link is required to request and obtain a new, valid access token. | After an initial user request, your platform exchanges the stored refresh token to obtain a new, valid access token necessary to call Google APIs. |"]]
