Pengguna Identity Platform dalam project

Objek pengguna Identity Platform mewakili akun pengguna yang telah mendaftar untuk suatu aplikasi dalam project Google Cloud Anda. Aplikasi biasanya memiliki banyak pengguna terdaftar, dan setiap aplikasi dalam project Google Cloud berbagi database pengguna.

Instance pengguna tidak bergantung pada instance Identity Platform, sehingga Anda dapat memiliki beberapa referensi untuk pengguna yang berbeda dalam konteks yang sama dan tetap memanggil metode mereka.

Properti pengguna

Pengguna Identity Platform memiliki kumpulan properti dasar yang tetap—ID unik, alamat email utama, nama, dan URL foto—tersimpan dalam database pengguna project, yang dapat diperbarui oleh pengguna (iOS, Android, web). Anda tidak dapat menambahkan properti lain ke objek pengguna secara langsung. Namun, Anda dapat menyimpan properti tambahan di layanan penyimpanan lain seperti Google Cloud Firestore.

Saat pertama kali pengguna mendaftar ke aplikasi Anda, data profil pengguna akan diisi menggunakan informasi yang tersedia:

Jika pengguna mendaftar dengan alamat email dan sandi, hanya properti alamat email utama yang akan diisi
Jika pengguna mendaftar dengan penyedia identitas gabungan, seperti Google atau Facebook, informasi akun yang disediakan oleh penyedia akan digunakan untuk mengisi profil pengguna
Jika pengguna mendaftar dengan sistem autentikasi kustom, Anda harus secara eksplisit menambahkan informasi yang diinginkan ke profil pengguna

Setelah akun pengguna dibuat, Anda dapat memuat ulang informasi pengguna tersebut agar menyertakan perubahan yang mungkin telah dibuat oleh si pengguna pada perangkat lain.

Penyedia proses login

Anda dapat membuat pengguna login ke aplikasi melalui beberapa metode: alamat email dan sandi, penyedia identitas gabungan, dan sistem autentikasi kustom. Anda dapat mengaitkan lebih dari satu metode login dengan satu pengguna: misalnya, pengguna dapat login ke akun yang sama menggunakan alamat email dan sandi, atau menggunakan Login dengan Google.

Instance pengguna melacak setiap penyedia yang terhubung dengan pengguna. Hal ini memungkinkan Anda untuk memperbarui properti profil kosong menggunakan informasi yang diberikan oleh penyedia. Baca bagian Mengelola Pengguna (iOS, Android, web).

Pengguna aktif

Ketika pengguna mendaftar atau login, pengguna tersebut menjadi pengguna aktif instance Auth. Instance ini mempertahankan status pengguna, sehingga memuat ulang halaman (pada browser) atau memulai ulang aplikasi tidak akan menghapus informasi pengguna ini.

Ketika pengguna logout, instance Auth berhenti menyimpan referensi ke objek pengguna dan tidak lagi mempertahankan statusnya; tidak ada pengguna yang aktif saat ini. Namun, instance pengguna tetap berfungsi sepenuhnya: jika Anda menyimpan referensi ke sana, Anda masih dapat mengakses dan memperbarui data pengguna.

Siklus proses pengguna

Cara yang direkomendasikan untuk melacak status instance Auth saat ini adalah dengan menggunakan pemroses (juga disebut sebagai "observer" di JavaScript). Pemroses Auth akan dikirimi pemberitahuan setiap kali sesuatu yang relevan terjadi pada objek Auth. Baca bagian Mengelola Pengguna (iOS, Android, web).

Pemroses Auth akan diberitahu jika terjadi situasi berikut:

Objek Auth selesai melakukan inisialisasi dan pengguna sudah login dari sesi sebelumnya atau telah dialihkan dari alur login penyedia identitas
Pengguna login (pengguna aktif ditetapkan)
Pengguna logout (pengguna aktif menjadi null)
Token akses pengguna aktif dimuat ulang. Hal ini dapat terjadi dalam keadaan berikut:
- Masa berlaku token akses berakhir: ini biasa terjadi. Token refresh digunakan untuk memperoleh sekumpulan token valid yang baru.
- Pengguna mengubah sandinya: Identity Platform mengeluarkan token akses dan refresh baru, lalu membuat token lama tidak berlaku lagi. Ini secara otomatis membuat token pengguna tidak berlaku dan/atau membuat pengguna logout dari setiap perangkat untuk alasan keamanan.
- Pengguna melakukan autentikasi ulang: beberapa tindakan mengharuskan bahwa kredensial pengguna diterbitkan baru-baru ini; tindakan tersebut termasuk menghapus akun, menentukan alamat email utama, dan mengubah sandi. Daripada memproses logout pengguna kemudian login lagi, dapatkan kredensial baru dari pengguna dan teruskan kredensial baru tersebut ke metode autentikasi ulang objek pengguna.

Secara default, Identity Platform memungkinkan pengguna mendaftar dan menghapus akun mereka tanpa intervensi administratif. Dalam banyak situasi, hal ini memungkinkan pengguna akhir menemukan aplikasi atau layanan Anda, dan mengaktifkan (atau menonaktifkannya) dengan hambatan minimal.

Namun, ada situasi saat Anda ingin pengguna dibuat secara manual atau terprogram oleh administrator, baik menggunakan Admin SDK atau Konsol Google Cloud. Dalam kasus ini, Anda dapat menonaktifkan tindakan pengguna dari halaman setelan Identity Platform, yang mencegah pembuatan dan penghapusan akun oleh pengguna akhir. Jika menggunakan multi-tenancy, Anda perlu membuat permintaan HTTP untuk menonaktifkan fitur ini per tenant.

Jika pengguna akhir mencoba membuat atau menghapus akun dalam sistem Anda, layanan Identity Platform akan menampilkan kode error: auth/admin-restricted-operation untuk panggilan API Web, atau ERROR_ADMIN_RESTRICTED_OPERATION untuk Android dan iOS. Anda harus menangani error di frontend dengan baik dengan meminta pengguna mengambil tindakan yang sesuai untuk layanan Anda.

Token Auth

Saat Anda melakukan autentikasi dengan Identity Platform, ada tiga jenis token autentikasi yang mungkin Anda temui:

Token ID Identity Platform	Dibuat oleh Identity Platform saat pengguna login ke aplikasi. Token ini adalah JWT yang ditandatangani yang mengidentifikasi pengguna dalam project Google Cloud dengan aman. Token ini berisi informasi profil dasar untuk pengguna, termasuk string ID pengguna yang unik untuk project Google Cloud. Karena integritas token ID dapat diverifikasi, Anda dapat mengirimkannya ke server backend untuk mengidentifikasi pengguna yang login saat ini.
Token penyedia identitas	Dibuat oleh penyedia identitas gabungan, seperti Google dan Facebook. Token ini dapat memiliki format yang berbeda, tetapi sering kali merupakan token akses OAuth 2.0. Aplikasi menggunakan token ini untuk memverifikasi bahwa pengguna telah berhasil diautentikasi dengan penyedia identitas, lalu mengubahnya menjadi kredensial yang dapat digunakan oleh layanan Identity Platform.
Token kustom Identity Platform	Dibuat oleh sistem autentikasi kustom agar pengguna bisa login ke aplikasi menggunakan sistem autentikasi Anda. Token kustom adalah JWT yang ditandatangani menggunakan kunci pribadi akun layanan. Aplikasi menggunakan token ini dengan cara yang sama seperti saat menggunakan token yang diperoleh dari penyedia identitas gabungan.

Alamat email terverifikasi

Identity Platform menganggap email telah terverifikasi jika memenuhi dua ketentuan:

Pengguna menyelesaikan alur verifikasi Identity Platform
Email tersebut diverifikasi oleh Penyedia Identitas atau IdP yang tepercaya.

IdP yang memverifikasi email sekali, tetapi kemudian mengizinkan pengguna mengubah alamat email tanpa memerlukan verifikasi ulang, bukan IdP yang tepercaya. IdP yang memiliki domain atau selalu mensyaratkan verifikasi dianggap sebagai IdP yang tepercaya.

Penyedia yang tepercaya:

Google (untuk alamat @gmail.com)
Yahoo (untuk alamat @yahoo.com)
Microsoft (untuk alamat @outlook.com dan @hotmail.com)
Apple (selalu terverifikasi, karena akun selalu diverifikasi dan melalui autentikasi multi-faktor)

Penyedia tidak tepercaya:

Facebook
Twitter
GitHub
Google, Yahoo, dan Microsoft untuk domain yang tidak dikeluarkan oleh Penyedia Identitas tersebut
Email/Sandi tanpa verifikasi email

Dalam beberapa situasi, Identity Platform akan otomatis menautkan akun saat pengguna login dengan penyedia yang berbeda menggunakan alamat email yang sama. Namun, hal ini hanya dapat terjadi jika kriteria tertentu terpenuhi. Untuk memahami alasannya, pertimbangkan situasi berikut: seorang pengguna login menggunakan Google dengan akun @gmail.com dan seorang oknum yang berbahaya membuat akun menggunakan alamat @gmail.com yang sama, tetapi login melalui Facebook. Jika kedua akun tersebut ditautkan secara otomatis, oknum tersebut akan mendapatkan akses ke akun pengguna.

Kasus berikut menjelaskan kapan kami menautkan akun secara otomatis dan kapan kami menampilkan error yang memerlukan tindakan pengguna atau developer:

Pengguna login dengan penyedia yang tidak tepercaya, lalu login dengan penyedia lain yang tidak tepercaya menggunakan email yang sama (misalnya, Facebook dilanjutkan dengan GitHub). Tindakan ini akan memunculkan error yang memerlukan penautan akun.
Pengguna login dengan penyedia yang tepercaya, lalu login dengan penyedia yang tidak tepercaya menggunakan email yang sama (misalnya, Google dilanjutkan dengan Facebook). Tindakan ini akan memunculkan error yang memerlukan penautan akun.
Pengguna login dengan penyedia yang tidak tepercaya, lalu login dengan penyedia yang tepercaya menggunakan email yang sama (misalnya, Facebook dilanjutkan dengan Google). Penyedia yang tepercaya akan menimpa penyedia yang tidak tepercaya. Jika pengguna mencoba login lagi dengan Facebook, hal ini akan menyebabkan error yang memerlukan penautan akun.
Pengguna login dengan penyedia yang tepercaya, lalu login dengan penyedia lain yang tepercaya menggunakan email yang sama (misalnya, Apple dilanjutkan dengan Google). Kedua penyedia akan ditautkan tanpa error.

Anda dapat secara manual menetapkan email sebagai terverifikasi menggunakan Admin SDK, tetapi sebaiknya Anda hanya melakukan hal ini jika tahu bahwa pengguna benar-benar memiliki email tersebut.