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

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 database pengguna.

Instance pengguna tidak bergantung pada 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 kumpulan properti dasar yang 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.

Saat 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 gabungan, 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 memasukkan perubahan apa pun yang mungkin telah dilakukan pengguna di perangkat lain.

Penyedia masuk

Anda dapat memasukkan pengguna ke aplikasi Anda menggunakan beberapa metode: alamat email dan sandi, penyedia identitas gabungan, 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 untuk memperbarui properti profil kosong menggunakan informasi yang diberikan oleh penyedia. Lihat Mengelola Pengguna ( iOS , Android , web ).

Pengguna saat ini

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

Saat pengguna keluar, 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 referensinya, Anda masih dapat mengakses dan memperbarui data pengguna.

Siklus hidup pengguna

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

Pendengar Auth akan diberi tahu dalam situasi berikut:

  • Objek Auth selesai diinisialisasi dan pengguna sudah masuk dari sesi sebelumnya, atau telah dialihkan dari alur masuk penyedia identitas
  • Seorang pengguna masuk (pengguna saat ini disetel)
  • Seorang pengguna keluar (pengguna saat ini menjadi nol)
  • Token akses pengguna saat ini disegarkan. Kasus ini dapat terjadi dalam kondisi berikut:
    • Token akses kedaluwarsa: ini adalah situasi umum. Token penyegaran digunakan untuk mendapatkan set token baru yang valid.
    • Pengguna mengubah kata sandi mereka: Firebase mengeluarkan akses baru dan token penyegaran dan membuat token lama kedaluwarsa. Ini secara otomatis membuat token pengguna kedaluwarsa 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, mengatur alamat email utama, dan mengubah kata sandi. Alih-alih mengeluarkan pengguna lalu masuk lagi ke pengguna, 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 keadaan, 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 Firebase console. Dalam kasus ini, Anda dapat menonaktifkan tindakan pengguna dari halaman Setelan Otentikasi Firebase , yang mencegah pembuatan dan penghapusan akun oleh pengguna akhir. Jika Anda menggunakan multi-penyewa, Anda perlu membuat permintaan HTTP untuk menonaktifkan fitur ini per penyewa.

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

Token autentik

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 dalam 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 gabungan, 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 kustom 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 kondisi: 1. Pengguna menyelesaikan alur verifikasi Firebase 2. Email diverifikasi oleh Penyedia Identitas tepercaya, atau disingkat IdP.

IdP yang memverifikasi email sekali, tetapi kemudian mengizinkan pengguna untuk 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 / Kata Sandi tanpa verifikasi email

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

Kasus berikut menjelaskan saat kami menautkan akun secara otomatis dan saat kami membuat 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 memerlukan penautan akun.
  • Pengguna masuk dengan penyedia tepercaya, lalu masuk dengan penyedia tidak tepercaya dengan email yang sama (misalnya, Google diikuti oleh Facebook). Ini menimbulkan kesalahan yang memerlukan 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 secara manual menyetel email sebagai terverifikasi dengan menggunakan Admin SDK, tetapi sebaiknya lakukan ini hanya jika Anda tahu bahwa pengguna benar-benar memiliki email tersebut.