Đối tượng Firebase Authentication user (người dùng) đạ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. Các ứng dụng thường có nhiều người dùng đã đăng ký và mọi ứng dụng trong một dự án đều dùng chung một cơ sở dữ liệu người dùng.
Các thực thể người dùng độc lập với các thực thể Firebase Authentication, vì vậy, bạn có thể có nhiều tham chiếu đến những người dùng khác nhau trong cùng một bối cảnh và vẫn gọi được bất kỳ phương thức nào của họ.
Thuộc tính người dùng
Người dùng Authentication có một bộ thuộc tính cơ bản cố định (một mã nhận dạng duy nhất, một địa chỉ email chính, một tên và một 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 sẽ được điền sẵ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ỉ thuộc tính địa chỉ email chính được điền sẵn
- Nếu người dùng đăng ký bằng một nhà cung cấp dịch vụ danh tính 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 dùng để điền sẵn vào hồ sơ của người dùng
- Nếu người dùng đăng ký bằng hệ thống xác thực tuỳ chỉnh của bạn, thì bạn phải thêm thông tin bạn muốn vào hồ sơ người dùng một cách rõ ràng
Sau khi tạo tài khoản người dùng, bạn có thể tải lại thông tin của người dùng để kết hợp mọi thay đổi mà người dùng có thể đã thực hiện trên một thiết bị khác.
Nhà cung cấp dịch vụ đă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 nhiều phương thức: địa chỉ email và mật khẩu, nhà cung cấp danh tính liên kết và hệ thống xác thực tuỳ chỉnh. 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 bằng tính năng Đăng nhập bằng Google.
Các 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 thông tin do nhà cung cấp cung cấp. Xem phần 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 thực thể Auth. Phiên bản này 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 sẽ 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 sẽ ngừng lưu giữ thông tin tham chiếu đến đối tượng người dùng và không còn duy trì trạng thái của đối tượng đó 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 hoàn toàn hoạt động: nếu giữ lại một tệp tham chiếu đến phiên bả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 của 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). Trình nghe Auth sẽ nhận đượ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 phần Quản lý người dùng (iOS, Android, web).
Trình nghe Auth sẽ nhận được thông báo trong các trường hợp sau:
- Đối tượng Auth hoàn tất quá trình khởi tạo và người dùng đã đăng nhập từ một phiên trước hoặc đã được chuyển hướng từ quy trình đă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 giá trị rỗng)
- Mã truy cập của người dùng hiện tại sẽ đượ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ã truy cập hết hạn: đây là một tình huống thường gặp. Mã làm mới được 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: Authentication phát hành mã truy cập và mã làm mới mới, đồng thời khiến mã cũ hết hạn. Thao tác này sẽ tự động 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ố thao tác yêu cầu thông tin đăng nhập của người dùng được cấp gần đây; những thao tác như vậy bao gồm xoá 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, hãy lấy thông tin đăng nhập mới từ người dùng và truyền thông tin đăng nhập mới đó vào phương thức xác thực lại của đối tượng người dùng.
Tự phục vụ cho người dùng
Theo mặc định, Firebase Authentication cho phép người dùng đăng ký và xoá 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 giúp người dùng cuối khám phá ứng dụng hoặc dịch vụ của bạn và tham gia (hoặc ngừng sử dụng) với mức độ khó khăn tối thiểu.
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 lập 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ể tắt các thao tác của người dùng trên trang Firebase Authentication Cài đặt. Thao tác này sẽ ngăn người dùng cuối tạo và xoá tài khoản. Nếu đang sử dụng mô hình nhiều đối tượng 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 theo từng đối tượng thuê.
Nếu người dùng cuối cố gắng tạo hoặc xoá tài khoản trong hệ thống của bạn, dịch vụ Firebase Authentication sẽ trả về mã lỗi: auth/admin-restricted-operation cho các lệnh gọi Web API hoặc ERROR_ADMIN_RESTRICTED_OPERATION cho Android và iOS. Bạn nên xử lý lỗi một cách thích hợp trên giao diện người dùng bằng cách yêu cầu người dùng thực hiện các hành động phù hợp cho dịch vụ của bạn.
Mã thông báo xác thực
Khi xác thực bằng Authentication, bạn có thể gặp phải 3 loại mã thông báo xác thực:
| Authentication mã nhận dạng | Được tạo bởi Authentication 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ý, giúp 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 cơ bản về hồ sơ của người dùng, bao gồm cả chuỗi mã nhận dạng người dùng (chỉ có trong dự án Firebase). Vì bạn có thể xác minh tính toàn vẹn của mã thông báo nhận dạng, nên bạn có thể gửi mã thông báo này đến một máy chủ phụ trợ để xác định người dùng hiện đã đăng nhập. |
| Mã thông báo của nhà cung cấp dịch vụ danh tính | Do các nhà cung cấp danh tính được liên kết tạo, chẳng hạn như Google và Facebook. Các mã thông báo này có thể có nhiều định dạng, nhưng thường là mã truy cập OAuth 2.0. Các ứng dụng sử dụng những 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 những mã thông báo này thành thông tin đăng nhập mà các dịch vụ Authentication có thể sử dụng. |
| Authentication mã thông báo tuỳ chỉnh | Do hệ thống xác thực tuỳ chỉnh của bạn tạo ra để cho phép người dùng đăng nhập vào một ứng dụng bằng hệ thống xác thực của bạn. Mã thông báo tuỳ chỉnh là JWT được ký bằng khoá riêng tư của tài khoản dịch vụ. Các ứng dụng sử dụng những mã thông báo này tương tự như cách chúng sử dụng mã thông báo do nhà cung cấp danh tính liên kết trả về. |
Địa chỉ email đã xác minh
Authentication coi một email là đã xác minh nếu email đó đáp ứng 2 điều kiện:
- Người dùng hoàn tất quy trình xác minh Authentication
- Email này được xác minh bởi một Nhà cung cấp danh tính (IdP) đáng tin cậy.
Các 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, sẽ không được tin cậy. Những IdP sở hữu miền hoặc luôn yêu cầu xác minh được coi là đáng tin cậy.
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 đa yếu tố)
Nhà cung cấp không đáng tin cậy:
- GitHub
- Google, Yahoo và Microsoft cho những miền không do Nhà cung cấp dịch vụ danh tính đó phát hành
- Email / Mật khẩu không có quy trình xác minh email
Trong một số trường hợp, Authentication sẽ tự động liên kết các tài khoản khi người dùng đăng nhập bằng nhiều nhà cung cấp khác nhau nhưng sử dụng cùng một địa chỉ email. Tuy nhiên, điều này chỉ có thể xảy ra khi bạn đáp ứng các tiêu chí cụ thể. Để hiểu lý do, hãy xem xét tình huống sau: một người dùng đăng nhập bằng Google bằng tài khoản @gmail.com và một đối tượng xấu tạo tài khoản bằng chính đị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, thì kẻ xấu 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ả thời điểm chúng tôi tự động liên kết các tài khoản và thời điểm chúng tôi đưa ra lỗi yêu cầu người dùng hoặc nhà phát triển thực hiện hành động:
- 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 rồi đến GitHub). Thao tác này 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 nhà cung cấp không đáng tin cậy bằng cùng một email (ví dụ: Google, sau đó là Facebook). Thao tác này 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 không đáng tin cậy, sau đó đăng nhập bằng một nhà cung cấp đáng tin cậy bằng cùng một email (ví dụ: Facebook, sau đó là Google). Nhà cung cấp đáng tin cậy sẽ ghi đè 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, thì sẽ xả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, sau đó là Google). Cả hai nhà cung cấp sẽ được liên kết mà không gặp lỗi.
Bạn có thể đặt email thành đã xác minh theo cách thủ công bằng SDK dành cho quản trị viên, nhưng bạn chỉ nên làm việc này nếu biết người dùng thực sự sở hữu email đó.