Người dùng trong các dự án Firebase

Đối tượng người dùng Firebase đại diện cho một tài khoản người dùng đã đăng ký một ứng dụng trong dự án của bạn. Ứng dụng thường có nhiều người dùng đã đăng ký và mọi ứng dụng trong dự án đều chia sẻ cơ sở dữ liệu người dùng.

Các phiên bản người dùng độc lập với các phiên bản Xác thực Firebase, vì vậy bạn có thể có một số tham chiếu đến những người dùng khác nhau trong cùng một ngữ cảnh và vẫn gọi bất kỳ phương thức nào của họ.

Thuộc tính người dùng

Người dùng Firebase có một bộ thuộc tính cơ bản cố định—ID duy nhất, địa chỉ email chính, tên và URL ảnh—được lưu trữ trong cơ sở dữ liệu người dùng của dự án, người dùng có thể cập nhật các thuộc tính này ( iOS , Android , web ). Bạn không thể thêm trực tiếp các thuộc tính khác vào đối tượng người dùng; thay vào đó, bạn có thể lưu trữ các thuộc tính bổ sung trong bất kỳ dịch vụ lưu trữ nào khác, chẳng hạn như Google Cloud Firestore.

Lần đầu tiên người dùng đăng ký ứng dụng của bạn, dữ liệu hồ sơ của người dùng được điền bằng thông tin có sẵn:

  • Nếu người dùng đã đăng ký bằng địa chỉ email và mật khẩu, thì chỉ có thuộc tính địa chỉ email chính được điền
  • Nếu người dùng đã đăng ký với nhà cung cấp danh tính được liên kết, chẳng hạn như Google hoặc Facebook, thì thông tin tài khoản do nhà cung cấp cung cấp sẽ được sử dụng để điền vào hồ sơ của người dùng
  • Nếu người dùng đã đăng ký với hệ thống xác thực tùy chỉnh của bạn, bạn phải thêm rõ ràng thông tin bạn muốn vào hồ sơ của người dùng

Khi tài khoản người dùng đã được tạo, bạn có thể tải lại thông tin của người dùng để kết hợp bất kỳ thay đổi nào mà người dùng có thể đã thực hiện trên thiết bị khác.

Nhà cung cấp đăng nhập

Bạn có thể đăng nhập người dùng vào ứng dụng của mình bằng một số phương pháp: địa chỉ email và mật khẩu, nhà cung cấp danh tính được liên kết và hệ thống xác thực tùy chỉnh của bạn. Bạn có thể liên kết nhiều phương thức đăng nhập với một người dùng: ví dụ: người dùng có thể đăng nhập vào cùng một tài khoản bằng địa chỉ email và mật khẩu hoặc sử dụng Đăng nhập bằng Google.

Phiên bản người dùng theo dõi mọi nhà cung cấp được liên kết với người dùng. Điều này cho phép bạn cập nhật các thuộc tính của hồ sơ trống bằng cách sử dụng thông tin do nhà cung cấp cung cấp. Xem Quản lý người dùng ( iOS , Android , web ).

Người dùng hiện tại

Khi người dùng đăng ký hoặc đăng nhập, người dùng đó sẽ trở thành người dùng hiện tại của phiên bản Auth. Phiên bản duy trì trạng thái của người dùng, do đó việc làm mới trang (trong trình duyệt) hoặc khởi động lại ứng dụng không làm mất thông tin của người dùng.

Khi người dùng đăng xuất, phiên bản Auth ngừng giữ tham chiếu đến đối tượng người dùng và không còn duy trì trạng thái của nó nữa; không có người dùng hiện tại. Tuy nhiên, phiên bản người dùng vẫn tiếp tục hoạt động hoàn toàn: nếu bạn giữ tham chiếu đến nó, bạn vẫn có thể truy cập và cập nhật dữ liệu của người dùng.

Vòng đời người dùng

Cách được đề xuất để theo dõi trạng thái hiện tại của phiên bản Auth là sử dụng trình nghe (còn được gọi là "trình quan sát" trong JavaScript). Người nghe Auth được thông báo bất cứ khi nào có điều gì đó liên quan xảy ra với đối tượng Auth. Xem Quản lý người dùng ( iOS , Android , web ).

Người nghe Auth được thông báo trong các trường hợp sau:

  • Đối tượng Auth kết thúc quá trình khởi tạo và người dùng đã đăng nhập từ phiên trước đó hoặc đã được chuyển hướng từ luồng đăng nhập của nhà cung cấp danh tính
  • Người dùng đăng nhập (người dùng hiện tại được đặt)
  • Người dùng đăng xuất (người dùng hiện tại trở thành null)
  • Mã thông báo truy cập của người dùng hiện tại được làm mới. Trường hợp này có thể xảy ra trong các điều kiện sau:
    • Mã thông báo truy cập hết hạn: đây là trường hợp phổ biến. Mã thông báo làm mới được sử dụng để nhận một bộ mã thông báo hợp lệ mới.
    • Người dùng thay đổi mật khẩu của họ: Firebase cấp mã thông báo truy cập và làm mới, đồng thời hiển thị mã thông báo cũ đã hết hạn. Điều này sẽ tự động làm hết hạn mã thông báo của người dùng và/hoặc đăng xuất người dùng trên mọi thiết bị vì lý do bảo mật.
    • Người dùng xác thực lại: một số hành động yêu cầu thông tin đăng nhập của người dùng được cấp gần đây; những hành động đó bao gồm xóa tài khoản, đặt địa chỉ email chính và thay đổi mật khẩu. Thay vì đăng xuất người dùng rồi đăng nhập lại người dùng, hãy nhận thông tin đăng nhập mới từ người dùng và chuyển thông tin đăng nhập mới cho phương thức xác thực lại của đối tượng người dùng.

Người dùng tự phục vụ

Theo mặc định, Firebase cho phép người dùng đăng ký và xóa tài khoản của họ mà không cần sự can thiệp của quản trị viên. Trong nhiều trường hợp, điều này cho phép người dùng cuối khám phá ứng dụng hoặc dịch vụ của bạn và tích hợp (hoặc không hoạt động) với ít ma sát nhất.

Tuy nhiên, có những trường hợp bạn muốn quản trị viên tạo người dùng theo cách thủ công hoặc theo chương trình, bằng cách sử dụng SDK dành cho quản trị viên hoặc bảng điều khiển Firebase. Trong những trường hợp này, bạn có thể vô hiệu hóa hành động của người dùng từ trang Cài đặt xác thực Firebase , điều này ngăn người dùng cuối tạo và xóa tài khoản. Nếu bạn đang sử dụng nhiều bên thuê, bạn sẽ cần thực hiện một yêu cầu HTTP để tắt các tính năng này trên cơ sở từng bên thuê.

Nếu người dùng cuối cố gắng tạo hoặc xóa tài khoản trong hệ thống của bạn, thì dịch vụ Firebase sẽ trả về mã lỗi: auth/admin-restricted-operation đối với lệnh gọi API Web hoặc ERROR_ADMIN_RESTRICTED_OPERATION đối với Android và iOS. Bạn nên xử lý lỗi trên giao diện người dùng của mình một cách duyên dáng bằng cách yêu cầu người dùng thực hiện các hành động thích hợp cho dịch vụ của bạn.

Mã thông báo xác thực

Khi bạn thực hiện xác thực với Firebase, có ba loại mã thông báo xác thực mà bạn có thể gặp phải:

Mã thông báo ID Firebase Được tạo bởi Firebase khi người dùng đăng nhập vào một ứng dụng. Các mã thông báo này là JWT đã ký xác định người dùng một cách an toàn trong dự án Firebase. Các mã thông báo này chứa thông tin hồ sơ cơ bản của người dùng, bao gồm cả chuỗi ID của người dùng, chuỗi này là duy nhất đối với dự án Firebase. Vì tính toàn vẹn của mã thông báo ID có thể được xác minh nên bạn có thể gửi chúng đến máy chủ phụ trợ để xác định người dùng hiện đang đăng nhập.
Mã thông báo nhà cung cấp danh tính Được tạo bởi các nhà cung cấp danh tính có liên kết, chẳng hạn như Google và Facebook. Các mã thông báo này có thể có các định dạng khác nhau, nhưng thường là mã thông báo truy cập OAuth 2.0. Ứng dụng sử dụng các mã thông báo này để xác minh rằng người dùng đã xác thực thành công với nhà cung cấp danh tính, sau đó chuyển đổi chúng thành thông tin đăng nhập mà dịch vụ Firebase có thể sử dụng.
Mã thông báo tùy chỉnh Firebase Được tạo bởi hệ thống xác thực tùy chỉnh của bạn để cho phép người dùng đăng nhập vào ứng dụng bằng hệ thống xác thực của bạn. Mã thông báo tùy chỉnh là JWT được ký bằng khóa riêng của tài khoản dịch vụ . Các ứng dụng sử dụng các mã thông báo này giống như chúng sử dụng các mã thông báo được trả lại từ các nhà cung cấp danh tính được liên kết.

Địa chỉ email đã xác minh

Firebase coi email đã được xác minh nếu đáp ứng hai điều kiện:

  1. Người dùng hoàn thành quy trình xác minh Firebase
  2. Email được xác minh bởi Nhà cung cấp danh tính đáng tin cậy hoặc viết tắt là IdP.

IdP xác minh email một lần, nhưng sau đó cho phép người dùng thay đổi địa chỉ email mà không yêu cầu xác minh lại, không được tin cậy. IdP sở hữu miền hoặc luôn yêu cầu xác minh được coi là đáng tin cậy.

Các nhà cung cấp đáng tin cậy:

  • Google (đối với địa chỉ @gmail.com)
  • Yahoo (đối với địa chỉ @yahoo.com)
  • Microsoft (đối với địa chỉ @outlook.com và @hotmail.com)
  • Apple (luôn được xác minh, vì tài khoản luôn được xác minh và xác thực bằng nhiều yếu tố)

Nhà cung cấp không đáng tin cậy:

  • Facebook
  • Twitter
  • GitHub
  • Google, Yahoo và Microsoft đối với các miền không do Nhà cung cấp danh tính đó cấp
  • Email/Mật khẩu không cần xác minh email

Trong một số trường hợp, Firebase sẽ tự động liên kết các tài khoản khi người dùng đăng nhập bằng các nhà cung cấp khác nhau bằng cùng một địa chỉ email. Tuy nhiên, điều này chỉ có thể xảy ra khi các tiêu chí cụ thể được đáp ứng. Để hiểu lý do tại sao, hãy xem xét tình huống sau: người dùng đăng nhập bằng Google bằng tài khoản @gmail.com và kẻ xấu tạo tài khoản bằng cùng địa chỉ @gmail.com nhưng đăng nhập qua Facebook. Nếu hai tài khoản này được liên kết tự động, tác nhân độc hại sẽ có quyền truy cập vào tài khoản của người dùng.

Các trường hợp sau đây mô tả khi chúng tôi tự động liên kết các tài khoản và khi chúng tôi đưa ra lỗi yêu cầu hành động của người dùng hoặc nhà phát triển:

  • Người dùng đăng nhập bằng một nhà cung cấp không đáng tin cậy, sau đó đăng nhập bằng một nhà cung cấp không đáng tin cậy khác bằng cùng một email (ví dụ: Facebook theo sau là GitHub). Điều này gây ra lỗi yêu cầu liên kết tài khoản.
  • Người dùng đăng nhập bằng một nhà cung cấp đáng tin cậy, sau đó đăng nhập bằng nhà cung cấp không đáng tin cậy bằng cùng một email (ví dụ: Google theo sau là Facebook). Điều này gây ra lỗi yêu cầu liên kết tài khoản.
  • Người dùng đăng nhập bằng một nhà cung cấp không đáng tin cậy, sau đó đăng nhập bằng một nhà cung cấp đáng tin cậy có cùng email (ví dụ: Facebook theo sau là Google). Nhà cung cấp đáng tin cậy sẽ ghi đè lên nhà cung cấp không đáng tin cậy. Nếu người dùng cố gắng đăng nhập lại bằng Facebook, nó sẽ gây ra lỗi yêu cầu liên kết tài khoản.
  • Người dùng đăng nhập bằng một nhà cung cấp đáng tin cậy, sau đó đăng nhập bằng một nhà cung cấp đáng tin cậy khác bằng cùng một email (ví dụ: Apple theo sau là Google). Cả hai nhà cung cấp sẽ được liên kết mà không có lỗi.

Bạn có thể đặt email là đã được xác minh theo cách thủ công bằng cách sử dụng SDK dành cho quản trị viên, nhưng chúng tôi khuyên bạn chỉ nên thực hiện việc này nếu bạn biết người dùng thực sự sở hữu email đó.