จะเลือกผู้ให้บริการยืนยันตัวตนยังไง: กรอบการประเมินของทีมวิศวกรรม

บทความเปรียบเทียบผู้ให้บริการยืนยันตัวตน (IdP) ส่วนใหญ่มักเขียนโดยผู้ขาย IdP เอง น่าตกใจใช่ไหม? พวกเขาจะลิสต์แต่ฟีเจอร์ที่ตัวเองมี ข้ามสิ่งที่ไม่มี แล้วบอกว่านี่คือ "คู่มือแบบเป็นกลาง"

นี่ไม่ใช่แบบนั้น

เราได้รีวิวคำขอประเมินจากองค์กรจริงแบบนับสิบเจ้า — จากสเปรดชีตและเอกสาร RFP จริง ๆ ที่ฝ่ายจัดซื้อส่งให้ vendor แบบล้วน ๆ แล้ว Pattern จะชัดเจนมาก: ทีมวิศวกรรมมักให้ค่าน้ำหนักกับเกณฑ์ผิดจุด — ให้ค่าสิ่งไม่สำคัญเกินไป และมองข้ามของจำเป็น

ผลลัพธ์ที่เกิดขึ้น? ทีมเลือก IdP เพราะเดโม ดูเหมือนจะเวิร์ค พอหกเดือนผ่านไปตอนย้ายระบบจริงกลายเป็นฝันร้าย แล้วก็ต้องกลับมาประเมินใหม่

นี่คือกรอบการประเมินที่เราอยากมีตั้งแต่แรกสำหรับทีมวิศวกรรมของบริษัท SaaS B2B — ทีมที่สร้างโปรดักต์ ไม่ใช่ทีมที่เลือก workforce SSO ให้พนักงานตัวเอง

สรุปสั้น: ปัจจัยชี้เป็นชี้ตาย IdP#

ถ้าคุณกำลังไล่อ่านแบบเร็ว ๆ นี่คือเวอร์ชั่นกระชับ:

1. ความลึกของโปรโตคอลสำคัญกว่าจำนวนฟีเจอร์ การบอกว่า "รองรับ OAuth2" ไม่มีความหมาย อันไหนรองรับ grant type อะไรบ้าง? ปรับแต่ง token claim ได้แค่ไหน? กลายเป็น OIDC provider ได้มั้ย?
2. ศักยภาพการย้ายผู้ใช้เก่าคือเกณฑ์ที่ถูกประเมินต่ำสุด ถ้าย้ายผู้ใช้เก่าโดยไม่รีเซ็ตรหัสผ่านไม่ได้ IdP ตัวนั้นไม่มีประโยชน์ ไม่ว่าตรงอื่นจะดีแค่ไหน
3. มัลติเทนซีต้อง native ไม่ใช่เอามาแปะ ถ้าโมเดลองค์กรหรือการตั้งค่าต่อ tenant ต้องใช้ลูกเล่น workaround คุณจะต้องสู้กับระบบนี้ตลอด
4. AI-readiness ไม่ใช่วางแผนอนาคต — มันคือความต้องการ 12 เดือนนี้ Token exchange, agent identity, delegated scopes ถ้า IdP ขาดตรงนี้ คุณจะต้องรีวิวรอบใหม่ปีหน้า

คู่มือนี้จะแยกแต่ละมิติพร้อมตัวอย่างคำถามที่ควรถามและ Red Flag ที่ควรระวัง

ใครควรอ่าน (และใครไม่ควร)#

ถ้านี่คือตัวคุณ:

• คุณเป็น CTO, VP of Engineering หรือ Platform Architect ของ B2B SaaS ขนาด 50-300 คน
• คุณมีผู้ใช้ >100,000 ราย และย้ายระบบแบบเดือดร้อนไม่ได้
• คุณกำลังขยายสู่กลุ่ม Enterprise ที่ต้องการ SSO, org model, audit log
• คุณต้องเขียนรายงานประเมินทางเทคนิคและอยากได้กรอบที่ไม่ได้มาจาก vendor

ไม่ใช่สำหรับกรณีนี้:

• คุณกำลังหา IAM ภายในองค์กร (SSO ให้พนักงาน) — เป็นการตัดสินใจอีกแบบ
• เป็นสตาร์ทอัพผู้ใช้ 500 คน และยังไม่มีลูกค้าองค์กร — เอาอะไรก็ได้ที่ SDK ดีสุดพอ
• คุณต้องการ identity verification (KYC/KYB) — อยู่คนละหมวดเลย

มิติที่ 1: ศักยภาพโปรโตคอล — ไม่ใช่แค่ "รองรับ OAuth2"#

ทุก IdP จะบอกว่ารองรับ OAuth2 กับ OIDC แต่นั่นเป็นแค่พื้นฐาน ของจริงต้องดูรายละเอียดลึก

Grant types: มีอะไรบ้างและทำไมต้องสนใจ#

ต้องมี:

• Authorization Code + PKCE — Flow เดียวที่ควรใช้กับ Browser กับ Mobile ถ้า vendor ยังแนะนำ Implicit flow ให้เดินออก PKCE ต้องมี ไม่ใช่ตัวเลือก แต่เป็นความปลอดภัย
• Client Credentials — สำหรับ service-to-service พวก backend ต่าง ๆ ที่คุยกันเอง ไม่มี user login
• Refresh Token — ฟังดูพื้น ๆ แต่รายละเอียดต่างกันหนัก ปรับ rotation, expiration ได้มั้ย? Revoke refresh token จุดเดียวโดยไม่ kill ทุก session ได้หรือเปล่า?

เริ่มสำคัญขึ้นเรื่อย ๆ :

• Token Exchange (RFC 8693) — grant ที่ทำให้ AI agent, impersonation, delegation เป็นจริง ถ้าขาดวันนี้ ถาม roadmap ถ้าไม่มี roadmap คือแดงแรง ๆ

OIDC Provider capability#

คำถามที่หลายทีมไม่เคยคิด: IdP นี้กลายเป็น OIDC Provider ให้คนอื่นใช้ login ได้มั้ย ไม่ใช่แค่กิน identity จากเจ้าอื่น?

ทำไมต้องแคร์: SaaS โตขึ้น คู่ค้าหรือพาร์ทเนอร์อาจอยากให้ระบบ identity ของคุณกลายเป็น SSO ให้ tool พวกเขาเอง คุณต้องออก token, มีระบบให้ app มากรอก consent, third-party app registration ถ้า IdP แค่ให้คุณ consume ภายนอกแต่ federate ออกข้างนอกไม่ได้ จะตันทันที

ถามว่า:

• เปิด endpoint OpenID Discovery แบบ white-label ได้หรือเปล่า?
• สมัคร first-party กับ third-party app พร้อม trust level ต่างกันได้มั้ย?
• First-party app ข้าม consent แต่ third-party บังคับได้มั้ย?

JWT customization#

Token คือสัญญาระหว่าง IdP กับ service ถ้าปรับแต่งไม่ได้ downstream service ต้องยิง API ไปถาม role/permission เพิ่ม

ถามว่า:

• ใส่ custom claim ใน access/ID token ได้ไหม?
• ฝัง context ของ org/tenant ไว้ใน token เลยได้หรือเปล่า?
• กำหนด custom scope ที่แมพ permission model ตัวเองได้มั้ย?
• Claim ประมวลผลตอนออก token เลยหรือจะ populate ผ่าน webhook/script แบบ dynamic ได้?

Token ที่ใส่ { "org_id": "org_123", "role": "admin", "auth_level": 2 } ทำให้ API authorize ใน 1 บรรทัด Token เดิม ๆ { "sub": "user_456" } ทุก service ต้องยิง IdP / DB หาเพิ่ม ที่ scale จะต่างกัน 2ms vs 200ms ต่อ request

มิติที่ 2: Authentication flow — รายละเอียดที่อาจพังทั้งระบบ#

ทุก IdP มี email/password & social login แปลว่าคุณยังไม่คัดใครออกเลย

แต่ของจริงอยู่ที่รายละเอียดเล็ก ๆ ที่ demo ไม่เคยโชว์

Signup flow#

• Auto-login หลังสมัคร: sign up เสร็จเข้าใช้งานอัตโนมัติเลยหรือบังคับให้ login ใหม่? ถ้าต้อง login ซ้ำหลังสมัคร เสีย conversion หนักมาก อย่าเชื่อว่าทุก IdP ทำถูก
• Custom fields: สมัครแล้วเก็บ role, company name, use case ได้เลยมั้ย? หรือหยิบไป onboarding แยกอีกรอบ?
• Progressive profiling: ขอข้อมูลลูกค้าเพิ่มในหลาย session ได้ ไม่ใช่กรอกหมดทีเดียว?

Login flow#

• login_hint support: user คลิกลิงก์ในอีเมล marketing ระบบ pre-fill อีเมลได้มั้ย? ดูเหมือนไม่จำเป็นแต่พลาดตรงนี้ conversion จากแคมเปญอีเมลหาย 20%
• Org-specific auth policies: Org A บังคับ SAML SSO, Org B ใช้ email/password, Enterprise tenant เท่านั้นที่บังคับ MFA ถ้านโยบายต่อ tenant ต้องแก้โค้ดแทน config คุณเสียเวลาทุกครั้ง onboarding
• Branding per tenant: เปลี่ยน UX login ของแต่ละ org ได้? ไม่ใช่แค่ logo+สี แต่ปรับ CSS, custom domain, white-label email ได้หมด "Hosted UI vs. custom UI" ต้องเป็นทางเลือกคุณ เลือกเอง ไม่ใช่ข้อจำกัด

สิ่งที่ checklist ส่วนมากลืม#

• Silent authentication: Token หมดอายุ แอพ refresh token แบบ silent โดยไม่เด้ง user ได้มั้ย? ถ้า Refresh หมดด้วย มี fallback อะไรมั้ย (เช่น iframe sliding session)?
• Account linking: user ใช้ Google sign up แล้ว login ด้วย email — กลายเป็น 2 account หรืออันเดียว? IdP merge identity ให้หรือสร้างซ้ำ? จัดการไม่ดี user ซ้ำแบบผีเต็ม DB
• Passwordless option: magic link, passkey, WebAuthn — ลูกค้า enterprise จะถามแน่ภายใน 6 เดือน

มิติที่ 3: การจัดการ session และ token — จุดที่พังแล้ววุ่นวาย#

จุดนี้แหละที่แยก IdP เดโมกับ IdP ที่ใช้งานจริง Session/token management น่าเบื่อแต่ถ้าพัง ผู้ใช้โดนเตะออกทั้งระบบ

Cookie security#

อาจดูไม่ไฮเทคแต่สำคัญมาก

• HttpOnly, Secure, SameSite: ต้องตั้งครบหมด ถ้า IdP ไม่ใส่ HttpOnly ให้ session cookie ยังไม่พร้อม production
• Cross-subdomain: ถ้าแอพรันบน app.yourproduct.com แต่ API คือ api.yourproduct.com session ข้าม subdomain ได้มั้ย ทำยังไง?
• Third-party cookie deprecation: Chrome กำลังเลิกใช้ vendor รับมือ auth ข้าม origin ยังไง ถ้าบอกว่า "กำลังทำ" — รับไม่ได้

Remember me/persistent session#

User อยากล็อกอินทีเดียวอยู่ได้เป็นสัปดาห์ ไม่ใช่ 30 นาที แต่ session 180 วันกับ 30 นาที ความปลอดภัยต่างกันมาก

ถามว่า:

• ปรับระยะเวลาของ session กับ token lifetime แยกได้มั้ย?
• "Remember me" ยืด session ได้แต่คุม token ให้อายุสั้นได้มั้ย?
• บังคับ auth ใหม่เฉพาะ operation เสี่ยงโดยไม่ kill session ทั้งหมดได้เปล่า?

Refresh token security#

• Token rotation: ใช้ refresh แล้วออก token ตัวใหม่ทุกครั้ง? (ควรใช่)
• Encrypted storage: เก็บ refresh token แบบเข้ารหัส?
• Revoke จุดเดียว: kill session เฉพาะ device ได้มั้ย ไม่ kill ทุก session?
• Configurable expiration: แต่ละแอพตั้ง refresh lifetime เองหรือต้องใช้ global ค่าเดียวกันหมด?

มิติที่ 4: Authorization model — เกินกว่า RBAC#

ถ้า IdP ไม่มี RBAC ไม่ต้องรีวิวต่อ แต่ถ้าเป็น B2B SaaS มีแค่ RBAC ไม่พอ

Organization-scoped permission#

user สังกัดองค์กร มีสิทธิในแต่ละ org ต่างจากระดับ platform

user เดียวกันอาจเป็น admin ใน Org A แต่เป็น viewer ใน Org B ถ้า IdP ทำไม่ได้ ต้องสร้าง permission system แยกเองแล้วมี source of truth สองที่

ถามว่า:

• กำหนด role ที่ระดับ org ได้ ไม่ใช่แค่ user แบบ global?
• user คนเดียวมี role ต่างกันใน org ต่าง ๆ ได้หรือเปล่า?
• context ของ org ปัจจุบันฝังใน token ให้ backend อ่านได้เลยมั้ย?

Multi-level authorization (auth_level)#

แอพการเงิน, เฮลธ์แคร์ หรือที่มีความเสี่ยง: การแค่ล็อกอินยังไม่พอ

อ่าน dashboard ใช้ session cookie ได้แต่จะโอนเงินต้อง fresh MFA อีกชั้นต่อให้ล็อกอินแล้วก็ตาม

feature นี้เรียกว่า step-up authentication หรือ auth_level ต้องเป็น first-class citizen ของ token

ถามว่า:

• token มี claim auth_level ช่วย backend เช็ค privilege ได้ไหม?
• จากแอพ trigger step-up auth ได้โดยไม่ต้อง re-login ทั้งหมด?
• auth_level มี expiration แยกจาก session หลักได้มั้ย?

IdP ขาดจุดนี้ต้องสร้างเอง — ในสิ่งที่จริง ๆ แล้วควรซื้อมาใช้

Token-based authorization decision#

เป้าหมาย: API middleware อ่าน token เห็น org/role/auth_level ตัดสิน auth ได้ทันที

แต่ IdP ส่วนมาก token บอกแค่ user ใคร แต่อะไรที่ user ทำได้ต้องไป query API อีกที

ตรงนี้เพิ่ม latency, dependency, จุดพังที่ scale 1,000 req/sec, คุณไม่อยาก auth แล้วต้องชะลอรอ external call

มิติที่ 5: การย้ายระบบ — ตัวชี้ขาดที่ไม่มีใครพูดถึง#

สถิติที่ทุกคนไม่อยากเผย: กระบวนการเลือก IdP ส่วนมากจบเพราะ migrate ผู้ใช้เก่าไม่ได้ ไม่ใช่เพราะ IdP ไม่ดี

ถ้ามีผู้ใช้เกินแสน Migration ไม่ใช่ "nice to have" แต่มันคือทั้งโปรเจค

กลยุทธ์ย้ายระบบ 3 แบบ (และ IdP ต้องรองรับแบบไหน)#

1. Bulk import พร้อม hash เดิม

ผู้ใช้ตั้งรหัสผ่านเดิมไว้ใน bcrypt, argon2 หรืออื่น ๆ IdP import hash ได้เลยมั้ย ตรวจรหัสผ่านกับ hash เดิมได้ไหม?

ถ้าได้: user login ด้วยของเดิม ไม่รู้เรื่อง Best case

ถ้าไม่ได้: ทุกคนต้อง reset password ผ่านอีเมล หาย 30-50% ของฐาน user แน่ ๆ ไม่ใช่ทฤษฎี แต่ประสบการณ์จริง

2. Progressive (ย้ายทีละคนขณะ login)

ไม่ต้องย้ายหมดทีเดียว ให้ user login ใหม่ทีละคน เมื่อ login ใหม่สำเร็จดึง hash จากระบบเก่าแล้วสร้าง user ใน IdP ใหม่ ครั้งถัดไปใช้ IdP ใหม่ทันที

เหมาะกับ user base ใหญ่แต่ต้องให้ IdP รองรับ:

• Hook ดัก auth เองไปเช็คระบบเก่า
• สร้าง user "สด ๆ" ตอน login ได้เลย
• track ว่า user ไหน migrated แล้ว

3. Dual-write (รันสองระบบคู่ขนาน)

ระหว่างเปลี่ยน ระบบเก่า-ใหม่เขียนพร้อมกัน อ่านค่อย ๆ เปลี่ยนไปใหม่ มีทาง rollback แต่จะซับซ้อน

สัญญาณอันตราย migration#

• "Import CSV ได้" — หมายถึง profile ไม่ใช่รหัสผ่าน ยังไงก็ต้อง reset password
• "มี migration guide" — อ่านให้ละเอียด ถ้าเขียนว่า "user ต้องตั้ง password ใหม่" นั่นแหละ user หายยกฐาน
• ไม่ได้พูดถึง hash compatibility — Vendor ที่ไม่สน password hash migration ไม่เคยเจอระบบใหญ่จริง

ถามอะไรบ้าง#

• import hash อะไรได้? (bcrypt, argon2, scrypt, PBKDF2, custom?)
• progressive migration ทีละ user ได้มั้ย?
• ตามดูได้มั้ยว่า user migrate ไปแล้วกี่ %?
• ถ้าย้ายไม่เวิร์ค rollback strategy เป็นยังไง?
• session ต่อเนื่องเป็น seamless มั้ย ระหว่างย้าย user ไม่ถูกเตะออก?

ตอบไม่ได้ชัด ให้ข้ามเลย แปลว่ายังไม่เคยทำ migration scale ใหญ่จริง

มิติที่ 6: Multi-tenancy — Native กับ Workaround#

SaaS B2B = multi-tenancy ลูกค้าคือองค์กร มีผู้ใช้/role/policy เยอะ IdP ต้องเข้าใจ multipl org เป็นของจริง

Native multi-tenancy คืออะไร#

• Organization เป็น entity first-class: ไม่ใช่ custom field แต่เป็นโมเดลเต็ม มี ID, config, member list เอง
• Policy ต่อองค์กร: Org A ใช้ SAML SSO, Org B email/password + MFA, Org C Google Workspace ทำได้ผ่าน UI/API ไม่ใช่ต้องแก้โค้ด
• เชิญสมาชิกและจัดการสิทธิ์ในแต่ละ org: Admin org จัดเชิญ user, กำหนด role, ลบสมาชิกได้ flow เชิญ/verify email/ตั้ง role IdP จัดการให้
• Token ฝัง context org: user operate ใน org ไหน token ฝัง context นั้น API ส่ง data กลับอิง org ได้เลย

Workaround "custom metadata"#

บาง IdP ไม่มี org model เสนอใช้ user metadata (user.app_metadata.org_id = "123")

ซึ่งจะพังเร็วมาก:

• user หลาย org ต้องบริหาร array ใน metadata เอง
• ไม่มี flow เชิญหรือจัดการสมาชิก built-in
• policy-per-org ทำไม่ได้
• org-scoped token ไม่มี ต้องเดา context จากสัญญาณอื่น
• audit log ไม่รู้ว่าเหตุการณ์เกี่ยวกับ org ไหน

ถ้า vendor บอกใช้ metadata แทน native org model เทียบเท่ากับเก็บ relational data ไว้ใน JSON ช่องเดียว — เวิร์คชั่วคราวแต่อีกหน่อยก็พัง

คำถามสำคัญ#

• org model native หรือปั้นจาก user metadata?
• user คนนึงอยู่หลาย org พร้อมกันได้ไหม?
• config auth แต่ละ org แยกกันได้มั้ย?
• role/permission ต่อ org-id native หรือเปล่า?
• admin org จัดการสมาชิกผ่าน self-service UI ได้?
• token มี org context มั้ย?

มิติที่ 7: AI-readiness — เกณฑ์ที่ยังไม่มีใครถาม#

12 เดือนก่อน "AI agent authentication" ไม่มีใครพูดถึง ตอนนี้ถ้าคุณกำลังสร้างฟีเจอร์ AI เช่น copilot, agent, workflow อัจฉริยะ IdP ต้องรองรับ identity ประเภทใหม่: agent

ทำไม agent ทำ auth แบบเดิมพัง#

โมเดลเก่ามี user + app เป็นผู้เล่นหลัก (OAuth2)

AI agent คือ entity ที่ 3 — ไม่ใช่ user ไม่มี password/เบราเซอร์, ไม่ใช่ machine-to-machine, แต่มัน acting on behalf of user, permission ต้องปกป้อง, audit trail ต้องชัด

• agent ไม่ใช่ user — ไม่มี password ไม่ login ด้วยเบราเซอร์
• agent ไม่ใช่ service ระหว่าง machine — แต่มันแอคชั่นแทน user
• agent ต้องการ permission ที่จำกัดขอบเขตและเวลาชัดเจน ไม่ใช่สิทธิ user เต็มรูปแบบ

IdP ต้องรองรับอะไร#

Token Exchange (RFC 8693): agent + credential user รับ scoped token กลับมา token นี้ต้องมี: user ไหน, agent อะไร, scope อะไร, อายุเท่าไหร่

Agent เป็น client type ต่างหาก: ใหญ่กว่าการสร้าง API key หรือ share user token ต้องเป็น OAuth2 client ชนิดใหม่ที่มี client_id เป็นของตัวเอง

Delegated scope: user กำหนด permission เฉพาะที่ให้ agent ได้ read อย่างเดียว แต่ห้าม write, เข้าถึง resource บางอย่างได้

Audit log แยกแยะ: log ระหว่าง user ทำ X กับ agent ทำ X แทน user ต้องชัด ไม่งั้นสอบ SOC2 ไม่ผ่าน

MCP (Model Context Protocol)#

MCP กำลังกลายเป็นมาตรฐานให้ agent AI ใช้ติดต่อกับ tool/service ถ้า IdP ทำ auth กับ MCP ได้ผ่าน OAuth agent ก็ authenticate ได้ระดับ protocol แท้ ไม่ต้องพึ่ง API key/shared secret

คำถามสำคัญ#

• รองรับ OAuth2 Token Exchange มั้ย?
• agent เป็น client-type แยกจากปกติได้?
• token มี delegation info ฝัง (ใคร authorise, role/scpoe)?
• Audit log แยก action ของ agent/คน ได้ไหม?
• มี integration กับ MCP server หรือ OAuth ให้ agent-to-tool?

ถ้า vendor ไม่ตอบเรื่องพวกนี้ คือกำลังสร้างของปี 2020 — คุณควรคิดถึงปี 2026

มิติที่ 8: Non-functional — สิ่งที่ทำให้คุณนอนไม่หลับ#

ฟีเจอร์ขาย ระบบงานจริงตัดสินใจเรื่อง renew contract

Performance#

• Throughput: handle auth burst 100+ /วินาที หรือ 1,000+ ได้จริง?
• Latency การ validate token: service ควร validate JWT ใน local < 1 ms ถ้าต้อง introspect กับ IdP P99 latency เท่าไหร่?
• เพดาน scale: รองรับ MAU สูงสุดเท่าไร เคยรันที่ scale เป้าหมายจริงมั้ย?

Compliance#

• SOC2 Type II: ไม่เอาแค่ Type I (ตรวจเฉพาะจุดเวลา) ต้อง Type II (ตรวจยาวทั้งรอบ) ถ้ามีแต่ Type I รู้ว่าเมื่อไรจะได้ Type II
• Audit log: Event ทุกอย่าง export เข้า SIEM ได้มั้ย log เปลี่ยน permission/admin action log แก้ไม่ได้หรือเปล่า
• Data residency: บอกได้มั้ย user data อยู่ region ไหน ลูกค้า EU ห้ามข้ามเรื่องนี้

ความเชื่อถือได้#

• Uptime SLA: 99.9% = offline ได้ 8.7 ชม.ต่อปี, 99.99% = 52 นาทีต่อปี Auth คือประตูแอพ ต่างกันมาก
• Failover: Provider down ทำไง มี fallback, multi-region, failover มั้ย
• Incident history: ดู status page เจ้าเขา ไม่ใช่แค่คำสัญญา

Data portability#

• User export: export user พร้อม metadata, org, role ได้หมด? format อะไร?
• Standards compliance: ใช้ protocol มาตรฐาน (OIDC, SCIM) หรือเปล่า เวลาย้ายง่ายมั้ย?
• No lock-in signal: มีแต่ API/protocol/token proprietary = lock-in integration ใด ๆ ที่ไม่มาตรฐาน ย้ายออกยาก

Evaluation matrix: กรอบตัดสินใจแบบเป็นจริง#

เจาะลึกทุกมิติแล้ว ต้องเปรียบเทียบคะแนนจริง ใช้ framework นี้

P1 — ผ่าน/ไม่ผ่าน (must pass หรือ out)#

P2 — ควรมี (หายไปต้องเสียแรงทำเองหนัก)#

P3 — สำคัญ (วางแผนใช้ใน 12 เดือน)#

P4 — ดีถ้ามี (ไม่มีไม่เป็นไร)#

วิธีใช้งาน: เริ่มจาก P1 ถ้าเจ้าไหนไม่ผ่านข้อไหนหยุดทันที แล้ววัด P2/P3 ใครรวมคะแนนดีที่สุดคือคำตอบ

ข้อผิดพลาดประเมินระบบที่เจอบ่อย#

เราเห็นทีมพลาดแบบเดิม ๆ ตลอด นี่คือวิธีแก้:

พลาด 1: เน้นฟีเจอร์ไม่ดูสถาปัตยกรรมจริง#

เทียบ feature table บอกแค่มี ไม่มี ไม่บอกว่าทำมายังไง IdP บางเจ้าตีตั๋วว่ามี org ด้วยการเก็บ org_id ใน metadata ซึ่ง production จะมีปัญหาจริง

วิธีแก้: ทุกฟีเจอร์ถามต่อ "implement ยังไง" ไม่ใช่แค่ "มีมั้ย"

พลาด 2: ลืม migration ไปจนจบ process#

เลือก IdP ตามเดโม ทำจริงค่อยรู้ว่าต้อง reset password ฐาน user พัง ต้องติดอยู่กับ migration ห่วยหรือกลับไปเริ่ม process อีกรอบ

แก้: migration ต้องเป็น filter แรก ไม่ใช่ท้ายสุด

พลาด 3: เชื่อเดโมมากเกิน#

Demo vendor มาเนียนเสมอ ข้อมูล user ใหม่หมดไร้ขอบปัญหา Production มี user merge, Unicode แปลก, session ตกค้าง

วิธีแก้: ขอตัวอย่าง PoC จาก data จริง ใส่ผู้ใช้ 1,000 record แล้วลอง flow ตามจริง

พลาด 4: คนประเมินผิดกลุ่ม#

มีแต่ทีม platform evaluate เลือกของที่สะอาดแต่ integrate ยาก มีแต่ product เลือกของ integrate ง่ายแต่ขาด security มีแต่ security เลือกของ compliance ดีสุดแต่ใช้งานยาก

แก้: รวมทีม platform, product, security แต่ละทีมดูแล P1/P2 คนละจุด

พลาด 5: ลืมคิดว่าต้องย้ายออกวันหนึ่ง#

Vendor lock-in คือความจริง มี SDK/protocol/token เฉพาะจนย้ายออกยาก

แก้: เลือก IdP ที่ใช้ protocol มาตรฐาน (OIDC, OAuth2, SCIM) อนาคตจะขอบคุณตัวเอง

FAQ#

ใช้เวลาประเมิน IdP นานแค่ไหน?#

ถ้าครบถ้วน รวม PoC test เต็มๆ ให้เวลากับ process 4-8 สัปดาห์ ถ้าเร่งเกินปกติจะพลาด โดยเฉพาะ migration กะสัปดาห์แรก 2 วีกเก็บ requirement, 2-3 วีก evaluate + PoC, 1-2 วีก align stakeholder

ควรสร้าง auth เองแทนซื้อ IdP มั้ย?#

ขึ้นกับจำนวนผู้ใช้ ถ้าน้อยกว่า 10,000 ยังไม่มีลูกค้าองค์กร ใช้ไลบรารีเบา ๆ ก็โอเค แต่ถ้าต้องการ SSO, multi-tenant, MFA, compliance ทำเองแพงกว่า IdP จ้างวิศวกร 2-3 คนดูแล auth เอง หมายถึงโอกาสเสียเงิน 3-5 แสนเหรียญต่อปี

ต่างกันอย่างไรระหว่าง CIAM กับ workforce IAM?#

CIAM คืออะไรที่ user ของคุณเจอ — สมัคร, login, จัดการโปรไฟล์ Workforce IAM คือพนักงานใช้เข้า app ภายใน (SSO ให้ Slack, Google Workspace บริษัทคุณ ฯลฯ) เป็นการซื้อคนละแบบ ต้องประเมินต่างกัน นี่เป็น CIAM

Open-source กับ proprietary สำคัญแค่ไหน?#

Open-source IdP เผยโค้ด audit ได้, พกพาสะดวก, community เสริม Proprietary UI อาจเนียนกว่าและดูแลให้ แต่คำถามคือ "ไปต่อได้ไหมถ้าต้องย้ายออก?" Open-source ย้ายออกง่าย เพราะ data model/API public

auth agent AI ควรเป็น P1 หรือ P3?#

ถ้าคุณสร้าง AI ที่ต้อง access user data อยู่แล้ว (copilot, automaton) ให้เป็น P1 ถ้า roadmap มีใน 6-12 เดือนให้เป็น P3 ถ้ายังไม่เลยก็ปล่อยไปอยู่ P4 แล้วกลับมา review ใน 6 เดือน

ประเมินราคายังไงเมื่อแต่ละ vendor คิดแบบไม่เหมือนกัน?#

ส่วนใหญ่คิดแบบ MAU (Monthly Active User) แต่ "MAU" นับไม่เหมือนกัน — บ้างนับทุกล็อกอิน, บ้างนับ user unique, บ้างนับ connection M2M แยก ให้ vendor แจ้งราคาตาม use case จริง: user กี่คน, org กี่ org, M2M connection กี่ตัว, traffic login เท่าไร เทียบ total cost ไม่ใช่ unit

ข้อสรุป#

เลือก IdP คือ infrastructure ไม่ใช่ feature คุณกำลังเลือกอะไรที่จะ handle การ login อันแรกของ user ทุกคน, permission ทุก API, audit log ทุกการตรวจสอบ compliance

framework ข้างบนนี้คือสิ่งที่ต้องใช้ตัดสินใจจริง ไม่ใช่ bullet ที่ vendor ตั้งเอง ใช้ filter กวาดเร็วด้วย P1, ลงลึก P2/P3 พร้อมการทดสอบจริง แล้วตัดสินใจให้ไปไกลได้หลายปี

ทีมที่ได้ IdP ดีมีอย่างเดียวร่วมกัน: treat identity เป็น infrastructure ไม่ใช่ feature เล็ก ๆ ใน roadmap