- 28
- มีนาคม
OpenID Connect (OIDC) คืออะไร? — มาตรฐาน Authentication ที่ต่อยอดจาก OAuth 2.0
OpenID Connect (OIDC) คือโปรโตคอล Authentication (การพิสูจน์ตัวตน) ที่สร้างเป็นชั้นบน OAuth 2.0 ทำให้แอปพลิเคชันไม่เพียงรู้ว่า "ผู้ใช้อนุญาตให้เข้าถึงอะไร" แต่ยังรู้ว่า "ผู้ใช้คือใคร" — เช่น ชื่อ อีเมล เลขบัตรประชาชน โดยผ่าน ID Token ในรูปแบบ JWT
สรุปสั้น: OAuth 2.0 = "อนุญาตให้เข้าถึง" (Authorization) ส่วน OIDC = "พิสูจน์ว่าคุณคือใคร" (Authentication) + Authorization — OIDC เพิ่ม ID Token เข้ามาเพื่อบอกข้อมูลตัวตนผู้ใช้ ทำให้ระบบ ERP รู้ว่าใครกำลังใช้งานอยู่
OAuth 2.0 vs OIDC — ต่างกันอย่างไร?
หลายคนสับสนระหว่าง OAuth 2.0 กับ OIDC เพราะ OIDC สร้างอยู่บน OAuth 2.0 แต่มีจุดประสงค์ต่างกัน:
| ประเด็น | OAuth 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| หน้าที่หลัก | Authorization (อนุญาตให้เข้าถึงทรัพยากร) | Authentication + Authorization (พิสูจน์ตัวตน + อนุญาต) |
| คำถามที่ตอบ | "แอปนี้มีสิทธิ์เข้าถึงข้อมูลของฉันไหม?" | "ผู้ใช้คนนี้คือใคร?" + "มีสิทธิ์เข้าถึงอะไร?" |
| Token ที่ออกให้ | Access Token เท่านั้น | ID Token + Access Token |
| ข้อมูลผู้ใช้ | ไม่มีมาตรฐาน (ต้อง call API เอง) | มี Claims มาตรฐาน (name, email, sub) ใน ID Token |
| Discovery | ไม่มี | มี .well-known/openid-configuration |
| ตัวอย่างการใช้ | แอปขอเข้าถึง Google Drive ของผู้ใช้ | "เข้าสู่ระบบด้วย Google" หรือ "เข้าสู่ระบบด้วย ThaiD" |
OIDC ทำงานอย่างไร? — Authorization Code Flow
Flow ที่แนะนำสำหรับระบบ ERP คือ Authorization Code Flow ซึ่งเป็น flow ที่ปลอดภัยที่สุด เหมาะกับ web application ที่มี backend server:
| ขั้นตอน | ผู้ทำ | รายละเอียด |
|---|---|---|
| 1. ผู้ใช้กดปุ่ม Login | ผู้ใช้ | กดปุ่ม "เข้าสู่ระบบด้วย ThaiD" บนหน้า ERP |
| 2. Redirect ไป OpenID Provider | แอป ERP | ส่ง request ไป Authorization Endpoint พร้อม scope=openid, response_type=code, redirect_uri, state, nonce |
| 3. ผู้ใช้ยืนยันตัวตน | OpenID Provider | ผู้ใช้ login ที่ ThaiD (สแกนหน้า, PIN) แล้วอนุญาตให้แชร์ข้อมูล |
| 4. ส่ง Authorization Code กลับ | OpenID Provider | Redirect กลับมาที่ ERP พร้อม Authorization Code (ใช้ได้ครั้งเดียว) |
| 5. แลก Code เป็น Token | Backend ERP | ส่ง Code + client_secret ไป Token Endpoint ได้รับ ID Token + Access Token |
| 6. ตรวจสอบ ID Token | Backend ERP | Verify signature, iss, aud, exp, nonce แล้วอ่าน Claims (ชื่อ, เลขบัตร, อีเมล) |
| 7. สร้าง Session | Backend ERP | จับคู่ข้อมูลกับ user ในระบบ ERP สร้าง session ให้ผู้ใช้เข้าสู่ระบบสำเร็จ |
จุดสำคัญ: Authorization Code ถูกส่งผ่าน browser (front-channel) แต่การแลก Token ทำที่ backend (back-channel) ทำให้ Access Token และ ID Token ไม่ถูกเปิดเผยต่อ browser โดยตรง — เพิ่มความปลอดภัยอย่างมาก
ID Token vs Access Token — เปรียบเทียบ
OIDC ออก Token 2 ชนิดที่มีหน้าที่ต่างกัน:
| ประเด็น | ID Token | Access Token |
|---|---|---|
| จุดประสงค์ | พิสูจน์ตัวตน — "ผู้ใช้คือใคร" | อนุญาตเข้าถึง — "ทำอะไรได้บ้าง" |
| รูปแบบ | JWT เสมอ (Header.Payload.Signature) | อาจเป็น JWT หรือ opaque string |
| ข้อมูลที่บรรจุ | sub, name, email, iss, aud, exp, nonce | scope, permissions (ขึ้นกับ provider) |
| อายุ (Lifetime) | สั้น (5-60 นาที) — ใช้ครั้งเดียวเพื่อสร้าง session | สั้น-ปานกลาง (1-24 ชั่วโมง) — ใช้เรียก API ซ้ำได้ |
| ใครตรวจสอบ | Client (แอป ERP) ตรวจสอบเอง | Resource Server (API Server) ตรวจสอบ |
| ส่งไปที่ไหน | ไม่ส่งไปที่ API — ใช้ภายใน client เท่านั้น | ส่งไปใน Authorization header เมื่อเรียก API |
คำศัพท์สำคัญของ OIDC
คำศัพท์ที่ทีม Implement ต้องเข้าใจเมื่อ integrate ระบบ ERP กับ OpenID Provider:
| คำศัพท์ | ความหมาย | ตัวอย่าง |
|---|---|---|
| ID Token | โทเค็น JWT ที่ OpenID Provider ออกให้ บรรจุข้อมูลยืนยันตัวตนผู้ใช้ | eyJhbGciOiJSUzI1NiIs... (JWT 3 ส่วน) |
| Claims | ข้อมูลชิ้นย่อยที่อยู่ใน Token เช่น ชื่อ อีเมล เลขบัตรประชาชน | "sub": "1234567890", "name": "สมชาย", "email": "..." |
| UserInfo Endpoint | API ที่ให้ข้อมูลผู้ใช้เพิ่มเติม ต้องส่ง Access Token ไปด้วย | GET /userinfo พร้อม Bearer token |
| Issuer (iss) | URL ของ OpenID Provider ผู้ออก Token | https://thaid.goth.or.th, https://accounts.google.com |
| Subject (sub) | ตัวระบุเฉพาะของผู้ใช้ที่ Issuer กำหนด ไม่ซ้ำกัน | "sub": "110248560174256879" (Google), เลขบัตร 13 หลัก (ThaiD) |
| Nonce | ค่าสุ่มที่ client สร้างขึ้น ส่งไปตอน request แล้วเช็คใน ID Token เพื่อป้องกัน replay attack | "nonce": "abc123xyz" |
| JWT (JSON Web Token) | รูปแบบมาตรฐานสำหรับส่งข้อมูลอย่างปลอดภัย 3 ส่วน: Header, Payload, Signature | xxxxx.yyyyy.zzzzz (Base64 encoded) |
| Discovery Document | ไฟล์ JSON ที่ .well-known/openid-configuration บอกข้อมูลทั้งหมดของ Provider | authorization_endpoint, token_endpoint, jwks_uri, supported scopes |
OIDC กับ Single Sign-On (SSO) — ทำไมเป็นมาตรฐาน SSO ยุคใหม่?
SSO (Single Sign-On) คือการที่ผู้ใช้ login ครั้งเดียวแล้วเข้าถึงหลายระบบได้โดยไม่ต้อง login ซ้ำ OIDC กลายเป็นมาตรฐาน SSO ยุคใหม่เพราะใช้งานง่าย รองรับ web + mobile และมี Discovery Document ที่ทำให้ integrate ได้รวดเร็ว:
| ประเด็น | OIDC | SAML 2.0 | LDAP |
|---|---|---|---|
| ปีที่เผยแพร่ | 2014 | 2005 | 1993 |
| รูปแบบข้อมูล | JSON / JWT | XML | Binary (ASN.1) |
| รองรับ Mobile | ดีมาก (JSON เบา, OAuth-based) | จำกัด (XML หนัก) | ไม่รองรับโดยตรง |
| ความซับซ้อนในการ Integrate | ต่ำ — มี Discovery Document + library เยอะ | ปานกลาง-สูง — ต้อง config metadata XML | สูง — ต้อง config schema + firewall |
| SSO | รองรับ (ผ่าน session ที่ OpenID Provider) | รองรับ (จุดแข็งหลัก) | ไม่ใช่ SSO โดยตรง (ใช้ร่วมกับ Kerberos) |
| ตัวอย่างผู้ให้บริการ | Google, ThaiD, Azure AD, Keycloak | ADFS, Shibboleth, Okta | Active Directory, OpenLDAP |
| เหมาะกับ | Web + Mobile + API ยุคใหม่ | Enterprise SSO ระบบเก่า | Internal network, directory service |
ทำไม ERP ต้องรองรับ OIDC?
ในยุคที่รัฐบาลไทยผลักดัน Digital Government การรองรับ OIDC ในระบบ ERP ไม่ใช่ทางเลือก แต่กลายเป็น ข้อกำหนด:
- ThaiD Login ใช้ OIDC — ระบบยืนยันตัวตนดิจิทัลของกรมการปกครอง (DOPA) ใช้โปรโตคอล OIDC เป็นหลัก หน่วยงานรัฐที่ต้อง integrate กับ ThaiD จึงต้องรองรับ OIDC
- Single Portal ภาครัฐ — แผน Digital Government Plan 2025-2027 กำหนดให้หน่วยงานรัฐใช้ระบบ Login กลาง (Single Sign-On) เพื่อให้ประชาชนเข้าถึงบริการหลายหน่วยงานด้วยบัญชีเดียว
- ลดภาระจัดการรหัสผ่าน — เมื่อใช้ OIDC ระบบ ERP ไม่ต้องเก็บรหัสผ่านเอง ลดความเสี่ยงจากการรั่วไหลของข้อมูลรหัสผ่าน
- 2FA ฝั่ง Provider — OpenID Provider (เช่น ThaiD) จัดการ Multi-Factor Authentication เอง ระบบ ERP ไม่ต้อง implement 2FA ซ้ำ
- API Authentication — ระบบ ERP ที่เปิด API สำหรับระบบภายนอก (เช่น GFMIS, e-GP) สามารถใช้ Access Token จาก OIDC เพื่อยืนยันตัวตนของระบบที่เรียกใช้
ตัวอย่างใน Saeree ERP
Saeree ERP รองรับ OIDC สำหรับการ integrate กับระบบ identity ของหน่วยงานรัฐ:
| Use Case | OpenID Provider | ข้อมูลที่ได้รับ |
|---|---|---|
| ThaiD Login | ThaiD (DOPA) | เลขบัตรประชาชน, ชื่อ-นามสกุล, วันเกิด |
| SSO หน่วยงานรัฐ | Keycloak / Azure AD ของหน่วยงาน | รหัสพนักงาน, ตำแหน่ง, สังกัด, อีเมล |
| API Authentication | Saeree ERP (เป็น Resource Server) | ตรวจสอบ Access Token จาก client ภายนอก |
เมื่อผู้ใช้ login ผ่าน ThaiD สำเร็จ Saeree ERP จะจับคู่เลขบัตรประชาชน (sub claim) กับบัญชีผู้ใช้ในระบบ แล้วกำหนด Role (RBAC) ตามตำแหน่งที่ตั้งไว้ — ผู้ใช้ไม่ต้องจำรหัสผ่านแยกสำหรับระบบ ERP
สำคัญสำหรับทีม Implement: เมื่อ integrate OIDC ต้องตรวจสอบ ID Token ทุกครั้ง — verify signature ด้วย JWKS, เช็ค iss ตรงกับ provider ที่คาดหวัง, เช็ค aud ตรงกับ client_id ของเรา, เช็ค exp ยังไม่หมดอายุ, และเช็ค nonce ตรงกับที่ส่งไป
