คุณจำเป็นต้องสร้างการยืนยันตัวตนของตัวเองสำหรับแอปหรือไม่?

พื้นหลัง#

ฉันเคยเห็นนักพัฒนาเป็นจำนวนมากถามคำถามเช่น "ฉันควรสร้างการยืนยันตัวตนของตัวเองสำหรับแอปของฉันหรือไม่?" ในขณะที่คำตอบไม่สามารถเป็น "ใช่" หรือ "ไม่" ง่ายๆ ฉันอยากจะเขียนบทความเพื่อแยกย่อยการนำไปใช้และอธิบายข้อดีและข้อเสียเพื่อช่วยให้คุณตัดสินใจได้

สรุปสั้นๆ จำเป็นต้องหาวิธีที่มีอยู่แล้วที่เหมาะกับความต้องการของคุณ ยกเว้นว่าคุณต้องการควบคุมทั้งหมดหรือคุณยังคงเรียนรู้การพัฒนาซอฟต์แวร์

แนะนำ#

ในฐานะนักพัฒนา ฉันได้สร้างแอปพลิเคชันมากมายในระหว่างอาชีพของฉัน ไม่ว่าจะเป็นภาษาโปรแกรมใด ก็จะมีพื้นฐานร่วมกันที่ฉันต้องสร้างเสมอ: การยืนยันตัวตนผู้ใช้

มันเป็นส่วนน้อยที่ถูกมองข้ามเพราะทุกอย่างเป็นเรื่องง่ายเมื่อย้อนกลับไป 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) สำหรับการยืนยันตัวตน และยอมรับชุมชนโอเพ่นซอร์สตั้งแต่วันแรก

หวังว่าบทความนี้จะเป็นประโยชน์