ออบเจ็กต์ Firebase Authentication ผู้ใช้ แสดงถึงบัญชีผู้ใช้ที่ลงชื่อ สมัครใช้แอปใน โปรเจ็กต์ โดยปกติแล้วแอปจะมีผู้ใช้ที่ลงทะเบียนไว้จำนวนมาก และทุกแอปในโปรเจ็กต์จะใช้ฐานข้อมูลผู้ใช้ร่วมกัน
อินสแตนซ์ของผู้ใช้จะแยกจากอินสแตนซ์ของ Firebase Authentication ดังนั้นคุณจึงสามารถมี การอ้างอิงถึงผู้ใช้หลายรายในบริบทเดียวกัน และยังคงเรียกใช้เมธอดของผู้ใช้เหล่านั้นได้
พร็อพเพอร์ตี้ผู้ใช้
Authentication ผู้ใช้จะมีชุดพร็อพเพอร์ตี้พื้นฐานที่กำหนดไว้ ได้แก่ รหัสที่ไม่ซ้ำกัน อีเมลหลัก ชื่อ และ URL รูปภาพ ซึ่งจัดเก็บไว้ใน ฐานข้อมูลผู้ใช้ของโปรเจ็กต์ และผู้ใช้สามารถอัปเดตได้ (iOS, Android, เว็บ) คุณไม่สามารถเพิ่มพร็อพเพอร์ตี้อื่นๆ ลงในออบเจ็กต์ผู้ใช้ได้โดยตรง แต่ให้จัดเก็บพร็อพเพอร์ตี้เพิ่มเติมไว้ในบริการพื้นที่เก็บข้อมูลอื่นๆ เช่น Google Cloud Firestore
เมื่อผู้ใช้ลงชื่อสมัครใช้แอปเป็นครั้งแรก ระบบจะป้อนข้อมูลโปรไฟล์ของผู้ใช้โดยใช้ข้อมูลที่มีอยู่ ดังนี้
- หากผู้ใช้ลงชื่อสมัครใช้ด้วยอีเมลและรหัสผ่าน ระบบจะป้อนเฉพาะพร็อพเพอร์ตี้อีเมลหลัก
- หากผู้ใช้ลงชื่อสมัครใช้ด้วยผู้ให้บริการข้อมูลประจำตัวภายนอก เช่น Google หรือ Facebook ระบบจะใช้ข้อมูลบัญชีที่ผู้ให้บริการให้มาเพื่อป้อนข้อมูลโปรไฟล์ของผู้ใช้
- หากผู้ใช้ลงชื่อสมัครใช้ด้วยระบบการตรวจสอบสิทธิ์ที่กำหนดเอง คุณต้องเพิ่มข้อมูลที่ต้องการลงในโปรไฟล์ของผู้ใช้ด้วยตนเอง
เมื่อสร้างบัญชีผู้ใช้แล้ว คุณสามารถโหลดข้อมูลของผู้ใช้ซ้ำเพื่อรวมการเปลี่ยนแปลงที่ผู้ใช้อาจทำในอุปกรณ์อื่น
ผู้ให้บริการในการลงชื่อเข้าใช้
คุณสามารถให้ผู้ใช้ลงชื่อเข้าใช้แอปได้หลายวิธี ได้แก่ อีเมลและรหัสผ่าน ผู้ให้บริการข้อมูลประจำตัวภายนอก และระบบการตรวจสอบสิทธิ์ที่กำหนดเอง นอกจากนี้ คุณยังเชื่อมโยงวิธีลงชื่อเข้าใช้มากกว่า 1 วิธีกับผู้ใช้ได้ด้วย เช่น ผู้ใช้สามารถลงชื่อเข้าใช้บัญชีเดียวกันโดยใช้อีเมลและรหัสผ่าน หรือใช้การลงชื่อเข้าใช้ด้วยบัญชี Google
อินสแตนซ์ของผู้ใช้จะติดตามผู้ให้บริการทุกรายที่ลิงก์กับผู้ใช้ ซึ่งจะช่วยให้คุณอัปเดตพร็อพเพอร์ตี้ของโปรไฟล์ที่ว่างเปล่าได้โดยใช้ข้อมูลที่ผู้ให้บริการให้มา ดูข้อมูลเพิ่มเติมได้ที่การจัดการผู้ใช้ (iOS, Android, เว็บ)
ผู้ใช้ปัจจุบัน
เมื่อผู้ใช้ลงชื่อสมัครใช้หรือลงชื่อเข้าใช้ ผู้ใช้รายนั้นจะกลายเป็นผู้ใช้ปัจจุบันของอินสแตนซ์ Auth อินสแตนซ์จะเก็บสถานะของผู้ใช้ไว้ เพื่อให้การรีเฟรชหน้า (ในเบราว์เซอร์) หรือการรีสตาร์ทแอปพลิเคชันไม่ทำให้ข้อมูลของผู้ใช้สูญหาย
เมื่อผู้ใช้ออกจากระบบ อินสแตนซ์ Auth จะหยุดเก็บการอ้างอิงถึงออบเจ็กต์ผู้ใช้และไม่เก็บสถานะของผู้ใช้อีกต่อไป จึงไม่มีผู้ใช้ปัจจุบัน อย่างไรก็ตาม อินสแตนซ์ของผู้ใช้จะยังคงทำงานได้อย่างสมบูรณ์ หากคุณเก็บการอ้างอิงถึงอินสแตนซ์ดังกล่าวไว้ คุณจะยังคงเข้าถึงและอัปเดตข้อมูลของผู้ใช้ได้
วงจรของผู้ใช้
วิธีที่แนะนำในการติดตามสถานะปัจจุบันของอินสแตนซ์ Auth คือการใช้ Listener (หรือที่เรียกว่า "Observer" ใน JavaScript) Listener ของ Auth จะได้รับการแจ้งเตือนทุกครั้งที่มีบางอย่างที่เกี่ยวข้องเกิดขึ้นกับออบเจ็กต์ Auth ดูข้อมูลเพิ่มเติมได้ที่การจัดการ ผู้ใช้ (iOS, Android, เว็บ)
Listener ของ Auth จะได้รับการแจ้งเตือนในกรณีต่อไปนี้
- ออบเจ็กต์ Auth เริ่มต้นใช้งานเสร็จสมบูรณ์และผู้ใช้ลงชื่อเข้าใช้จากเซสชันก่อนหน้าแล้ว หรือระบบเปลี่ยนเส้นทางผู้ใช้จากโฟลว์การลงชื่อเข้าใช้ของผู้ให้บริการข้อมูลประจำตัว
- ผู้ใช้ลงชื่อเข้าใช้ (ระบบตั้งค่าผู้ใช้ปัจจุบัน)
- ผู้ใช้ออกจากระบบ (ผู้ใช้ปัจจุบันกลายเป็น Null)
- โทเค็นเพื่อการเข้าถึงของผู้ใช้ปัจจุบันได้รับการรีเฟรช กรณีนี้อาจเกิดขึ้นในเงื่อนไขต่อไปนี้
- โทเค็นเพื่อการเข้าถึงหมดอายุ ซึ่งเป็นสถานการณ์ที่พบได้บ่อย ระบบจะใช้โทเค็นการรีเฟรชเพื่อรับชุดโทเค็นใหม่ที่ใช้งานได้
- ผู้ใช้เปลี่ยนรหัสผ่าน: Authentication จะออกโทเค็นเพื่อการเข้าถึง และโทเค็นการรีเฟรชใหม่ และทำให้โทเค็นเก่าหมดอายุ การดำเนินการนี้จะทำให้โทเค็นของผู้ใช้หมดอายุโดยอัตโนมัติและ/หรือนำผู้ใช้ออกจากระบบในทุกอุปกรณ์ด้วยเหตุผลด้านความปลอดภัย
- ผู้ใช้ตรวจสอบสิทธิ์อีกครั้ง: การดำเนินการบางอย่างกำหนดให้ข้อมูลเข้าสู่ระบบของผู้ใช้ต้องออกให้เมื่อไม่นานมานี้ การดำเนินการดังกล่าว ได้แก่ การลบบัญชี การตั้งค่าอีเมลหลัก และการเปลี่ยนรหัสผ่าน แทนที่จะนำผู้ใช้ออกจากระบบแล้วนำผู้ใช้เข้าสู่ระบบอีกครั้ง ให้ขอข้อมูลเข้าสู่ระบบใหม่จากผู้ใช้ แล้วส่งข้อมูลเข้าสู่ระบบใหม่ไปยังเมธอด reauthenticate ของออบเจ็กต์ผู้ใช้
บริการตนเองของผู้ใช้
โดยค่าเริ่มต้น Firebase Authentication จะอนุญาตให้ผู้ใช้ลงชื่อสมัครใช้และลบบัญชีของตนได้ โดยไม่ต้องมีการแทรกแซงจากผู้ดูแลระบบ ในหลายๆ กรณี การดำเนินการนี้จะช่วยให้ผู้ใช้ปลายทางค้นพบแอปพลิเคชันหรือบริการของคุณและเริ่มต้นใช้งาน (หรือเลิกใช้งาน) ได้อย่างราบรื่น
อย่างไรก็ตาม ในบางกรณี คุณอาจต้องการให้ผู้ดูแลระบบสร้างผู้ใช้ด้วยตนเองหรือ โดยโปรแกรม ไม่ว่าจะใช้ Admin SDK หรือ Firebase คอนโซล ในกรณีดังกล่าว คุณสามารถปิดใช้การดำเนินการของผู้ใช้ จากหน้าการตั้งค่าFirebase Authentication ซึ่งจะป้องกันไม่ให้ผู้ใช้ปลายทางสร้างและลบบัญชี หากคุณใช้การเช่าใช้หลายรายการ คุณจะต้องส่งคำขอ HTTP เพื่อปิดใช้ ฟีเจอร์เหล่านี้สำหรับแต่ละผู้เช่า
หากผู้ใช้ปลายทางพยายามสร้างหรือลบบัญชีภายในระบบ บริการ
Firebase Authentication จะแสดงรหัสข้อผิดพลาด:
auth/admin-restricted-operation สำหรับการเรียก Web API หรือ ERROR_ADMIN_RESTRICTED_OPERATION สำหรับ Android และ iOS คุณควรจัดการข้อผิดพลาดในส่วนหน้าอย่างเหมาะสมโดยขอให้ผู้ใช้ดำเนินการที่เหมาะสมสำหรับบริการของคุณ
โทเค็นการตรวจสอบสิทธิ์
เมื่อทำการตรวจสอบสิทธิ์ด้วย Authentication คุณอาจพบโทเค็นการตรวจสอบสิทธิ์ 3 ประเภท ได้แก่
| โทเค็นรหัสประจำตัวของ Authentication | สร้างโดย Authentication เมื่อผู้ใช้ลงชื่อเข้าใช้แอป โทเค็นเหล่านี้เป็น JWT ที่ลงชื่อแล้วซึ่งระบุตัวผู้ใช้ใน Firebase โปรเจ็กต์อย่างปลอดภัย โทเค็นเหล่านี้มีข้อมูลโปรไฟล์พื้นฐานของผู้ใช้ รวมถึงสตริงรหัสของผู้ใช้ ซึ่งไม่ซ้ำกันสำหรับ Firebase โปรเจ็กต์ เนื่องจาก สามารถยืนยันความสมบูรณ์ของโทเค็นรหัสประจำตัว ได้ คุณจึงส่งโทเค็นเหล่านี้ไปยังเซิร์ฟเวอร์แบ็กเอนด์เพื่อระบุ ผู้ใช้ที่ลงชื่อเข้าใช้อยู่ในปัจจุบันได้ |
| โทเค็นของผู้ให้บริการข้อมูลประจำตัว | สร้างโดยผู้ให้บริการข้อมูลประจำตัวภายนอก เช่น Google และ Facebook โทเค็นเหล่านี้อาจมีรูปแบบที่แตกต่างกัน แต่ส่วนใหญ่มักเป็นโทเค็นเพื่อการเข้าถึง OAuth 2.0 แอปใช้โทเค็นเหล่านี้เพื่อยืนยันว่าผู้ใช้ตรวจสอบสิทธิ์กับผู้ให้บริการข้อมูลประจำตัวเรียบร้อยแล้ว จากนั้นจึงแปลงโทเค็นเป็นข้อมูลเข้าสู่ระบบที่บริการ Authentication ใช้ได้ |
| โทเค็นที่กำหนดเองของ Authentication | สร้างโดยระบบการตรวจสอบสิทธิ์ที่กำหนดเองเพื่อให้ผู้ใช้ลงชื่อเข้าใช้แอป โดยใช้ระบบการตรวจสอบสิทธิ์ของคุณ โทเค็นที่กำหนดเองเป็น JWT ที่ลงชื่อโดยใช้คีย์ส่วนตัวของบัญชีบริการ แอปใช้โทเค็นเหล่านี้ในลักษณะเดียวกับที่ใช้โทเค็นที่ส่งคืนจาก ผู้ให้บริการข้อมูลประจำตัวภายนอก |
อีเมลที่ได้รับการยืนยัน
Authentication จะถือว่าอีเมลได้รับการยืนยันหากเป็นไปตามเงื่อนไข 2 ข้อต่อไปนี้
- ผู้ใช้ทำโฟลว์การยืนยันของ Authentication เสร็จสมบูรณ์
- อีเมลได้รับการยืนยันจากผู้ให้บริการข้อมูลประจำตัวที่เชื่อถือได้ หรือ IdP
IdP ที่ยืนยันอีเมลเพียงครั้งเดียว แต่จากนั้นอนุญาตให้ผู้ใช้เปลี่ยนอีเมลโดยไม่ต้องยืนยันอีกครั้งจะไม่ถือว่าเชื่อถือได้ IdP ที่เป็นเจ้าของโดเมนหรือกำหนดให้ต้องมีการยืนยันเสมอจะถือว่าเชื่อถือได้
ผู้ให้บริการที่เชื่อถือได้
- Google (สำหรับอีเมล @gmail.com)
- Yahoo (สำหรับอีเมล @yahoo.com)
- Microsoft (สำหรับอีเมล @outlook.com และ @hotmail.com)
- Apple (ยืนยันเสมอ เนื่องจากบัญชีได้รับการยืนยันและมีการตรวจสอบสิทธิ์แบบหลายปัจจัยเสมอ)
ผู้ให้บริการที่ไม่เชื่อถือ
- GitHub
- Google, Yahoo และ Microsoft สำหรับโดเมนที่ไม่ได้ออกโดยผู้ให้บริการข้อมูลประจำตัวรายนั้น
- อีเมล / รหัสผ่านที่ไม่มีการยืนยันอีเมล
ในบางกรณี Authentication จะลิงก์บัญชีโดยอัตโนมัติเมื่อผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการรายต่างๆ โดยใช้อีเมลเดียวกัน อย่างไรก็ตาม การดำเนินการนี้จะเกิดขึ้นได้ก็ต่อเมื่อเป็นไปตามเกณฑ์ที่เฉพาะเจาะจงเท่านั้น โปรดพิจารณาสถานการณ์ต่อไปนี้เพื่อทำความเข้าใจเหตุผล: ผู้ใช้ลงชื่อเข้าใช้ด้วยบัญชี Google ที่มีอีเมล @gmail.com และผู้ไม่ประสงค์ดีสร้างบัญชีโดยใช้อีเมล @gmail.com เดียวกัน แต่ลงชื่อเข้าใช้ผ่าน Facebook หากระบบลิงก์บัญชีทั้ง 2 บัญชีนี้โดยอัตโนมัติ ผู้ไม่ประสงค์ดีจะได้รับสิทธิ์เข้าถึงบัญชีของผู้ใช้
กรณีต่อไปนี้อธิบายถึงเวลาที่ระบบลิงก์บัญชีโดยอัตโนมัติและเวลาที่ระบบแสดงข้อผิดพลาดที่กำหนดให้ผู้ใช้หรือนักพัฒนาแอปต้องดำเนินการ
- ผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการที่ไม่เชื่อถือ จากนั้นลงชื่อเข้าใช้ด้วยผู้ให้บริการที่ไม่เชื่อถือรายอื่นโดยใช้อีเมลเดียวกัน (เช่น Facebook ตามด้วย GitHub) การดำเนินการนี้จะแสดงข้อผิดพลาดที่กำหนดให้ต้องลิงก์บัญชี
- ผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการที่เชื่อถือได้ จากนั้นลงชื่อเข้าใช้ด้วยผู้ให้บริการที่ไม่เชื่อถือโดยใช้อีเมลเดียวกัน (เช่น Google ตามด้วย Facebook) การดำเนินการนี้จะแสดงข้อผิดพลาดที่กำหนดให้ต้องลิงก์บัญชี
- ผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการที่ไม่เชื่อถือ จากนั้นลงชื่อเข้าใช้ด้วยผู้ให้บริการที่เชื่อถือได้โดยใช้อีเมลเดียวกัน (เช่น Facebook ตามด้วย Google) ผู้ให้บริการที่เชื่อถือได้จะเขียนทับผู้ให้บริการที่ไม่เชื่อถือ หากผู้ใช้พยายามลงชื่อเข้าใช้อีกครั้งด้วย Facebook การดำเนินการนี้จะทำให้เกิดข้อผิดพลาดที่กำหนดให้ต้องลิงก์บัญชี
- ผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการที่เชื่อถือได้ จากนั้นลงชื่อเข้าใช้ด้วยผู้ให้บริการที่เชื่อถือได้รายอื่นโดยใช้อีเมลเดียวกัน (เช่น Apple ตามด้วย Google) ระบบจะลิงก์ผู้ให้บริการทั้ง 2 รายโดยไม่มีข้อผิดพลาด
คุณสามารถตั้งค่าอีเมลเป็นยืนยันแล้วด้วยตนเองโดยใช้ Admin SDK แต่เราขอแนะนำให้ดำเนินการนี้เฉพาะในกรณีที่คุณทราบว่าผู้ใช้เป็นเจ้าของอีเมลนั้นจริงๆ