Stack Auth – โอเพนซอร์สทางเลือกแทน Auth0/Clerk

 (github.com/stack-auth)
16 คะแนน โดย GN⁺ 2024-08-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โซลูชัน "การยืนยันตัวตนผู้ใช้" แบบโอเพนซอร์สเต็มรูปแบบที่เป็นมิตรกับนักพัฒนา ภายใต้ไลเซนส์ MIT และ AGPL
  • เริ่มต้นได้อย่างรวดเร็ว และเมื่อโปรเจกต์เติบโตขึ้นก็ยังใช้งานฟีเจอร์ทั้งหมดได้เหมือนเดิม
  • Managed service เป็นตัวเลือกเสริมเท่านั้น และสามารถส่งออกข้อมูลผู้ใช้ได้ทุกเมื่อพร้อมโฮสต์เองได้ฟรี
  • รองรับฟรอนต์เอนด์ Next.js และแบ็กเอนด์ทุกชนิดที่ใช้งาน REST API ได้

ฟีเจอร์

  • <SignIn/> และ <SignUp/>: คอมโพเนนต์ยืนยันตัวตนที่รองรับ OAuth, ข้อมูลรับรองแบบรหัสผ่าน และ magic link รองรับโหมดมืด/สว่าง
  • Next.js API: ทำงานบนพื้นฐานของ server component, React hook และ route handler
  • แดชบอร์ดผู้ใช้: กรองผู้ใช้ วิเคราะห์ และแก้ไขได้
  • การตั้งค่าบัญชี: อัปเดตโปรไฟล์ ยืนยันอีเมล และเปลี่ยนรหัสผ่านได้
  • รองรับมัลติเทนเนนซีและทีม: จัดการลูกค้า B2B ได้
  • การควบคุมการเข้าถึงตามบทบาท: กำหนดกราฟสิทธิ์และมอบหมายให้ผู้ใช้ได้
  • การเชื่อมต่อ OAuth: จัดการ access token สำหรับ API ของบุคคลที่สาม เช่น Outlook, Google Calendar
  • การสวมสิทธิ์ผู้ใช้ (Impersonation): สามารถล็อกอินเป็นบัญชีผู้ใช้เพื่อการดีบักและซัพพอร์ตได้
  • เว็บฮุก: แจ้งเตือนกิจกรรมของผู้ใช้ พัฒนาบน Svix
  • อีเมลอัตโนมัติ: ส่งอีเมลแบบกำหนดเองเมื่อสมัครสมาชิก รีเซ็ตรหัสผ่าน และยืนยันอีเมล
  • การจัดการเซสชันผู้ใช้และ JWT: จัดการ refresh token, access token, JWT และคุกกี้
  • การยืนยันตัวตนแบบ M2M: ใช้ access token แบบอายุสั้นสำหรับการยืนยันตัวตนระหว่างเครื่อง

สรุปโดย GN⁺

  • Stack Auth เป็นโซลูชันยืนยันตัวตนผู้ใช้แบบโอเพนซอร์สที่เป็นมิตรกับนักพัฒนา โดยเริ่มต้นได้รวดเร็วและมีฟีเจอร์ที่หลากหลาย
  • รองรับฟรอนต์เอนด์ Next.js และ REST API จึงใช้งานร่วมกับแบ็กเอนด์ที่หลากหลายได้
  • มีฟีเจอร์หลากหลาย เช่น การจัดการผู้ใช้ การควบคุมการเข้าถึงตามบทบาท และการเชื่อมต่อ OAuth ซึ่งเหมาะกับการเติบโตของโปรเจกต์
  • พัฒนาอย่างต่อเนื่องจากการมีส่วนร่วมของชุมชนโอเพนซอร์ส และมีตัวเลือกสำหรับโฮสต์เองด้วย
  • ผลิตภัณฑ์ที่มีฟังก์ชันคล้ายกัน ได้แก่ Auth0 และ Clerk

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-10
ความเห็นบน Hacker News
  • มีความกังวลว่าเครื่องมือโอเพนซอร์สที่ได้รับเงินสนับสนุนจาก VC ถูกใช้เป็นช่องทางดึงดูดลูกค้า และในไม่ช้าจะเปลี่ยนฟีเจอร์ไปเป็นแบบเสียเงิน
  • ร่วมแสดงความยินดีกับการเปิดตัวอย่างเป็นทางการของ Stack Auth และสงสัยว่ามีแผนรองรับเฟรมเวิร์ก "รุ่นเก่า" อย่าง Django, Rails และ Bootstrap หรือไม่
    • กล่าวว่าปกติโปรเจ็กต์ใหม่มักใช้เทคโนโลยีสมัยใหม่ แต่ผู้ใช้เทคโนโลยีเดิมก็สามารถให้ฟีดแบ็กที่สำคัญได้เช่นกัน
  • ใช้งาน Golang backend, Postgres DB และแอป React อยู่ และตั้งคำถามว่าการตั้งค่า authentication พื้นฐานมีความซับซ้อนหรือไม่
    • สงสัยว่า OAuth หรือ SAML คือจุดที่สร้างความแตกต่างหรือไม่ และถามว่าจำเป็นต้องมี dependency กับการดูแลจัดการเพิ่มเติมหรือเปล่า
  • กล่าวว่าที่ผ่านมาไม่ค่อยไว้ใจการมอบ authentication และ authorization ของโปรเจ็กต์ส่วนใหญ่ให้บริการภายนอกจัดการ
    • แสดงความยินดีกับการเปิดตัว Stack Auth และขอบคุณที่นำเสนอทางเลือกที่ดีกว่า
  • ขอให้ช่วยเปรียบเทียบกับ SuperTokens และสงสัยถึงความแตกต่างระหว่างสองระบบ
  • กล่าวว่าช่วงหลังมีระบบ authentication เปิดตัวออกมาจำนวนมาก
  • ตั้งคำถามเกี่ยวกับแนวทางด้านความปลอดภัย โดยชี้ว่าไม่มีการพูดถึงการทดสอบเจาะระบบ นโยบายความปลอดภัย หรือวิธีรายงานช่องโหว่
    • ยอมรับว่าการทำ UX ของ authentication และ authorization ให้ถูกต้องเป็นเรื่องยาก และย้ำว่าในด้านความปลอดภัยก็มีความท้าทายมากเช่นกัน
    • กล่าวว่าการมอบความรับผิดชอบให้ผลิตภัณฑ์ของบุคคลที่สามก็เท่ากับการสละการควบคุม
  • ในฐานะทีมขนาดเล็กที่ใช้ Next.js และ Supabase มองว่า Stack Auth น่าจะมีประโยชน์
    • ปัจจุบันใช้ Supabase Auth และ Nango อยู่ และต้องการ reference implementation ที่ดีสำหรับการสร้างระบบองค์กร
    • มองว่า Stack Auth อาจช่วยแก้บางปัญหาได้ แต่สงสัยว่าจะทำหน้าที่เป็น OAuth API proxy หรือไม่
  • เสนอให้เตรียมตารางเปรียบเทียบกับผลิตภัณฑ์คู่แข่งไว้บนหน้าแรก
    • เน้นจุดที่แตกต่างจาก Auth0, Clerk, Supabase Auth และ Auth.js/NextAuth
  • ขอให้ช่วยเปรียบเทียบกับ Ory Kratos และสงสัยถึงความแตกต่างระหว่างสองระบบ