IdP (Identity Provider) — รัฐบาลที่ออก passport#

IdP = ระบบที่เก็บข้อมูลตัวตนของคุณ + ออก passport ดิจิทัล

ในชีวิตจริง — IdP ที่คนใช้กันบ่อยที่สุด:

• Google (Google Workspace / Google Account) — IdP ที่ทุกคนมีอยู่แล้ว เพราะมี Gmail
• Microsoft Entra ID (เดิมชื่อ Azure AD) — IdP ของฝั่ง Microsoft 365 / Outlook
• Apple (Sign in with Apple) — IdP สำหรับฝั่ง iPhone / Mac
• Okta — IdP อิสระ ที่ไม่ผูกกับ ecosystem ไหน — บริษัทใหญ่ทั่วโลกเลือกเพราะ “ไม่ฝากชะตาไว้กับ Microsoft / Google”
• Facebook (Login with Facebook) — IdP สำหรับ consumer-facing apps

IdP ทำหน้าที่ 3 อย่าง: (1) เก็บ identity ของผู้ใช้ — username, password, MFA setting, profile, group membership. (2) ทำ authentication — เวลาผู้ใช้ login ที่ IdP — IdP ตรวจ password + MFA. (3) ออก token ให้ผู้ใช้นำไปยื่นที่ SP

ในบริษัท — IdP ของบริษัทคุณคือศูนย์กลางของ identity ทั้งหมด. ทุก SaaS ของบริษัทควร integrate กับ IdP ตัวเดียว. ลาออก = ลบ user ที่ IdP ครั้งเดียว = ทุก SaaS ตัด access อัตโนมัติ. นี่คือเหตุผลที่ EP.10 ผมพูดถึง centralized IAM — Federation คือเทคโนโลยีที่ทำให้มัน practical

SP (Service Provider) — ประเทศปลายทางที่ตรวจ passport#

SP = แอพ / บริการ / SaaS ที่ผู้ใช้ต้องการใช้งาน

Slack, Salesforce, Zoom, Notion, Figma, HubSpot, Asana, Dropbox, GitHub — ทุกตัวที่ผมยกมาตอนต้น — เป็น SP. แต่ละ SP มีฐานข้อมูลผู้ใช้ของตัวเอง — แต่แทนที่จะให้ผู้ใช้พิมพ์ password ที่ SP — มันยอมเชื่อ token ที่ IdP ออกให้

SP ทำหน้าที่ 3 อย่าง: (1) redirect ผู้ใช้ไปที่ IdP ตอนกดปุ่ม “Login with Google”. (2) รับ token กลับ หลัง IdP ออกให้. (3) ตรวจ signature ของ token ว่าเป็นของจริง + เปิดอ่านข้อมูลผู้ใช้จาก token

จุดสำคัญ — SP ไม่เคยเห็น password ของผู้ใช้เลย. password ของคุณอยู่ที่ Google เท่านั้น. Slack ไม่รู้ password คุณ. Salesforce ไม่รู้. นี่คือเหตุผลที่ Federation ปลอดภัยกว่าการสมัครสมาชิกใหม่ทุกที่ — เพราะ มี attack surface เดียวคือ IdP (และต้องป้องกันมันให้ดีที่สุด — ไม่ใช่กระจาย risk ไปทั่ว 50 SaaS)

Token / Assertion — passport ดิจิทัล#

Token = ไฟล์ดิจิทัลที่ IdP ออกให้ — ใช้เป็นหลักฐานยืนยันตัวตน

ในศัพท์ของ SAML — เราเรียก Assertion. ในศัพท์ของ OAuth / OIDC — เราเรียก Token. แต่ภาพในหัวเหมือนกัน — เอกสารดิจิทัลที่มีลายเซ็นของ IdP

ใน token จะมีข้อมูล:

• คุณคือใคร — user ID, email
• คุณมีสิทธิ์อะไร — role, group membership (บางที)
• IdP ออกตอนกี่โมง — timestamp
• token หมดอายุเมื่อไหร่ — expiry (สำคัญมาก — ส่วนใหญ่ 1 ชั่วโมง ถึง 1 วัน)
• token นี้ออกให้ใช้กับใคร — audience (เช่น “ให้ใช้กับ Slack เท่านั้น”)
• signature ของ IdP — ลายเซ็นที่ปลอมไม่ได้ ที่ทำให้ SP ตรวจได้ว่า token จริง

flow ของการใช้ token — เร็วๆ:

1. ผู้ใช้กดปุ่ม “Login with Google” ที่หน้า Slack
2. Slack redirect ผู้ใช้ไปที่ Google — พร้อมแนบข้อความว่า “ผู้ใช้นี้จะเข้า Slack ครับ ขอ token หน่อย”
3. Google ตรวจว่าผู้ใช้ login Google อยู่ไหม — ถ้ายัง ก็ถาม password + MFA
4. Google ออก token + redirect ผู้ใช้กลับ Slack — token แนบมาด้วย
5. Slack รับ token — ตรวจ signature ของ Google — เห็นข้อมูลใน token — รู้แล้วว่าผู้ใช้คือใคร — ให้เข้า

ทั้งหมดนี้ — ในมุมของผู้ใช้ — เห็นแค่ “กดปุ่ม → ระบบโหลด 1-2 วินาที → เข้าใช้ได้”. เบื้องหลัง — มี HTTP redirect, token, signature verification — ทั้งหมดเดินผ่าน browser ใน 1-2 วินาทีนั้น

มุมผู้บริหาร: จุดที่สำคัญที่สุดที่ผู้บริหารควรจำ — token เป็นของจริง = SP เชื่อ. token หาย = คนได้ token นั้นไป login ได้แทนคุณจนกว่าจะหมดอายุ. ไม่ต่างจาก passport เล่มจริง — ถ้าโจรขโมย passport คุณไป + รูปเหมือนคุณ — เขาเดินเข้าประเทศได้แทนคุณ. นี่คือเหตุผลที่ token theft เป็นการโจมตีที่อันตรายที่สุดของ Federation. EP นี้จะพาดูในหัวข้อ Federation gotchas

SAML 2.0 (2005) — passport รุ่นเก่าแก่ของ enterprise#

SAML (Security Assertion Markup Language) — เกิดที่ปี 2002 (เวอร์ชั่น 1.0) และโตเป็น SAML 2.0 ปี 2005. ตอนนั้น — โลก enterprise กำลังต้องการ SSO ข้ามบริษัท — เช่น พนักงานบริษัท A อยากเข้าระบบของ vendor B โดยไม่ต้องสมัครสมาชิกใหม่. SAML คือคำตอบของยุคนั้น

ลักษณะ SAML:

• ใช้ XML เป็นรูปแบบของ assertion — เพราะปี 2005 XML กำลังฮิตในวงการ enterprise (SOAP, WSDL, XSD ทุกอย่างเป็น XML)
• ออกแบบสำหรับ browser-based SSO — ผู้ใช้นั่งหน้าคอม กด login ในเว็บ — flow เดินผ่าน browser redirect
• มาตรฐาน enterprise — Active Directory Federation Services (ADFS) ของ Microsoft, Okta SSO, Ping Identity — ส่วนใหญ่ implement SAML
• ยังใช้กันแพร่หลายในปี 2026 — เพราะ enterprise IT ไม่เปลี่ยน protocol บ่อยๆ. ถ้า SAML ทำงานอยู่ ก็ปล่อยให้ทำงานต่อ

ปัญหาของ SAML: มันหนัก + เก่า. XML ยาว + งงตา. ไม่ออกแบบมาเพื่อ mobile app หรือ API — สำหรับ browser-based เท่านั้น. ยุค 2010s เป็นต้นมาที่โลกเริ่มใช้ mobile + API — SAML เริ่มอึดอัด

OAuth 2.0 (2012) — “ขอเข้าห้องของคนอื่น” (delegated authorization)#

OAuth 2.0 เกิดปี 2012 — ออกแบบเพื่อแก้ปัญหาที่ SAML ไม่ได้ออกแบบมาให้แก้. ปัญหาที่ว่าคือ — delegated authorization — หรือภาษาคน — “ฉันอนุญาตให้ app A เข้าถึงข้อมูลของฉันที่อยู่กับ service B”

ลองนึกตัวอย่างชีวิตจริง:

• คุณติดตั้ง app อ่าน QR code ของรถไฟฟ้า — แอพนี้อยากเก็บ ticket ใน Google Calendar ของคุณ. คำถาม: คุณจะให้ password Google ของคุณกับ app นี้ไหม? — แน่นอนว่าไม่. คุณไม่รู้ว่า app นี้ปลอดภัยแค่ไหน
• ทางเลือก — คุณกด “อนุญาตให้ app นี้เพิ่ม event ใน Calendar ของฉัน” — แอพได้ token พิเศษที่ทำได้ “แค่เพิ่ม event ใน Calendar” — เพิ่มอย่างอื่นไม่ได้ (อ่าน email ไม่ได้, ดูรูปไม่ได้)

นี่คือ OAuth 2.0 ครับ. มันคือ “ฉันอนุญาตให้ third party คนหนึ่ง ทำบางอย่างในชื่อของฉัน ที่บริการอื่น”. ใน OAuth ภาษา:

• Resource Owner = คุณ (เจ้าของข้อมูล)
• Resource Server = Google Calendar (ที่เก็บข้อมูล)
• Client = app อ่าน QR (ที่อยากเข้าข้อมูลของคุณ)
• Authorization Server = Google (ที่ออก token ให้ Client)
• Access Token = token ที่ Client เอาไปยื่นที่ Resource Server เพื่อทำสิ่งที่ขออนุญาต
• Scope = “อนุญาตให้ทำอะไรได้บ้าง” — เช่น calendar.write (เพิ่ม event ได้), calendar.read (อ่าน event ได้)

ข้อสำคัญที่หลายคนเข้าใจผิด — OAuth 2.0 ไม่ใช่ authentication protocol. OAuth ตอบคำถาม “ฉันอนุญาตให้ทำอะไร” — ไม่ใช่ “ฉันคือใคร”. แต่หลายเว็บก็เอา OAuth มาทำ authentication เพราะมันง่ายกว่า SAML + browser developer ส่วนใหญ่รู้จัก. ปัญหาคือ — OAuth ที่ใช้ผิดวิธีเป็น authentication = มีช่องโหว่หลายจุด (กลับมาดูในหัวข้อ Federation gotchas)

OIDC (OpenID Connect) (2014) — “OAuth + ID Card”#

วงการเห็นปัญหาที่ developer ใช้ OAuth ผิดวิธีเป็น authentication — เลยสร้าง protocol ใหม่ที่ปี 2014 ชื่อ OIDC (OpenID Connect)

OIDC = OAuth 2.0 + ID Token — เพิ่ม layer authentication ทับลงไปบน OAuth. ทำให้ developer ที่อยากทำ “Login with Google” ได้ protocol ที่ออกแบบมาเพื่อ authentication โดยตรง — ไม่ต้อง misuse OAuth อีกต่อไป

หน้าตา OIDC:

• ใช้ OAuth 2.0 เป็นฐาน — ใช้ flow เดียวกัน, scope เดียวกัน
• เพิ่ม ID Token — ที่เป็น JWT (จะลึกในหัวข้อถัดไป) — มีข้อมูล “ผู้ใช้คือใคร” — email, name, sub (subject ID)
• เพิ่ม UserInfo endpoint — SP สามารถถาม IdP เพิ่มได้ว่า “ผู้ใช้คนนี้มีข้อมูลอื่นอะไรไหม”
• มี scope พิเศษ — openid, profile, email — ที่บอกว่า “ฉันอยากได้ ID Token ด้วย ไม่ใช่แค่ access token”

ในปี 2026 — OIDC คือ standard ของ “Login with X” ในเว็บ consumer. ทุกครั้งที่คุณกดปุ่ม “Login with Google” ในเว็บ — เบื้องหลังเป็น OIDC. SAML ยังครอง enterprise (เพราะ ADFS / Okta enterprise plan ใช้ SAML). OAuth ครองงาน API + delegated permission. OIDC ครอง consumer login

สรุปง่ายๆ:

มุมผู้บริหาร: คุณไม่ต้องจำว่า SaaS ตัวไหนใช้ protocol ไหน — แต่ต้องรู้ว่า บริษัทคุณควร support ทั้ง SAML และ OIDC. ทำไม? — เพราะ enterprise SaaS รุ่นเก่าใช้ SAML, consumer-facing SaaS รุ่นใหม่ใช้ OIDC. ถ้า IdP ของคุณ (เช่น Microsoft Entra ID หรือ Okta) support ทั้งสอง — คุณ integrate กับ SaaS ใหม่ได้ทุกตัว ไม่ตกหล่น. ระบบ IdP ที่ขายๆ กันในปี 2026 — ส่วนใหญ่ support ทั้งหมดอยู่แล้ว — ตรวจให้แน่ใจตอนซื้อ

JWT คืออะไร — ตั๋วเข้าคอนเสิร์ตที่เคลือบลายเซ็นตรา#

ลองนึกภาพตั๋วเข้าคอนเสิร์ตของศิลปินดังครับ. ตั๋วนี้:

• บนหน้าตั๋ว — มีข้อมูลแสดงให้คนทั่วไปอ่านได้ — ชื่อคอนเสิร์ต, วันที่, ที่นั่ง, ชื่อผู้ซื้อ
• มุมขวาบน — มี ลายเซ็นตราของผู้จัดงาน — ที่เคลือบด้วยน้ำยาพิเศษที่ก๊อปปี้ไม่ได้
• คนตรวจที่หน้างาน — เห็นชื่อ + วันที่ + ที่นั่ง + ตรวจตราว่าจริงไหม

ใครก็ตามที่ถือตั๋วนี้ — เห็นข้อมูลบนตั๋วได้ทั้งหมด — ตั๋วไม่ได้ปกปิดข้อมูล. แต่ใครก็ตามที่อยากปลอมตั๋ว — ก๊อปข้อความได้ แต่ปลอมตราไม่ได้ เพราะตราต้องใช้น้ำยาพิเศษของผู้จัดเท่านั้น

JWT คือตั๋วในรูปดิจิทัลแบบนี้เป๊ะๆ ครับ. มัน:

• เปิดอ่านได้ — ใครก็ตามที่ถือ JWT เห็นข้อมูลข้างในได้หมด (Base64 = encoding ไม่ใช่ encryption — แปลงรูปได้ ไม่ใช่ปกปิด)
• มีลายเซ็นที่ปลอมไม่ได้ — เพราะลายเซ็นทำจาก secret key ของ IdP ที่เก็บไว้ที่เซิร์ฟเวอร์ IdP เท่านั้น
• SP ตรวจลายเซ็นเป็น = SP เชื่อข้อมูลใน JWT

โครงสร้าง 3 ส่วนของ JWT#

JWT แบ่งเป็น 3 ส่วน — คั่นด้วยเครื่องหมายจุด . — หน้าตาประมาณ:

1
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwiZW1haWwiOiJ0b29sc0A2Y29tbWFzLmNvbSJ9.signature_string_here

ดูเหมือนขยะ — แต่จริงๆ แบ่งเป็น 3 ส่วน:

ส่วนที่ 1 — Header — บอก JWT นี้ใช้ algorithm อะไรในการเซ็น. เช่น {"alg": "RS256", "typ": "JWT"} — แปลว่า “ลายเซ็นใช้ RSA SHA-256, นี่คือ JWT”

ส่วนที่ 2 — Payload (Claims) — ข้อมูลของผู้ใช้. เช่น:

1
{
2
  "sub": "user_123",
3
  "email": "[email protected]",
4
  "name": "Extra",
5
  "role": "admin",
6
  "iat": 1715455800,
7
  "exp": 1715459400
8
}

ทุกข้อมูลที่อยู่ใน payload — เรียกว่า claim (สิ่งที่ JWT อ้าง). sub = subject (user ID), iat = issued at (เวลาออก), exp = expiry (เวลาหมดอายุ — Unix timestamp). SP ตรวจ exp ทุกครั้ง — ถ้า token หมดอายุ = ไม่ให้เข้า

ส่วนที่ 3 — Signature — ลายเซ็น HMAC หรือ RSA ของ (Header + Payload) ที่เซ็นด้วย secret ของ IdP. นี่คือส่วนที่ปลอมไม่ได้

ข้อควรระวังของ JWT ที่ developer หลายคนพลาด#

ข้อที่ 1 — JWT payload เปิดอ่านได้. อย่าใส่ข้อมูลลับ (password, credit card, social security) ใน JWT payload — เพราะใครก็ตามที่ดักจับ JWT ได้ — เปิดอ่านได้หมด. JWT ปกป้องแค่ “ของแท้ไม่ปลอม” — ไม่ปกป้อง “ของลับไม่หลุด”

ข้อที่ 2 — ต้องตรวจ signature ทุกครั้ง. มี library JWT บางตัวมี option none algorithm — แปลว่า “ไม่ตรวจลายเซ็น เชื่อ payload เลย”. ในปี 2015 — มีหลาย site พลาดเปิด option นี้ — โจรปลอม JWT ไหนก็ได้ — ระบบเชื่อหมด. ต้อง always verify signature

ข้อที่ 3 — ต้องตรวจ exp ทุกครั้ง. ถ้า SP ไม่ตรวจ exp — token ที่หมดอายุไปแล้ว 6 เดือน — ยังใช้ได้อยู่ — เปิดทางให้ token theft

ข้อที่ 4 — Refresh Token + Access Token. ในระบบจริง — IdP ออก 2 token: Access Token (อายุสั้น 15 นาที - 1 ชั่วโมง — ใช้เข้า SP), Refresh Token (อายุยาว 30 วัน - 1 ปี — ใช้ขอ Access Token ใหม่ตอน Access Token หมดอายุ). การออกแบบนี้ลดความเสียหายถ้า Access Token หาย — เพราะมันหมดอายุเร็ว — แต่ Refresh Token ต้องเก็บลับสุด

มุมผู้บริหาร: JWT อยู่ในชีวิตคุณทุกวันโดยที่คุณไม่รู้ตัวครับ — Slack, Notion, Zoom, ทุก app ใน mobile — เก็บ JWT ของคุณไว้ในเครื่อง. คำถามที่ผู้บริหารควรถามทีม IT: “ถ้ามือถือพนักงานหาย — เรามีวิธี revoke (เพิกถอน) token ของเขาทุก SaaS ที่บริษัทใช้ได้ทันทีไหม?” ส่วนใหญ่คำตอบคือ “ได้ผ่าน IdP — ถ้าทุก SaaS integrate กับ IdP” — ถ้าตัวไหนไม่ผ่าน IdP = revoke ไม่ได้ = token นั้นใช้ได้จนกว่าจะหมดอายุเอง (อาจ 30 วัน)

Confused Deputy Attack — เผลออนุญาตให้คนอื่น#

Confused Deputy = “ผู้พิทักษ์ที่งง”. ตัวอย่างชีวิตจริงเร็วๆ — ลองนึกภาพรปภ. ของบริษัทคุณ. รปภ. มี กุญแจมาสเตอร์ เข้าได้ทุกห้องในตึก. มีคนเดินมาบอกรปภ.ว่า “เปิดประตูห้องการเงินให้หน่อย คุณ A สั่งมา”. รปภ. ไม่ได้เช็คกับคุณ A — เปิดให้เลย. นี่คือ confused deputy — รปภ. (ที่มีอำนาจ) ถูกหลอกให้ใช้อำนาจในทางที่ผู้สั่งจริงไม่ได้สั่ง

ใน OAuth — confused deputy เกิดเมื่อ app A ที่มี permission กว้าง ถูก app B หลอกให้ทำ action ที่เจ้าของไม่ได้อนุญาต. ป้องกันโดย — IdP ต้องตรวจ audience ของ token ว่าออกให้ app ไหน — token ของ app A ห้ามใช้ที่ app B

OAuth Consent Phishing — กดอนุญาตโดยไม่อ่าน#

นี่คือ attack ที่บริษัทไทยโดนเยอะที่สุดในปี 2024-2026 ครับ. ลองนึกฉาก:

1. โจรสร้าง app ปลอม ชื่อ “ChatGPT Pro for Office 365” — ตั้งให้ดูน่าเชื่อ
2. ส่งอีเมลหลอกพนักงาน “คลิกเพื่อ activate ChatGPT Pro ฟรี สำหรับองค์กร”
3. พนักงานกดลิงก์ — ไปหน้า Microsoft จริง — มี dialog ขึ้นมาถามว่า “App ‘ChatGPT Pro’ ขอ permission: อ่านอีเมลทั้งหมดของคุณ, ส่งอีเมลในชื่อคุณ, เข้าถึง OneDrive, เข้าถึง Teams”
4. พนักงานกด “Allow” โดยไม่อ่าน — คิดว่าเป็นแค่ Microsoft ถามมาตรฐาน
5. app ปลอมได้ OAuth token — อ่านอีเมลทั้งหมดของพนักงาน + ส่งอีเมลในชื่อพนักงาน + เข้า OneDrive ได้ทั้งหมด — ตลอดไป (จนกว่า admin จะ revoke)

จุดที่อันตราย — โจรไม่ต้องรู้ password ของพนักงานเลย. แค่หลอกให้กด Allow ครั้งเดียว — ได้ permission ทั้งหมด. และเพราะมัน “ผ่าน Microsoft ของจริง” — EDR + email filter ไม่จับ — เพราะมันเป็น legitimate OAuth flow

วิธีป้องกัน — admin ของ Microsoft 365 / Google Workspace ต้อง:

• เปิด admin consent required for third-party apps — แปลว่าไม่ให้พนักงานทั่วไป grant permission ให้ app ภายนอกเองได้
• review รายการ OAuth app ที่พนักงานเคย grant ทุกไตรมาส — revoke ตัวที่ไม่ใช้แล้ว
• ฝึกพนักงานให้ อ่าน permission ก่อนกด Allow — ถ้าเห็น “อ่านอีเมลทั้งหมด” = สงสัยทันที

Open Redirect + Token Theft — โจรหลอกให้ login ที่หน้าปลอม#

flow นี้:

1. โจรส่งลิงก์ที่เหมือน URL ของ IdP จริง — แต่ redirect ไปหน้าปลอมตอนหนึ่งของ flow
2. พนักงานพิมพ์ password ที่หน้าปลอม — โจรได้ password (หรือบางที — โจรเอา token ที่ออกแล้วไป)
3. โจรเอา token ของพนักงานไป login SP ตัวจริง — เข้าได้แบบเดียวกับพนักงาน

ป้องกันด้วย: MFA + Phishing-resistant MFA (FIDO2 / Hardware Key — กลับไปที่ EP.13). MFA ที่ phishing-resistant ผูกกับ domain ของหน้าเว็บจริง — ถ้าหน้าปลอม domain ผิด = MFA ไม่ทำงาน

เคสจริง 1: Twitter 2020 — Admin Panel Takeover ผ่าน Social Engineering#

15 กรกฎาคม 2020 — บัญชี Twitter ของ Barack Obama, Joe Biden, Elon Musk, Bill Gates, Apple, Uber — ทวีตข้อความหลอก Bitcoin ในเวลาเดียวกัน. ความเสียหายตอนนั้น = 121,000 USD ใน 3 ชั่วโมง (จริงๆ น้อยกว่าที่คิด — เพราะ Twitter รีบปิดทัน)

แต่ความเสียหายจริง = ความเชื่อมั่นของ Twitter เป็น platform ของบุคคลสำคัญ — พัง. และวิธีที่โจรเข้า — เปิดตำราของวงการ security ปี 2020-2025:

1. โจรโทรหา พนักงาน Twitter (ไม่ใช่ admin โดยตรง — แค่พนักงานปกติ) — แกล้งเป็น IT support ของ Twitter
2. หลอกให้พนักงานบอก OAuth credentials ที่ใช้เข้า Slack workspace ของ Twitter — ผ่านหน้า phishing ที่ปลอม
3. ใน Slack workspace มี admin tools ที่ใช้จัดการบัญชี Twitter — โจรหา credentials ของ admin tools จาก Slack message ของ admin
4. ใช้ admin tools — เปลี่ยน email ของ celebrity accounts — reset password — ทวีตข้อความหลอก

จุดที่เป็นบทเรียน — โจรไม่ได้ hack ระบบ Twitter เลย. ทุกอย่างผ่าน OAuth + admin tools + Slack — ของจริง — ในชื่อพนักงานจริง. นี่คือเหตุผลที่ EP.17 จะเล่าเรื่อง PAM (Privileged Access Management) — admin permission ต้องไม่ได้สิทธิ์ตลอดเวลา + ทุก action ต้องถูก log + review

เคสจริง 2: Okta 2022 Breach — IdP โดน Hack = ลูกค้าทั่วโลกพร้อมพัง#

มกราคม 2022 — Okta เปิดเผยว่า third-party support vendor (Sitel) โดนเจาะ. attacker ได้ access ไปยัง support engineer’s laptop — ที่มีสิทธิ์ใน Okta admin panel — เข้าถึงข้อมูลของลูกค้า Okta ได้บางส่วน

ทำไมเรื่องนี้ใหญ่? — เพราะ Okta คือ IdP ของบริษัทใหญ่ทั่วโลกหลายพันบริษัท. Cloudflare, T-Mobile, Microsoft (บางส่วน), FedEx — ทุกตัวใช้ Okta. ถ้า Okta พัง = บริษัทเหล่านั้นพร้อมพังเป็นโดมิโน่

จากนั้นในเดือนตุลาคม 2023 — Okta ถูก breach อีกครั้ง — caller-facing support system โดนเจาะ — ข้อมูลของลูกค้า Okta อีกจำนวนหนึ่งหลุด — ราคาหุ้น Okta ตก 11% ภายในวันเดียว

บทเรียนของวงการ:

• IdP คือ single point of failure ที่ใหญ่ที่สุดของบริษัท. ถ้า attacker ได้ admin ของ IdP = ได้ทุก SaaS ที่บริษัทใช้
• IdP ต้องมีระดับการป้องกันที่สูงกว่า service อื่น — MFA + Hardware Key + IP allowlist + admin tier separation + ทุก action log ส่งไป SIEM
• ระวัง third-party support / vendor access — Okta โดนผ่าน Sitel (vendor) — บริษัทคุณก็เช่นกัน — ถ้า vendor มี admin access = vendor คือจุดอ่อนที่อาจเป็น attack vector

มุมผู้บริหาร: Federation ดี — แต่ มันรวม risk ทั้งหมดไว้ที่ IdP. นี่ไม่ใช่ข้อเสีย — มันคือ trade-off. ทางเลือกอีกข้างคือ “กระจาย password ไป 50 SaaS” — ซึ่งแย่กว่าเพราะ attack surface กว้างกว่า. แต่ผู้บริหารต้องเข้าใจ trade-off นี้ — เลือก IdP ที่ secure ที่สุด + ใช้ MFA + ทำ security review IdP บ่อยกว่าระบบอื่น

บริษัทเล็ก (พนักงาน < 200 คน)#

คำแนะนำ: ใช้ IdP ที่มาฟรีกับ productivity suite ที่บริษัทใช้อยู่แล้ว

• ถ้าบริษัทใช้ Microsoft 365 — ใช้ Microsoft Entra ID (เดิม Azure AD) — มาฟรีกับ Microsoft 365 license. ทุก SaaS รุ่นใหม่ support Entra ID อยู่แล้ว
• ถ้าบริษัทใช้ Google Workspace — ใช้ Google as IdP — มาฟรี. Slack / Notion / Figma / Zoom — ทุกตัว support “Login with Google” อยู่แล้ว

ในขนาดนี้ — ไม่ต้องลงทุน IdP แยก. ใช้ของที่มีอยู่ + integrate ให้ดี. ค่าใช้จ่ายเพิ่มเติม = 0

บริษัทกลาง (200-2,000 คน)#

คำแนะนำ: เลือกตามจำนวน SaaS + ความซับซ้อนของ identity governance

• ถ้าใช้ SaaS น้อย (< 20 ตัว) + อยู่ใน ecosystem เดียว (Microsoft หรือ Google) — ใช้ IdP ของ ecosystem นั้นต่อไป
• ถ้าใช้ SaaS หลากหลาย (20+ ตัว) + ต้องการ identity governance ลึก (access review, automated provisioning, lifecycle management) — พิจารณา Okta หรือ JumpCloud — IdP อิสระที่ไม่ผูกกับ vendor เดียว
• Microsoft Entra ID P1/P2 plan ก็ใช้ได้ — มี feature ระดับ Okta แต่ถูกกว่าถ้าใช้ Microsoft 365 อยู่แล้ว

ในขนาดนี้ — ROI ของ IdP อิสระเริ่มคุ้ม. แต่ Microsoft Entra ID P1/P2 มักเพียงพอสำหรับบริษัทไทยขนาดกลางส่วนใหญ่

บริษัทใหญ่ (> 2,000 คน) + Multi-cloud#

คำแนะนำ: ใช้ IdP อิสระ + เน้น governance + zero trust

• Okta หรือ Ping Identity — IdP มืออาชีพที่ออกแบบสำหรับองค์กรใหญ่
• ต้องมี Identity Governance suite — automated provisioning + access review + lifecycle automation + segregation of duties
• ทุก admin account ต้องผ่าน PAM (EP.17 จะลึก) — Just-In-Time + session recording
• เริ่มเดินทางสู่ Zero Trust — ตำรวจตรวจที่ทุกประตู ไม่ใช่แค่ประตูหน้า

Trap ที่บริษัทไทยตกบ่อยที่สุด — Personal Account ใช้กับ SaaS บริษัท#

นี่คือกับดักที่เป็น pattern คลาสสิคของบริษัทไทยขนาดกลางเกือบทุกบริษัทครับ — พนักงานใช้ gmail ส่วนตัว / Apple ID ส่วนตัว / Facebook ส่วนตัว — login SaaS ของบริษัท

ตัวอย่างฉาก:

• พนักงาน marketing สมัคร Canva ด้วย gmail ส่วนตัว — แต่ใช้ออกแบบ artwork ของบริษัท + เก็บ brand asset ใน Canva account ส่วนตัว
• พนักงาน sales สมัคร Notion ด้วย gmail ส่วนตัว — ทำ CRM ของลูกค้าใน Notion ส่วนตัว
• พนักงาน HR สมัคร Zoom ด้วย gmail ส่วนตัว — มี recording ของ interview ผู้สมัครงาน

วันที่พนักงานคนนั้นลาออก:

• บริษัทไม่มีทางตัด access ได้ — เพราะ account ไม่ใช่ของบริษัท. gmail ส่วนตัวยังใช้ได้. Canva / Notion / Zoom ยังเข้าได้
• ข้อมูลของบริษัทอยู่ใน account ส่วนตัวของอดีตพนักงาน — ตามกฎหมาย PDPA = บริษัทรับผิด (เพราะเป็น data controller)
• ไม่มี audit log ในมุมของบริษัท — เพราะไม่ผ่าน IdP ของบริษัท

นี่คือ Orphan Account ของ EP.10 ที่สเกลใหญ่ระดับองค์กร. และมัน prevent ได้ง่ายมาก — บังคับให้ทุก SaaS ของบริษัทใช้ corporate email + corporate SSO เท่านั้น. ห้าม gmail ส่วนตัวเด็ดขาด

มุมผู้บริหาร: ลองออกคำสั่งง่ายๆ ในบริษัทคุณ — “ทุก SaaS ที่บริษัทใช้ ต้อง login ผ่าน @yourcompany.com เท่านั้น. ห้ามใช้ gmail / hotmail / Yahoo ส่วนตัว”. แล้วให้ IT scan ทุก SaaS — รายงานตัวที่ยังมีพนักงาน login ด้วย account ส่วนตัว. ส่วนใหญ่ — บริษัทไทยขนาดกลาง — จะตกใจกับตัวเลขที่ออกมา. การแก้ — migrate ทีละตัว — ใช้เวลา 1-3 เดือน — แต่หลังแก้เสร็จ = บริษัทคุณ revoke access ของอดีตพนักงานได้จริงในวันเดียว แทนที่จะ “ไม่มีทางตัดได้เลย”

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — ทุก SaaS ของบริษัทต้องผ่าน corporate SSO. ห้าม personal account เด็ดขาด

นี่คือข้อที่ผมอยากให้คุณจำที่สุดของ EP นี้ครับ. ในปี 2026 — บริษัทไทยขนาดกลางใช้ SaaS เฉลี่ย 40-80 ตัวต่อพนักงานหนึ่งคน. ถ้าครึ่งหนึ่งของ SaaS เหล่านั้น พนักงาน login ด้วย gmail ส่วนตัว = บริษัทคุณมี Orphan Account ระดับองค์กร — ทันทีที่มีใครลาออก = access ค้างถาวร + ข้อมูลบริษัทตกใน account ส่วนตัวของอดีตพนักงาน

4 ข้อที่ผู้บริหารควรสั่งทีม IT — ในเดือนนี้:

1. scan ทุก SaaS ที่บริษัทใช้ — รายชื่อตัวที่พนักงาน login ด้วย personal account
2. บังคับ corporate email + corporate SSO — ทุก SaaS ที่ support SSO ต้องเปิดใช้ SSO มาตรฐาน (SAML หรือ OIDC) ผ่าน IdP ของบริษัท
3. review OAuth permission รายไตรมาส — ทุก app ที่พนักงานเคย “Allow” — admin review + revoke ตัวที่ไม่จำเป็น
4. บล็อก gmail / hotmail / Yahoo ส่วนตัว จาก network ของบริษัท สำหรับงาน — บังคับให้ใช้ corporate email เป็นหลัก

ต้นทุนของการทำ = เวลา IT 1-3 เดือน. ROI = ตอนที่มีพนักงานลาออก / ตอนที่มี data breach — คุณ revoke access ได้จริง — แทนที่จะนั่งกุมขมับว่า “ตามกลับมาไม่ได้”

ข้อสอง — IdP คือ crown jewel ของยุค cloud. ปกป้องมันหนักกว่าทุก system อื่น

ข้อนี้เป็น mindset shift ที่ผู้บริหารหลายคนยังไม่เห็นภาพครับ. ใน EP.14 ผมพูดว่า Domain Admin = crown jewel ของบริษัทที่ใช้ Active Directory. ในยุค cloud + Federation — IdP admin = crown jewel ใหม่. ถ้า attacker ได้ admin ของ Microsoft Entra ID หรือ Okta = ได้ทุก SaaS ที่บริษัทใช้ทันที — เพราะทุก SaaS เชื่อ token ที่ IdP ออก

หลักการที่ต้องยึด:

• IdP admin ใช้ MFA + Hardware Key เท่านั้น — ไม่ใช่ SMS OTP. กลับไปที่ EP.13 — phishing-resistant MFA = FIDO2 / Hardware Key
• IdP admin ต้องผ่าน PAM — EP.17 จะลึก — แต่หลักการพื้นฐาน — admin ของ IdP ต้องไม่มีสิทธิ์ตลอดเวลา — ต้องขอสิทธิ์ทุกครั้งที่ใช้ + session recorded
• review IdP audit log รายสัปดาห์ — admin login ตอน ตี 3 จาก IP ใหม่ = alert. user provisioning ผิดปกติ = alert
• มี backup IdP plan — ถ้า Okta หรือ Microsoft Entra ID ล่ม = ทั้งบริษัทเข้าระบบไม่ได้ทันที. ต้องมีแผน emergency access (break-glass account) ที่เก็บที่อื่น
• third-party / vendor access ผ่าน IdP ต้อง audit เป็นพิเศษ — Okta โดน hack ผ่าน Sitel (vendor). บริษัทคุณ — vendor ทั้งหมดที่มี access ต้องผ่าน MFA + ทำ access review

ในวงการ security ปี 2026 — บริษัทที่มี IdP ที่ปกป้องไม่ดี = ไม่ใช่คำถามว่าจะโดนเมื่อไหร่ — เป็นคำถามว่า ใครจะมาก่อน — ransomware, BEC, หรือ data breach. การลงทุนใน IdP security = ลงทุน 1 ครั้ง — ปกป้อง 50+ SaaS — ROI สูงที่สุดในงาน cybersecurity ปี 2026