พื้นหลัง#
ฉันเคยเห็นนักพัฒนาเป็นจำนวนมากถามคำถามเช่น "ฉันควรสร้างการยืนยันตัวตนของตัวเองสำหรับแอปของฉันหรือไม่?" ในขณะที่คำตอบไม่สามารถเป็น "ใช่" หรือ "ไม่" ง่ายๆ ฉันอยากจะเขียนบทความเพื่อแยกย่อยการนำไปใช้และอธิบายข้อดีและข้อเสียเพื่อช่วยให้คุณตัดสินใจได้
สรุปสั้นๆ จำเป็นต้องหาวิธีที่มีอยู่แล้วที่เหมาะกับความต้องการของคุณ ยกเว้นว่าคุณต้องการควบคุมทั้งหมดหรือคุณยังคงเรียนรู้การพัฒนาซอฟต์แวร์
แนะนำ#
ในฐานะนักพัฒนา ฉันได้สร้างแอปพลิเคชันมากมายในระหว่างอาชีพของฉัน ไม่ว่าจะเป็นภาษาโปรแกรมใด ก็จะมีพื้นฐานร่วมกันที่ฉันต้องสร้างเสมอ: การยืนยันตัวตนผู้ใช้
มันเป็นส่วนน้อยที่ถูกมองข้ามเพราะทุกอย่างเป็นเรื่องง่ายเมื่อย้อนกลับไป 20 ปี:
- สร้างระบบลงทะเบียนและเข้าสู่ระบบด้วยชื่อผู้ใช้และรหัสผ่าน
- สร้างกลไกในการรักษาข้อมูลการระบบผู้ใช้
- เรื่องความปลอดภัย? MD5 คือคำตอบ
แค่นั้น แล้วฉันก็สามารถมุ่งเน้นไปที่ "ธุรกิจจริง" ได้เลย ไม่เคยได้ยินเกี่ยวกับ MD5 เหรอ? คุณพลาด "ช่วงเวลาที่ดี" ของการพัฒนาซอฟต์แวร์ สมัยนี้ นักพัฒนาต้องเผชิญกับความท้าทายมากขึ้นเมื่อสร้างการลงชื่อเข้าใช้หรือสมัคร
มันฟังดูเกรงขาม แต่ให้ฉันอธิบายด้วยตัวอย่าง
ตัวอย่าง: ร้านหนังสือออนไลน์#
ลองสมมติว่าคุณพยายามสร้างร้านหนังสือออนไลน์พร้อมบริการ API และแอป frontend สำหรับเว็บ
ก่อนอื่น ขอบเขตของ "การยืนยันตัวตน" ควรกำหนดไว้ โดยที่การยืนยันตัวตนสามารถอธิบายได้ว่าเป็นการตรวจสอบและการอนุญาต และพวกเขามีคำจำกัดความและการใช้งานที่แตกต่างกันโดยสิ้นเชิง:
ฉันเขียนบทความ CIAM 101: การตรวจสอบ, เอกลักษณ์, SSO เพื่ออภิปรายแนวคิดเหล่านี้อย่างละเอียด
เลือกวิธีการตรวจสอบ#
เริ่มด้วย "การตรวจสอบ" ซึ่งเป็นการเข้าสู่ระบบของผู้ใช้ในตัวอย่างของเรา นอกเหนือจากวิธีการชื่อผู้ใช้และรหัสผ่าน นี่คือวิธีฮิตบางที่ผู้คนนำมาใช้เพื่อการเปลี่ยนผู้ใช้และความปลอดภัยที่ดียิ่งขึ้น:
- ไม่มีรหัสผ่าน, เช่น รหัสยืนยันไดนามิก (ผ่านอีเมลหรือ sms)
- การเข้าสู่ระบบโดยใช้โซเชียล (Google, Facebook, เป็นต้น)
การเลือกวิธีก็ขึ้นอยู่กับการตัดสินใจทางธุรกิจ ในขณะที่เราสามารถตรวจสอบความพยายามทางเทคโนโลยีได้:
- สำหรับไม่มีรหัสผ่าน คุณจำเป็นต้องหาผู้จำหน่ายเพื่อส่งรหัสยืนยันผ่านอีเมลหรือ sms แล้วบูรณาการกับบริการ API ของคุณ (อาจต้องใช้ API ใหม่)
- สำหรับการเข้าสู่ระบบโดยใช้โซเชียล คุณต้องปฏิบัติตามแนวทางการบูรณาการของผู้ให้บริการเอกลักษณ์โซเชียลที่คุณต้องการใช้ นอกจากนี้ คุณต้องสร้างแผนที่ระหว่าง IDs ผู้ใช้ของร้านหนังสือของคุณและของผู้ให้บริการเอกลักษณ์
- ยกตัวอย่างเช่น เมื่อผู้ใช้เข้าสู่ระบบด้วยบัญชี Gmail
[email protected] คุณสามารถเชื่อมโยงที่อยู่อีเมลนี้กับผู้ใช้ foo ในร้านหนังสือได้ ขั้นตอนนี้ช่วยให้คุณสร้างระบบเอกลักษณ์แบบรวมและอนุญาตให้ผู้ใช้ปรับเปลี่ยนหรือแยกเอกลักษณ์โซเชียลของพวกเขาในอนาคตได้
ออกแบบและดำเนินการประสบการณ์การเข้าสู่ระบบ#
เมื่อคุณตัดสินใจวิธีการตรวจสอบแล้ว ประสบการณ์การเข้าสู่ระบบที่ราบรื่นและนุ่มนวลสำหรับผู้ใช้สุดท้ายของคุณคือเป้าหมายต่อไป การแปลงที่นี่เป็นพื้นฐานแต่สำคัญต่อธุรกิจเพราะมันคือวิธีที่เป็นธรรมชาติในการทิ้งข้อมูลลูกค้าที่คงตัว
เมื่อฉันทำงานที่ Airbnb มีทีมทั้งทีมที่มุ่งปรับปรุงประสบการณ์การเข้าสู่ระบบสำหรับหลายแพลตฟอร์ม พวกเขาดำเนินการทดสอบ A/B จำนวนมากเพื่อกำหนดว่าการรวมกันใดมีอัตราการแปลงสูงสุด
มันไม่สามารถทำได้เมื่อธุรกิจเริ่มต้น แต่เราจำเป็นต้องลองทำให้ได้ดีที่สุดทุกชิ้น คุณต้องการรันร้านหนังสือนี้บนแพลตฟอร์มใดบ้าง? คุณอาจเริ่มต้นด้วยมือถือ เว็บหรือทั้งสองอย่าง การออกแบบที่แน่นอนจะขึ้นอยู่กับวิธีการตรวจสอบที่คุณเลือก:
- ชื่อผู้ใช้และรหัสผ่าน: วิธีที่ง่ายที่สุด แค่กล่องใส่ข้อมูลและปุ่มสองสามอย่าง
- ไม่มีรหัสผ่าน: ใส่หมายเลขโทรศัพท์ / อีเมล จากนั้นส่งและยืนยันรหัสไดนามิก
- การเข้าสู่ระบบโดยใช้โซเชียล: อ่านเอกสารจากผู้ให้บริการเอกลักษณ์โซเชียลที่เลือก ปฏิบัติตามไกด์ไลน์การแสดงผล จัดการตรรกะการเปลี่ยนเส้นทาง และลิงค์เอกลักษณ์โซเชียลกับเอกลักษณ์ของร้านหนังสือ
สิ่งที่ต้องพิจารณาเพิ่มเติมเพื่อทำให้ดีขึ้น:
- คุณต้องร่วมกระบวนการเข้าสู่ระบบและการลงทะเบียนสำหรับวิธีเฉพาะหรือไม่?
- คุณต้องใช้กระบวนการ "ลืมรหัสผ่าน" เพื่ออนุญาตให้ลูกค้ารีเซ็ตรหัสผ่านด้วยตัวเองหรือไม่?
หากคุณเลือกการพัฒนาที่เป็นธรรมชาติ งานจะเพิ่มขึ้นเกือบสองเท่าสำหรับแพลตฟอร์มเพิ่มเติม
ความปลอดภัยและการแลกเปลี่ยนโทเค็น#
ความปลอดภัยอาจเป็นภูเขาน้ำแข็งที่ซ่อนอยู่ มันจะดีถ้าคุณคุ้นเคยกับ OpenID Connect หรือ OAuth 2.0 เพราะมันเป็นที่ใช้งานกันอย่างแพร่หลายและทดสอบแล้ว OpenID Connect ค่อนข้างใหม่แต่ถูกออกแบบมาเพื่อ "การยืนยันตัวตนของผู้ใช้" ซึ่งเหมาะสำหรับร้านหนังสือออนไลน์
โดยไม่เจาะลึกถึงรายละเอียดของมาตรฐาน ยังมีสิ่งที่ควรพิจารณา:
- ควรใช้วิธีการเข้ารหัสใดสำหรับรหัสผ่าน?
- กระบวนการตรวจสอบและการอนุญาตมาตรฐานคืออะไร?
- การแลกเปลี่ยนโทเค็นทำงานอย่างไร (Access Token, Refresh Token, ID Token, เป็นต้น)?
- จะใช้กุญแจเซ็นในโทเค็นและตรวจสอบลายเซ็นเหล่านั้นได้อย่างไรเพื่อปกป้องทรัพยากร?
- จะป้องกันการโจมตีจากไคลเอนต์และเซิร์ฟเวอร์ได้อย่างไร?
สุดท้ายคุณสามารถสร้างประสบการณ์การเข้าสู่ระบบที่ดีและส่งมอบให้กับลูกค้าของคุณได้
โมเดลการอนุญาต#
ในฐานะร้านหนังสือ คุณต้องแยกทรัพยากรสำหรับลูกค้าและผู้ขาย ยกตัวอย่างเช่น ลูกค้าสามารถเรียกดูหนังสือทั้งหมดได้ ในขณะที่ผู้ขายสามารถจัดการหนังสือที่ขายอยู่ของพวกเขาได้ มันไม่เป็นไรที่จะเริ่มต้นด้วยการตรวจสอบ if-else ง่าย ๆ แต่เมื่อธุรกิจเติบโตขึ้น คุณอาจจำเป็นต้องใช้โมเดลที่ยืดหยุ่นกว่าราวกับ Role-based Access Control (RBAC) หรือ Attribute-based Access Control (ABAC)
ฉันเขียนบทความ CIAM 102: การอนุญาต & การควบคุมการเข้าถึงทั่วไป เพื่อแสดงแนวคิดการอนุญาตพื้นฐานและโมเดล RBAC
ทำการตัดสินใจ#
คุณจะเห็นว่าการยืนยันตัวตนไม่ใช่ปัญหา "ทั้งหมดหรือไม่มีอะไร" เพราะมันเกี่ยวข้องกับหลากหลายส่วนประกอบทางเทคนิคและคุณหรือทีมของคุณอาจมีความเชี่ยวชาญทางเทคนิคต่างกันในพื้นที่เหล่านี้ การแบ่งเป็นส่วนย่อย ๆ เป็นเรื่องสำคัญเพื่อให้เข้าใจสถานะปัจจุบันได้ดียิ่งขึ้น
เพื่อทำการตัดสินใจ ฉันจะถามตัวเองคำถามต่อไปนี้:
- โครงการมีความเร่งด่วนแค่ไหน?
- ฉันคาดหวังจะใส่ความพยายามเกี่ยวกับการยืนยันตัวตนเทียบกับธุรกิจอย่างไร?
- อะไรคือความสำคัญของประสบการณ์ผู้ใช้ ความปลอดภัย และการบำรุงรักษา?
- ฉันต้องควบคุมส่วนใด (หรือบางส่วน) อย่างเต็มที่? ฉันควรคุ้นเคยกับมันถึงขนาดไหน?
- ถ้าฉันไปกับกรอบงาน / โซลูชั่นบางอย่าง พวกมันดีพอสำหรับการปรับแต่งหรือขยายตัวหรือไม่?
- ถ้าธุรกิจเติบโตขึ้น ฉันจะต้องแนะนำโมเดลการตรวจสอบใหม่หรือไม่?
- ถ้าฉันพบผู้จำหน่ายที่เหมาะสม มันปลอดภัยพอที่จะใช้หรือไม่? ฉันต้องการแผนการถอนตัวถ้ามีเหตุการณ์ที่ส่งผลกับผู้จำหน่ายหรือไม่?
ด้วยคำถามต่าง ๆ ในใจ ฉันค้นพบความจริงสองอย่าง:
- การสร้างระบบการยืนยันตัวตนที่เชื่อถือได้มีความซับซ้อนอย่างสูง
- ผู้จำหน่ายที่มีอยู่ไม่สามารถตอบสนองทุกเกณฑ์ที่จำเป็นได้
ดังนั้นฉันจึงตัดสินใจเริ่มโครงการที่เน้นเฉพาะ (Logto) สำหรับการยืนยันตัวตน และยอมรับชุมชนโอเพ่นซอร์สตั้งแต่วันแรก
หวังว่าบทความนี้จะเป็นประโยชน์
