กรอบการประเมิน IdP ที่ใช้งานได้จริง ถูกสร้างขึ้นจากความต้องการขององค์กรขนาดใหญ่จริง ๆ ครอบคลุมระดับลึกของโปรโตคอล การย้ายระบบ มัลติเทนซี การเตรียมพร้อมรับ AI และเกณฑ์ต่าง ๆ ที่รายการตรวจสอบส่วนใหญ่มองข้าม
บทความเปรียบเทียบผู้ให้บริการยืนยันตัวตน (IdP) ส่วนใหญ่มักเขียนโดยผู้ขาย IdP เอง น่าตกใจใช่ไหม? พวกเขาจะลิสต์แต่ฟีเจอร์ที่ตัวเองมี ข้ามสิ่งที่ไม่มี แล้วบอกว่านี่คือ "คู่มือแบบเป็นกลาง"
นี่ไม่ใช่แบบนั้น
เราได้รีวิวคำขอประเมินจากองค์กรจริงแบบนับสิบเจ้า — จากสเปรดชีตและเอกสาร RFP จริง ๆ ที่ฝ่ายจัดซื้อส่งให้ vendor แบบล้วน ๆ แล้ว Pattern จะชัดเจนมาก: ทีมวิศวกรรมมักให้ค่าน้ำหนักกับเกณฑ์ผิดจุด — ให้ค่าสิ่งไม่สำคัญเกินไป และมองข้ามของจำเป็น
ผลลัพธ์ที่เกิดขึ้น? ทีมเลือก IdP เพราะเดโม ดูเหมือนจะเวิร์ค พอหกเดือนผ่านไปตอนย้ายระบบจริงกลายเป็นฝันร้าย แล้วก็ต้องกลับมาประเมินใหม่
นี่คือกรอบการประเมินที่เราอยากมีตั้งแต่แรกสำหรับทีมวิศวกรรมของบริษัท SaaS B2B — ทีมที่สร้างโปรดักต์ ไม่ใช่ทีมที่เลือก workforce SSO ให้พนักงานตัวเอง
ถ้าคุณกำลังไล่อ่านแบบเร็ว ๆ นี่คือเวอร์ชั่นกระชับ:
คู่มือนี้จะแยกแต่ละมิติพร้อมตัวอย่างคำถามที่ควรถามและ Red Flag ที่ควรระวัง
ถ้านี่คือตัวคุณ:
ไม่ใช่สำหรับกรณีนี้:
ทุก IdP จะบอกว่ารองรับ OAuth2 กับ OIDC แต่นั่นเป็นแค่พื้นฐาน ของจริงต้องดูรายละเอียดลึก
ต้องมี:
เริ่มสำคัญขึ้นเรื่อย ๆ :
คำถามที่หลายทีมไม่เคยคิด: IdP นี้กลายเป็น OIDC Provider ให้คนอื่นใช้ login ได้มั้ย ไม่ใช่แค่กิน identity จากเจ้าอื่น?
ทำไมต้องแคร์: SaaS โตขึ้น คู่ค้าหรือพาร์ทเนอร์อาจอยากให้ระบบ identity ของคุณกลายเป็น SSO ให้ tool พวกเขาเอง คุณต้องออก token, มีระบบให้ app มากรอก consent, third-party app registration ถ้า IdP แค่ให้คุณ consume ภายนอกแต่ federate ออกข้างนอกไม่ได้ จะตันทันที
ถามว่า:
Token คือสัญญาระหว่าง IdP กับ service ถ้าปรับแต่งไม่ได้ downstream service ต้องยิง API ไปถาม role/permission เพิ่ม
ถามว่า:
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
ทุก IdP มี email/password & social login แปลว่าคุณยังไม่คัดใครออกเลย
แต่ของจริงอยู่ที่รายละเอียดเล็ก ๆ ที่ demo ไม่เคยโชว์
จุดนี้แหละที่แยก IdP เดโมกับ IdP ที่ใช้งานจริง Session/token management น่าเบื่อแต่ถ้าพัง ผู้ใช้โดนเตะออกทั้งระบบ
อาจดูไม่ไฮเทคแต่สำคัญมาก
app.yourproduct.com แต่ API คือ api.yourproduct.com session ข้าม subdomain ได้มั้ย ทำยังไง?User อยากล็อกอินทีเดียวอยู่ได้เป็นสัปดาห์ ไม่ใช่ 30 นาที แต่ session 180 วันกับ 30 นาที ความปลอดภัยต่างกันมาก
ถามว่า:
ถ้า IdP ไม่มี RBAC ไม่ต้องรีวิวต่อ แต่ถ้าเป็น B2B SaaS มีแค่ RBAC ไม่พอ
user สังกัดองค์กร มีสิทธิในแต่ละ org ต่างจากระดับ platform
user เดียวกันอาจเป็น admin ใน Org A แต่เป็น viewer ใน Org B ถ้า IdP ทำไม่ได้ ต้องสร้าง permission system แยกเองแล้วมี source of truth สองที่
ถามว่า:
แอพการเงิน, เฮลธ์แคร์ หรือที่มีความเสี่ยง: การแค่ล็อกอินยังไม่พอ
อ่าน dashboard ใช้ session cookie ได้แต่จะโอนเงินต้อง fresh MFA อีกชั้นต่อให้ล็อกอินแล้วก็ตาม
feature นี้เรียกว่า step-up authentication หรือ auth_level ต้องเป็น first-class citizen ของ token
ถามว่า:
auth_level ช่วย backend เช็ค privilege ได้ไหม?auth_level มี expiration แยกจาก session หลักได้มั้ย?IdP ขาดจุดนี้ต้องสร้างเอง — ในสิ่งที่จริง ๆ แล้วควรซื้อมาใช้
เป้าหมาย: API middleware อ่าน token เห็น org/role/auth_level ตัดสิน auth ได้ทันที
แต่ IdP ส่วนมาก token บอกแค่ user ใคร แต่อะไรที่ user ทำได้ต้องไป query API อีกที
ตรงนี้เพิ่ม latency, dependency, จุดพังที่ scale 1,000 req/sec, คุณไม่อยาก auth แล้วต้องชะลอรอ external call
สถิติที่ทุกคนไม่อยากเผย: กระบวนการเลือก IdP ส่วนมากจบเพราะ migrate ผู้ใช้เก่าไม่ได้ ไม่ใช่เพราะ IdP ไม่ดี
ถ้ามีผู้ใช้เกินแสน Migration ไม่ใช่ "nice to have" แต่มันคือทั้งโปรเจค
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 รองรับ:
3. Dual-write (รันสองระบบคู่ขนาน)
ระหว่างเปลี่ยน ระบบเก่า-ใหม่เขียนพร้อมกัน อ่านค่อย ๆ เปลี่ยนไปใหม่ มีทาง rollback แต่จะซับซ้อน
ตอบไม่ได้ชัด ให้ข้ามเลย แปลว่ายังไม่เคยทำ migration scale ใหญ่จริง
SaaS B2B = multi-tenancy ลูกค้าคือองค์กร มีผู้ใช้/role/policy เยอะ IdP ต้องเข้าใจ multipl org เป็นของจริง
บาง IdP ไม่มี org model เสนอใช้ user metadata (user.app_metadata.org_id = "123")
ซึ่งจะพังเร็วมาก:
ถ้า vendor บอกใช้ metadata แทน native org model เทียบเท่ากับเก็บ relational data ไว้ใน JSON ช่องเดียว — เวิร์คชั่วคราวแต่อีกหน่อยก็พัง
12 เดือนก่อน "AI agent authentication" ไม่มีใครพูดถึง ตอนนี้ถ้าคุณกำลังสร้างฟีเจอร์ AI เช่น copilot, agent, workflow อัจฉริยะ IdP ต้องรองรับ identity ประเภทใหม่: agent
โมเดลเก่ามี user + app เป็นผู้เล่นหลัก (OAuth2)
AI agent คือ entity ที่ 3 — ไม่ใช่ user ไม่มี password/เบราเซอร์, ไม่ใช่ machine-to-machine, แต่มัน acting on behalf of user, permission ต้องปกป้อง, audit trail ต้องชัด
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 กำลังกลายเป็นมาตรฐานให้ agent AI ใช้ติดต่อกับ tool/service ถ้า IdP ทำ auth กับ MCP ได้ผ่าน OAuth agent ก็ authenticate ได้ระดับ protocol แท้ ไม่ต้องพึ่ง API key/shared secret
ถ้า vendor ไม่ตอบเรื่องพวกนี้ คือกำลังสร้างของปี 2020 — คุณควรคิดถึงปี 2026
ฟีเจอร์ขาย ระบบงานจริงตัดสินใจเรื่อง renew contract
เจาะลึกทุกมิติแล้ว ต้องเปรียบเทียบคะแนนจริง ใช้ framework นี้
| เกณฑ์ | ทำไมเป็น P1 |
|---|---|
| Import password hash หรือ migration ทีละคน | ถ้าย้ายไม่ได้ เลิกใช้ได้เลย |
| Auth Code + PKCE | ฐานความปลอดภัย |
| Native org model | SaaS B2B ต้องการ |
| SOC2 Type II หรือ roadmap ชัด | ลูกค้า enterprise ต้องถาม |
| Uptime SLA 99.9%+ | Auth ล่ม = แอพล่ม |
| เกณฑ์ | เหตุผล |
|---|---|
| Custom JWT claims | ไม่ต้อง lookup permission ทุกรอบ |
| Policy ต่อ org | onboard ลูกค้าองค์กรได้จริง |
| Role/token scoped กับ org | auth multi-tenant จริง |
| Refresh token rotation/revoke | Security มาตรฐาน |
| Hosted UI + custom UI option | ยืดหยุ่นกับหลาย use case |
| เกณฑ์ | เหตุผล |
|---|---|
| Token Exchange (RFC 8693) | auth agent AI |
| OIDC Provider capability | partner federation |
| Step-up auth / auth_level | งานการเงิน/เสี่ยงสูง |
| SCIM provisioning | sync directory ลูกค้า enterprise |
| Passkey / WebAuthn | ไปทางไร้รหัสผ่าน |
| เกณฑ์ | เหตุผล |
|---|---|
| Analytics dashboard | query จาก audit log ได้ |
| White-labeled email | สะดวกเท่านั้น |
| Visual flow builder | สะดวกเท่านั้น |
| Social connector extra | provider นานาชาติ |
วิธีใช้งาน: เริ่มจาก P1 ถ้าเจ้าไหนไม่ผ่านข้อไหนหยุดทันที แล้ววัด P2/P3 ใครรวมคะแนนดีที่สุดคือคำตอบ
เราเห็นทีมพลาดแบบเดิม ๆ ตลอด นี่คือวิธีแก้:
เทียบ feature table บอกแค่มี ไม่มี ไม่บอกว่าทำมายังไง IdP บางเจ้าตีตั๋วว่ามี org ด้วยการเก็บ org_id ใน metadata ซึ่ง production จะมีปัญหาจริง
วิธีแก้: ทุกฟีเจอร์ถามต่อ "implement ยังไง" ไม่ใช่แค่ "มีมั้ย"
เลือก IdP ตามเดโม ทำจริงค่อยรู้ว่าต้อง reset password ฐาน user พัง ต้องติดอยู่กับ migration ห่วยหรือกลับไปเริ่ม process อีกรอบ
แก้: migration ต้องเป็น filter แรก ไม่ใช่ท้ายสุด
Demo vendor มาเนียนเสมอ ข้อมูล user ใหม่หมดไร้ขอบปัญหา Production มี user merge, Unicode แปลก, session ตกค้าง
วิธีแก้: ขอตัวอย่าง PoC จาก data จริง ใส่ผู้ใช้ 1,000 record แล้วลอง flow ตามจริง
มีแต่ทีม platform evaluate เลือกของที่สะอาดแต่ integrate ยาก มีแต่ product เลือกของ integrate ง่ายแต่ขาด security มีแต่ security เลือกของ compliance ดีสุดแต่ใช้งานยาก
แก้: รวมทีม platform, product, security แต่ละทีมดูแล P1/P2 คนละจุด
Vendor lock-in คือความจริง มี SDK/protocol/token เฉพาะจนย้ายออกยาก
แก้: เลือก IdP ที่ใช้ protocol มาตรฐาน (OIDC, OAuth2, SCIM) อนาคตจะขอบคุณตัวเอง
ถ้าครบถ้วน รวม PoC test เต็มๆ ให้เวลากับ process 4-8 สัปดาห์ ถ้าเร่งเกินปกติจะพลาด โดยเฉพาะ migration กะสัปดาห์แรก 2 วีกเก็บ requirement, 2-3 วีก evaluate + PoC, 1-2 วีก align stakeholder
ขึ้นกับจำนวนผู้ใช้ ถ้าน้อยกว่า 10,000 ยังไม่มีลูกค้าองค์กร ใช้ไลบรารีเบา ๆ ก็โอเค แต่ถ้าต้องการ SSO, multi-tenant, MFA, compliance ทำเองแพงกว่า IdP จ้างวิศวกร 2-3 คนดูแล auth เอง หมายถึงโอกาสเสียเงิน 3-5 แสนเหรียญต่อปี
CIAM คืออะไรที่ user ของคุณเจอ — สมัคร, login, จัดการโปรไฟล์ Workforce IAM คือพนักงานใช้เข้า app ภายใน (SSO ให้ Slack, Google Workspace บริษัทคุณ ฯลฯ) เป็นการซื้อคนละแบบ ต้องประเมินต่างกัน นี่เป็น CIAM
Open-source IdP เผยโค้ด audit ได้, พกพาสะดวก, community เสริม Proprietary UI อาจเนียนกว่าและดูแลให้ แต่คำถามคือ "ไปต่อได้ไหมถ้าต้องย้ายออก?" Open-source ย้ายออกง่าย เพราะ data model/API public
ถ้าคุณสร้าง AI ที่ต้อง access user data อยู่แล้ว (copilot, automaton) ให้เป็น P1 ถ้า roadmap มีใน 6-12 เดือนให้เป็น P3 ถ้ายังไม่เลยก็ปล่อยไปอยู่ P4 แล้วกลับมา review ใน 6 เดือน
ส่วนใหญ่คิดแบบ 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