Ikuti semua informasi yang diumumkan di Firebase Summit, dan pelajari bagaimana Firebase dapat membantu Anda mempercepat pengembangan aplikasi dan menjalankan aplikasi dengan percaya diri. Pelajari Lebih Lanjut

Pengguna di Proyek Firebase

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Objek pengguna Firebase mewakili akun pengguna yang telah mendaftar untuk aplikasi di proyek Anda. Aplikasi biasanya memiliki banyak pengguna terdaftar, dan setiap aplikasi dalam proyek berbagi basis data pengguna.

Instance pengguna terpisah dari instance Firebase Authentication, sehingga Anda dapat memiliki beberapa referensi ke pengguna yang berbeda dalam konteks yang sama dan tetap memanggil salah satu metodenya.

Properti pengguna

Pengguna Firebase memiliki sekumpulan properti dasar tetap—ID unik, alamat email utama, nama, dan URL foto—yang disimpan dalam database pengguna proyek, yang dapat diperbarui oleh pengguna ( iOS , Android , web ). Anda tidak dapat menambahkan properti lain ke objek pengguna secara langsung; sebagai gantinya, Anda dapat menyimpan properti tambahan di layanan penyimpanan lainnya, seperti Google Cloud Firestore.

Pertama kali pengguna mendaftar ke aplikasi Anda, data profil pengguna diisi menggunakan informasi yang tersedia:

  • Jika pengguna mendaftar dengan alamat email dan kata sandi, hanya properti alamat email utama yang diisi
  • Jika pengguna mendaftar dengan penyedia identitas federasi, seperti Google atau Facebook, informasi akun yang disediakan oleh penyedia digunakan untuk mengisi profil pengguna.
  • Jika pengguna mendaftar dengan sistem autentikasi khusus Anda, Anda harus secara eksplisit menambahkan informasi yang Anda inginkan ke profil pengguna

Setelah akun pengguna dibuat, Anda dapat memuat ulang informasi pengguna untuk menyertakan perubahan apa pun yang mungkin dibuat pengguna di perangkat lain.

Penyedia masuk

Anda dapat memasukkan pengguna ke aplikasi Anda menggunakan beberapa metode: alamat email dan kata sandi, penyedia identitas federasi, dan sistem autentikasi khusus Anda. Anda dapat mengaitkan lebih dari satu metode masuk dengan pengguna: misalnya, pengguna dapat masuk ke akun yang sama menggunakan alamat email dan sandi, atau menggunakan Masuk dengan Google.

Instance pengguna melacak setiap penyedia yang ditautkan ke pengguna. Ini memungkinkan Anda memperbarui properti profil kosong menggunakan informasi yang diberikan oleh penyedia. Lihat Mengelola Pengguna ( iOS , Android , web ).

Pengguna saat ini

Saat pengguna mendaftar atau login, pengguna tersebut menjadi pengguna instance Auth saat ini. Instance mempertahankan status pengguna, sehingga menyegarkan halaman (di browser) atau memulai ulang aplikasi tidak akan menghilangkan informasi pengguna.

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

Siklus hidup pengguna

Cara yang disarankan untuk melacak status instance Auth saat ini adalah dengan menggunakan pendengar (disebut juga "pengamat" dalam JavaScript). Pendengar Auth akan diberi tahu setiap kali sesuatu yang relevan terjadi pada objek Auth. Lihat Mengelola Pengguna ( iOS , Android , web ).

Pemroses Auth akan diberi tahu dalam situasi berikut:

  • Objek Auth selesai melakukan inisialisasi dan pengguna telah masuk dari sesi sebelumnya, atau telah dialihkan dari alur masuk penyedia identitas
  • Pengguna masuk (pengguna saat ini ditetapkan)
  • Seorang pengguna logout (pengguna saat ini menjadi null)
  • Token akses pengguna saat ini disegarkan. Kasus ini dapat terjadi pada kondisi berikut:
    • Token akses kedaluwarsa: ini adalah situasi umum. Token penyegaran digunakan untuk mendapatkan sekumpulan token baru yang valid.
    • Pengguna mengubah kata sandi mereka: Firebase mengeluarkan token akses dan penyegaran baru dan merender token lama kedaluwarsa. Ini secara otomatis membuat token pengguna habis dan/atau membuat pengguna logout di setiap perangkat, untuk alasan keamanan.
    • Pengguna mengautentikasi ulang: beberapa tindakan mengharuskan kredensial pengguna dikeluarkan baru-baru ini; tindakan tersebut termasuk menghapus akun, menyetel alamat email utama, dan mengubah kata sandi. Alih-alih mengeluarkan pengguna lalu masuk lagi, dapatkan kredensial baru dari pengguna, dan teruskan kredensial baru ke metode autentikasi ulang objek pengguna.

Layanan mandiri pengguna

Secara default, Firebase memungkinkan pengguna untuk mendaftar dan menghapus akun mereka tanpa intervensi administratif. Dalam banyak situasi, ini memungkinkan pengguna akhir untuk menemukan aplikasi atau layanan Anda dan onboard (atau offboard) dengan gesekan minimal.

Namun, ada situasi di mana Anda ingin pengguna dibuat secara manual atau terprogram oleh administrator, baik menggunakan Admin SDK atau konsol Firebase. Dalam kasus ini, Anda dapat menonaktifkan tindakan pengguna dari halaman Pengaturan Firebase Authentication , yang mencegah pembuatan dan penghapusan akun oleh pengguna akhir. Jika Anda menggunakan multi-penyewa, Anda harus membuat permintaan HTTP untuk menonaktifkan fitur ini per penyewa.

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

Token autentikasi

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

Token ID Firebase Dibuat oleh Firebase saat pengguna login ke aplikasi. Token ini adalah JWT bertanda tangan yang mengidentifikasi pengguna dengan aman di proyek Firebase. Token ini berisi informasi profil dasar untuk pengguna, termasuk string ID pengguna, yang unik untuk proyek Firebase. Karena integritas token ID dapat diverifikasi , Anda dapat mengirimkannya ke server backend untuk mengidentifikasi pengguna yang saat ini masuk.
Token penyedia identitas Dibuat oleh penyedia identitas federasi, seperti Google dan Facebook. Token ini dapat memiliki format yang berbeda, tetapi seringkali merupakan token akses OAuth 2.0. Aplikasi menggunakan token ini untuk memverifikasi bahwa pengguna telah berhasil mengautentikasi dengan penyedia identitas, lalu mengonversinya menjadi kredensial yang dapat digunakan oleh layanan Firebase.
Token khusus Firebase Dibuat oleh sistem autentikasi khusus Anda untuk memungkinkan pengguna masuk ke aplikasi menggunakan sistem autentikasi Anda. Token khusus adalah JWT yang ditandatangani menggunakan kunci pribadi akun layanan . Aplikasi menggunakan token ini seperti mereka menggunakan token yang dikembalikan dari penyedia identitas federasi.

Alamat email terverifikasi

Firebase menganggap email terverifikasi jika memenuhi dua syarat:

  1. Pengguna menyelesaikan alur verifikasi Firebase
  2. Email tersebut diverifikasi oleh Penyedia Identitas tepercaya, atau disingkat IdP.

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

Penyedia tepercaya:

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

Penyedia tidak tepercaya:

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

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

Kasus berikut menjelaskan saat kami menautkan akun secara otomatis dan saat kami melontarkan kesalahan yang memerlukan tindakan pengguna atau pengembang:

  • Pengguna masuk dengan penyedia yang tidak tepercaya, lalu masuk dengan penyedia lain yang tidak tepercaya dengan email yang sama (misalnya, Facebook diikuti oleh GitHub). Ini menimbulkan kesalahan yang membutuhkan penautan akun.
  • Pengguna masuk dengan penyedia tepercaya, lalu masuk dengan penyedia tidak tepercaya dengan email yang sama (misalnya, Google diikuti dengan Facebook). Ini menimbulkan kesalahan yang membutuhkan penautan akun.
  • Pengguna masuk dengan penyedia yang tidak tepercaya, lalu masuk dengan penyedia tepercaya dengan email yang sama (misalnya, Facebook diikuti oleh Google). Penyedia tepercaya menimpa penyedia yang tidak tepercaya. Jika pengguna mencoba masuk lagi dengan Facebook, itu akan menyebabkan kesalahan yang memerlukan penautan akun.
  • Pengguna masuk dengan penyedia tepercaya, lalu masuk dengan penyedia tepercaya lain dengan email yang sama (misalnya, Apple diikuti oleh Google). Kedua penyedia akan ditautkan tanpa kesalahan.

Anda dapat menyetel email sebagai terverifikasi secara manual dengan menggunakan Admin SDK, tetapi sebaiknya lakukan hal ini hanya jika Anda tahu bahwa email tersebut benar-benar milik pengguna.