Tesseral บริการยืนยันตัวตนแบบโอเพนซอร์สใหม่สำหรับซอฟต์แวร์ B2B ได้เปิดตัวด้วยแนวทางที่เป็นเอกลักษณ์ในการจัดการผู้ใช้และองค์กร อย่างไรก็ตาม การตัดสินใจในการออกแบบของพวกเขาได้จุดประกายการถกเถียงอย่างมีนัยสำคัญในชุมชนนักพัฒนาเกี่ยวกับวิธีที่ดีที่สุดในการจัดการ multi-tenancy ในแอปพลิเคชันธุรกิจ
คุณสมบัติหลักของ Tesseral :
- การยืนยันตัวตนแบบ B2B SaaS หลายผู้เช่า
- SAML SSO และการจัดเตรียม SCIM
- การควบคุมการเข้าถึงตามบทบาท (RBAC)
- การยืนยันตัวตนหลายขั้นตอน (MFA)
- Magic links และการเข้าสู่ระบบผ่านโซเชียล
- การแอบอ้างผู้ใช้เพื่อการดีบัก
- การจัดการ API key
- ตัวเลือกบริการแบบโฮสต์เองหรือบริการที่มีการจัดการ
การตัดสินใจออกแบบที่ถกเถียงกัน
สถาปัตยกรรมของ Tesseral กำหนดให้ผู้ใช้แต่ละคนต้องเป็นสมาชิกขององค์กรเพียงหนึ่งเดียว หมายความว่าบุคคลหนึ่งคนต้องมีบัญชีผู้ใช้หลายบัญชีเพื่อเข้าถึงพื้นที่ทำงานที่แตกต่างกัน แนวทางนี้แตกต่างจากสิ่งที่นักพัฒนาหลายคนคาดหวัง ซึ่งผู้ใช้หนึ่งคนสามารถเป็นสมาชิกของหลายองค์กรพร้อมกันได้ ปฏิกิริยาจากชุมชนมีความหลากหลาย โดยนักพัฒนาหลายคนแสดงความกังวลเกี่ยวกับข้อจำกัดนี้
นักพัฒนาคนหนึ่งชี้ให้เห็นปัญหาด้านการใช้งานที่สำคัญของโมเดลนี้ โดยสังเกตว่าบริการอย่าง Datadog ใช้แนวทางที่คล้ายกัน ซึ่งผู้ใช้ต้องเปลี่ยนบริบททั้งหมดระหว่างองค์กร สิ่งนี้ป้องกันการเปิดแท็บจากองค์กรที่แตกต่างกันเคียงข้างกัน และทำให้ลิงก์ใช้งานไม่ได้เมื่อผู้ใช้อยู่ในบริบทองค์กรที่ผิด
การเปรียบเทียบโมเดลผู้ใช้-องค์กร:
| บริการ | โมเดลผู้ใช้ | การเข้าถึงหลายองค์กร |
|---|---|---|
| Tesseral | ผู้ใช้หนึ่งคนต่อหนึ่งองค์กร | ต้องมีหลายบัญชี |
| FusionAuth | ผู้ใช้ทั่วโลกพร้อมการลงทะเบียน tenant | ผู้ใช้เดียว หลาย tenant |
| แบบดั้งเดิม | ความสัมพันธ์แบบกลุ่มต่อกลุ่ม | ผู้ใช้เดียว หลายสมาชิกภาพ |
แนวทางทางเลือกที่ถูกหารือ
การถกเถียงเผยให้เห็นวิธีการต่างๆ ที่บริการยืนยันตัวตนอื่นๆ จัดการกับความท้าทายนี้ นักพัฒนาบางคนแนะนำให้ใช้คำศัพท์แบบดั้งเดิมอย่าง Users, Memberships และ Accounts เพื่อสร้างความสัมพันธ์แบบ many-to-many คนอื่นๆ กล่าวถึงว่า FusionAuth ใช้แนวคิดผู้ใช้ส่วนกลางพร้อมการลงทะเบียนเฉพาะ tenant ทำให้บุคคลเดียวกันสามารถอ้างอิงได้ทั้งจาก ID ผู้ใช้ส่วนกลางและเฉพาะแอปพลิเคชัน
สมาชิกชุมชนหลายคนสนับสนุนโมเดลที่เรียบง่ายกว่า ซึ่งผู้ใช้สามารถเข้าถึงหลายองค์กรได้โดยไม่ต้องสร้างบัญชีแยกต่างหาก พวกเขาโต้แย้งว่าแนวทางนี้ลดความสับสนและให้ประสบการณ์ผู้ใช้ที่ดีกว่า โดยเฉพาะสำหรับองค์กรขนาดใหญ่ที่พนักงานอาจต้องการเข้าถึงหลายแผนกหรือบริษัทย่อย
ภูมิทัศน์บริการยืนยันตัวตนที่กว้างขึ้น
การเปิดตัวของ Tesseral เพิ่มเข้าไปในสนามที่มีการแข่งขันสูงของบริการยืนยันตัวตน นักพัฒนาในการถกเถียงเปรียบเทียบกับผู้เล่นที่มีชื่อเสียงอย่าง Auth0 , Clerk , Keycloak และผู้เข้าใหม่อย่าง Stack Auth แต่ละบริการใช้แนวทางที่แตกต่างกันในการแก้ไขความท้าทายด้านการยืนยันตัวตน โดยบางบริการมุ่งเน้นไปที่เฟรมเวิร์กหรือโมเดลการปรับใช้เฉพาะ
น่าสนใจที่การถกเถียงยังเผยให้เห็นความกังวลที่เพิ่มขึ้นเกี่ยวกับการพึ่งพาคลาวด์ โดยเฉพาะในหมู่บริษัทยุโรป นักพัฒนาหลายคนกล่าวถึงว่าการพึ่งพา AWS และผู้ให้บริการคลาวด์ที่ตั้งอยู่ในสหรัฐอเมริกาอื่นๆ กำลังกลายเป็นข้อพิจารณาที่สำคัญสำหรับธุรกิจยุโรป เนื่องจากความกังวลเรื่องอำนาจอธิปไตยข้อมูลและภูมิรัฐศาสตร์
SDK ที่มีให้บริการ:
- ฝั่งไคลเอนต์: React
- ฝั่งเซิร์ฟเวอร์: Express, Flask, Golang
- อยู่ระหว่างการพัฒนา: Django, Laravel, Rails, Fastify
การถกเถียงระหว่าง Self-Host กับ Managed Service
ในขณะที่ Tesseral เสนอทั้งตัวเลือกที่จัดการและ self-hosted การถกเถียงของชุมชนเน้นให้เห็นความตึงเครียดที่ต่อเนื่องระหว่างความสะดวกสบายและการควบคุม นักพัฒนาบางคนชอบสร้างระบบยืนยันตัวตนของตนเองโดยใช้เฟรมเวิร์กที่มีชื่อเสียงอย่าง Rails กับ Devise ในขณะที่คนอื่นๆ ชื่นชมการประหยัดเวลาที่บริการที่จัดการให้มอบให้สำหรับฟีเจอร์ที่ซับซ้อนอย่าง SAML SSO และการยืนยันตัวตนแบบหลายปัจจัย
การถกเถียงสะท้อนคำถามที่กว้างขึ้นเกี่ยวกับเมื่อไหร่ควรสร้างเทียบกับซื้อ โดยเฉพาะสำหรับโครงสร้างพื้นฐานที่สำคัญอย่างการยืนยันตัวตน ดังที่นักพัฒนาคนหนึ่งสังเกต ข้อผิดพลาดในการยืนยันตัวตนอาจมีค่าใช้จ่ายสูงและยากต่อการแก้ไขในภายหลัง ทำให้การเลือกระหว่างการพัฒนาแบบกำหนดเองและบริการบุคคลที่สามมีความสำคัญเป็นพิเศษ
บทสรุป
การเปิดตัวของ Tesseral ได้เน้นให้เห็นคำถามพื้นฐานเกี่ยวกับวิธีที่บริการยืนยันตัวตนควรจัดการ multi-tenancy ในแอปพลิเคชัน B2B ในขณะที่บริการนี้เสนอฟีเจอร์ที่ครอบคลุมสำหรับซอฟต์แวร์ธุรกิจ โมเดล user-organization ของมันได้สร้างการถกเถียงอย่างมีนัยสำคัญเกี่ยวกับประสบการณ์ผู้ใช้และการแลกเปลี่ยนทางสถาปัตยกรรม ข้อเสนอแนะจากชุมชนแนะนำว่าผู้ให้บริการยืนยันตัวตนต้องสร้างสมดุลระหว่างการนำไปใช้ทางเทคนิคกับความคาดหวังของผู้ใช้และรูปแบบการใช้งานในโลกจริงอย่างระมัดระวัง
อ้างอิง: Tesseral