Node.js OAuth Linking: จัดการปัญหา Social Identity
แนวทางเชื่อมโยง Social Login ใน Node.js ป้องกันบัญชีซ้ำซ้อนในระบบสุขภาพ และแยก CAPTCHA ออกจากการพิสูจน์ตัวตน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ห้ามสร้างโปรไฟล์ใหม่จาก Social Login ทันทีโดยยังไม่ตรวจสอบข้อมูลเดิม
- ใช้คู่คีย์ (Issuer, Subject) เป็นกุญแจระบุตัวตนแทนการใช้อีเมล
- บังคับให้ผู้ใช้ต้องล็อกอินบัญชีเดิมก่อนเชื่อมโยงบัญชีใหม่ทุกครั้ง
- แยกการตรวจสอบ CAPTCHA ออกจากการตัดสินใจเชื่อมโยงบัญชี
การใช้งานระบบ Social Login ในแอปพลิเคชันโดยเฉพาะในระบบเทคโนโลยีสุขภาพ (Healthtech) มักพบปัญหาการสร้างโปรไฟล์ผู้ป่วยซ้ำซ้อนหากระบบไม่ทำการตรวจสอบข้อมูลตัวตนเดิมให้รอบคอบ กฎการทำงานที่ปลอดภัยและเรียบง่ายที่สุดคือ การตรวจสอบการยืนยันตัวตนจากผู้ให้บริการ ทำการปรับมาตรฐานข้อมูลผู้ให้บริการ ค้นหากุญแจระบุตัวตนที่ไม่เปลี่ยนแปลง และตัดสินใจว่าจะเชื่อมโยง ลงชื่อเข้าใช้ หรือสร้างโปรไฟล์ใหม่ โดยต้องวางระบบป้องกันการละเมิดไว้ก่อนขั้นตอนการสร้างบัญชี แต่ให้แยกผลลัพธ์ของ CAPTCHA ออกจากการพิสูจน์ตัวตนอย่างเด็ดขาด
ในเชิงสถาปัตยกรรมระบบ การจัดการข้อมูล Credential จากโซเชียลควรถูกมองว่าเป็นบันทึกตัวตนที่ไม่ซ้ำกัน (Unique Identity Record) แทนที่จะมองว่าเป็นเพียงที่อยู่อีเมล สำหรับ Node.js ธุรกรรมที่บันทึกข้อมูลดังกล่าวจะต้องทำการล็อกข้อมูลผู้ใช้ที่มีความเกี่ยวข้อง กำหนดให้ต้องมีเซสชันที่ผ่านการตรวจสอบสิทธิ์แล้วก่อนทำการเชื่อมโยง และออกแบบให้คำขอที่ส่งซ้ำไม่มีผลกระทบต่อระบบ อีเมลมีประโยชน์สำหรับการค้นหาและการแจ้งเตือนเท่านั้น แต่เป็นฐานที่อ่อนแอเกินไปสำหรับการรวมบัญชีแบบอัตโนมัติที่ไม่มีการยืนยัน
การตรวจสอบเหตุการณ์ที่ผิดพลาดควรเริ่มจากการวิเคราะห์ความล้มเหลวที่ปรากฏ เช่น ผู้ป่วยลงชื่อเข้าใช้ด้วยบัญชีโซเชียลแล้วพบโปรไฟล์ว่างเปล่า ขณะที่ฝ่ายสนับสนุนพบโปรไฟล์เก่าภายใต้วิธีการลงทะเบียนก่อนหน้า การทำงานย้อนกลับจะพบว่า Callback ยอมรับการยืนยันตัวตน การค้นหาอีเมลพบคู่ที่อาจตรงกัน และแอปพลิเคชันได้สร้างโปรไฟล์ใหม่ก่อนที่ใครจะยืนยันบัญชีเก่าอย่างชัดเจน สัญญาณที่ขาดหายไปคือเหตุการณ์การแก้ไขปัญหาบัญชีก่อนที่จะมีการบันทึกข้อมูลลงฐานข้อมูล
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในทางปฏิบัติการพัฒนาซอฟต์แวร์ การพึ่งพาอีเมลเป็นเกณฑ์หลักในการผูกบัญชีมักเปิดช่องให้ผู้ไม่หวังดีเข้ายึดครองบัญชี (Account Takeover) ได้ง่าย หากผู้ให้บริการรายนั้นมีนโยบายอีเมลที่เปลี่ยนแปลงได้หรือไม่ได้รับการยืนยันที่รัดกุม การใช้ตัวระบุตัวตนระดับ OpenID Connect เช่น (issuer, subject) จึงมีความปลอดภัยสูงกว่ามากเพราะไม่สามารถเปลี่ยนแปลงได้ในบริบทของผู้ให้บริการรายนั้นๆ
แนวทางการตัดสินใจที่ปลอดภัยมีขอบเขตที่ชัดเจนประกอบด้วย:
- ตัวตนเดิมที่มีอยู่จะนำผู้ใช้เข้าสู่ระบบโดยอัตโนมัติ
- กรณีที่ไม่พบตัวตนเดิมแต่มีเซสชันในระบบที่ผ่านการตรวจสอบแล้ว สามารถเชื่อมโยงได้หลังผ่านขั้นตอนการยืนยันอย่างตั้งใจ
- กรณีที่ไม่พบตัวตนแต่มีอีเมลตรงกัน จะต้องเข้าสู่กระบวนการกู้คืนหรือตรวจสอบบัญชี ห้ามรวมบัญชีโดยอัตโนมัติ
- การสร้างโปรไฟล์ใหม่จะเกิดขึ้นได้ก็ต่อเมื่อผ่านการตรวจสอบการละเมิดและความยินยอมเรียบร้อยแล้ว
"An OAuth subject is scoped to an issuer and client, so the durable lookup key is a tuple such as (issuer, subject)."
Dev.to Article
ฐานข้อมูลควรมีข้อจำกัด (Constraint) ที่แข็งแกร่งเป็นปราการด่านสุดท้าย โดยเก็บบันทึกตัวตนภายนอกหนึ่งแถวต่อหนึ่งบัญชี พร้อมข้อจำกัดที่ไม่ซ้ำกัน (Unique Constraint) ครอบคลุมทั้ง Issuer และ Subject และทำให้การเชื่อมโยงบัญชีเป็นระบบธุรกรรม (Transactional) เพื่อป้องกันความผิดพลาดที่อาจเกิดขึ้นจากการเขียนโค้ดฝั่งแอปพลิเคชันเพียงอย่างเดียว
ที่มา:
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น