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 — ลึกใน EP.15.5 — Web Services Trio)
• ออกแบบสำหรับ 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 ในเวลาเดียวกัน. ความเสียหายตอนนั้น = ราว 117,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