- 28
- มีนาคม
OAuth 2.0 คืออะไร? — ระบบยืนยันตัวตนที่ ERP ต้องรองรับ
OAuth 2.0 (Open Authorization 2.0) คือมาตรฐานเปิดสำหรับ Authorization (การอนุญาตให้เข้าถึง) ที่ให้แอปพลิเคชันหนึ่งเข้าถึงข้อมูลของผู้ใช้ในอีกระบบหนึ่ง โดยไม่ต้องรู้รหัสผ่าน ของผู้ใช้ เช่น เมื่อระบบ ERP ต้องดึงข้อมูลจากระบบ e-GP หรือเชื่อมต่อ ThaiD เพื่อยืนยันตัวตน OAuth 2.0 คือกลไกที่ทำให้เกิดขึ้นได้อย่างปลอดภัย
สรุปสั้น: OAuth 2.0 = มาตรฐาน "อนุญาตให้เข้าถึง" (Authorization) ไม่ใช่ "พิสูจน์ตัวตน" (Authentication) แอปขอ Token แทนรหัสผ่าน ทำให้เชื่อมต่อระบบภายนอกได้ปลอดภัย โดยผู้ใช้ควบคุมว่าจะให้เข้าถึงอะไรบ้าง
OAuth 2.0 ทำงานอย่างไร?
OAuth 2.0 มี 4 บทบาทหลักที่ทำงานร่วมกัน:
| บทบาท (Role) | ความหมาย | ตัวอย่างในระบบ ERP |
|---|---|---|
| Resource Owner | เจ้าของข้อมูล (ผู้ใช้งาน) ที่ให้ความยินยอมให้แอปเข้าถึงข้อมูลของตน | เจ้าหน้าที่ที่กด "อนุญาต" ให้ ERP ดึงข้อมูลจาก ThaiD |
| Client | แอปพลิเคชันที่ต้องการเข้าถึงข้อมูล ต้องลงทะเบียนกับ Authorization Server ก่อน | Saeree ERP ที่ต้องการดึงข้อมูลจากระบบภายนอก |
| Authorization Server | เซิร์ฟเวอร์ที่ตรวจสอบตัวตนผู้ใช้และออก Access Token ให้ Client | เซิร์ฟเวอร์ ThaiD, เซิร์ฟเวอร์ GFMIS |
| Resource Server | เซิร์ฟเวอร์ที่เก็บข้อมูล (API) รับเฉพาะ request ที่มี Access Token ที่ถูกต้อง | API ของระบบ e-GP, API ของ GFMIS |
ขั้นตอนการทำงาน (Authorization Code Flow)
Flow ที่ใช้มากที่สุดและปลอดภัยที่สุด มีขั้นตอนดังนี้:
| ขั้นตอน | ใครทำอะไร | รายละเอียด |
|---|---|---|
| 1 | ผู้ใช้กด "เข้าสู่ระบบด้วย ThaiD" | Client (ERP) ส่งผู้ใช้ไปยังหน้า login ของ Authorization Server |
| 2 | ผู้ใช้ยืนยันตัวตนและให้ความยินยอม | Authorization Server ตรวจสอบตัวตนและถามว่า "อนุญาตให้ ERP เข้าถึงข้อมูลหรือไม่?" |
| 3 | Authorization Server ส่ง Authorization Code กลับ | Code ชั่วคราว ส่งผ่าน browser redirect กลับมาที่ ERP |
| 4 | Client แลก Code เป็น Access Token | ERP ส่ง Code + Client Secret ไปที่ Authorization Server ผ่าน back-channel (server-to-server) |
| 5 | Client ใช้ Access Token เรียก API | ERP ส่ง Token ไปกับทุก request เพื่อดึงข้อมูลจาก Resource Server |
4 Grant Types ของ OAuth 2.0
OAuth 2.0 รองรับ 4 รูปแบบการขอ Token (Grant Type) แต่ละแบบเหมาะกับสถานการณ์ที่ต่างกัน:
| Grant Type | ใช้เมื่อไหร่ | ความปลอดภัย | สถานะ |
|---|---|---|---|
| Authorization Code | Web app, Mobile app ที่มี back-end server | สูงสุด — Token แลกผ่าน back-channel | แนะนำ (ใช้มากที่สุด) |
| Authorization Code + PKCE | Mobile app, SPA ที่ไม่มี Client Secret | สูง — เพิ่ม code_verifier ป้องกันดักจับ | แนะนำสำหรับ mobile/SPA |
| Client Credentials | Server-to-server (ไม่มีผู้ใช้เกี่ยวข้อง) | สูง — ใช้ Client ID + Secret | แนะนำ (M2M) |
| Implicit | SPA เดิมที่ไม่มี back-end | ต่ำ — Token ส่งผ่าน URL fragment | Deprecated (เลิกใช้แล้ว) |
| Resource Owner Password | Legacy app ที่ต้องส่ง username/password ตรง | ต่ำ — Client เห็นรหัสผ่านผู้ใช้ | ไม่แนะนำ |
คำแนะนำ: ปัจจุบัน IETF แนะนำให้ใช้ Authorization Code + PKCE สำหรับทุกกรณี (ทั้ง web และ mobile) และ Client Credentials สำหรับ server-to-server เท่านั้น Grant Type อื่นไม่แนะนำให้ใช้ในระบบใหม่
OAuth 2.0 vs Authentication — ต่างกันอย่างไร?
หลายคนสับสนระหว่าง OAuth 2.0 กับการยืนยันตัวตน (Authentication) ซึ่งจริงๆ แล้ว OAuth 2.0 คือ Authorization (อนุญาตให้เข้าถึง) ไม่ใช่ Authentication (พิสูจน์ว่าคุณคือใคร):
| ประเด็น | OAuth 2.0 (Authorization) | Authentication | OpenID Connect (OIDC) |
|---|---|---|---|
| คำถามที่ตอบ | "แอปนี้ทำอะไรได้บ้าง?" | "คุณคือใคร?" | ตอบได้ทั้งสองคำถาม |
| ผลลัพธ์ | Access Token (สิทธิ์เข้าถึง) | ยืนยันตัวตนสำเร็จ/ไม่สำเร็จ | Access Token + ID Token |
| ตัวอย่าง | ERP ดึงข้อมูลจาก API ภายนอก | ผู้ใช้ login ด้วยรหัสผ่าน | login ด้วย ThaiD เข้า ERP |
| มาตรฐาน | RFC 6749 | หลากหลาย (LDAP, SAML, etc.) | ต่อยอดจาก OAuth 2.0 |
OpenID Connect (OIDC) คือโปรโตคอลที่ต่อยอดจาก OAuth 2.0 เพิ่มความสามารถด้าน Authentication โดยส่ง ID Token (JWT) กลับมาพร้อม Access Token ทำให้รู้ว่า "ผู้ใช้คือใคร" และ "ให้เข้าถึงอะไรได้บ้าง" — นี่คือสิ่งที่ ThaiD Login ใช้
OAuth 2.0 vs API Key vs Basic Auth
เปรียบเทียบวิธีการยืนยันตัวตนและอนุญาตเข้าถึง API ที่พบบ่อย:
| ประเด็น | OAuth 2.0 | API Key | Basic Auth |
|---|---|---|---|
| วิธีส่ง credentials | Bearer Token ใน Header | Key ใน Header หรือ URL | username:password เข้ารหัส Base64 |
| ความปลอดภัย | สูง — Token มีอายุ, มี Scope, เพิกถอนได้ | ปานกลาง — ไม่มีอายุ, เพิกถอนยาก | ต่ำ — ส่งรหัสผ่านทุก request |
| ควบคุมขอบเขตสิทธิ์ | ได้ (Scope) | จำกัด (ทำได้ทุกอย่างที่ key อนุญาต) | ไม่ได้ (full access) |
| รองรับ Third-party | ได้ — ออกแบบมาเพื่อการนี้ | ได้บางส่วน | ไม่เหมาะ |
| เหมาะกับ | ระบบ ERP, Single Portal, ThaiD | Internal API, Webhook | ระบบเก่า, การทดสอบ |
ทำไม ERP ต้องรองรับ OAuth 2.0?
ในยุคที่ระบบราชการเชื่อมต่อกันมากขึ้น OAuth 2.0 กลายเป็นมาตรฐานที่ขาดไม่ได้:
- Single Portal ภาครัฐ — รัฐบาลกำหนดให้หน่วยงานเชื่อมข้อมูลผ่าน API มาตรฐาน OAuth 2.0 เป็นพื้นฐานของการเชื่อมต่อเหล่านี้
- ThaiD Login — ระบบยืนยันตัวตนดิจิทัลแห่งชาติใช้ OpenID Connect (ต่อยอดจาก OAuth 2.0) ERP ที่รองรับ OAuth 2.0 จึงเชื่อมต่อ ThaiD ได้ทันที
- เชื่อมต่อระบบภายนอก — ไม่ว่าจะเป็น GFMIS, e-GP, e-Tax Invoice หรือระบบธนาคาร OAuth 2.0 เป็นมาตรฐานที่ทุกระบบรองรับ
- API Economy — ยุคที่ระบบต้อง "คุยกัน" ได้ OAuth 2.0 ช่วยให้ ERP เชื่อมต่อกับระบบอื่น ได้อย่างปลอดภัยและเป็นมาตรฐาน
- ความปลอดภัย — ไม่ต้องเก็บรหัสผ่านของระบบอื่น Token มีอายุจำกัด เพิกถอนได้ทันที และกำหนด Scope ได้ละเอียด
ตัวอย่างการใช้งานจริงใน Saeree ERP
| Use Case | Grant Type ที่ใช้ | รายละเอียด |
|---|---|---|
| ThaiD Login | Authorization Code + PKCE (OIDC) | ผู้ใช้ login ด้วย ThaiD แล้ว ERP รับ ID Token + Access Token กลับมา ไม่ต้องเก็บรหัสผ่าน |
| API ระหว่างหน่วยงาน | Client Credentials | Saeree ERP ส่งข้อมูลงบประมาณไป GFMIS โดยใช้ Client ID/Secret แลก Token แบบ server-to-server |
| เชื่อมต่อ e-GP | Client Credentials | ดึงข้อมูลจัดซื้อจัดจ้างจากระบบ e-GP โดยอัตโนมัติ ใช้ Token ที่มีอายุจำกัด |
| ลายเซ็นดิจิทัล | Authorization Code | ผู้ใช้อนุญาตให้ ERP เรียกใช้บริการลายเซ็นดิจิทัลจาก CA ภายนอก |
คำศัพท์ที่เกี่ยวข้อง
| คำศัพท์ | ความหมาย |
|---|---|
| Access Token | โทเค็นที่ใช้เป็นหลักฐานว่าได้รับอนุญาตให้เข้าถึงทรัพยากรแล้ว มีอายุจำกัด (เช่น 15-60 นาที) ส่งไปกับทุก API request |
| Refresh Token | โทเค็นที่ใช้ขอ Access Token ใหม่โดยไม่ต้องให้ผู้ใช้ login ซ้ำ มีอายุยาวกว่า Access Token (เช่น 7-30 วัน) |
| Scope | ขอบเขตสิทธิ์ที่แอปร้องขอจากผู้ใช้ เช่น read:profile, write:documents ช่วยจำกัดสิทธิ์ตามหลัก Least Privilege |
| Bearer Token | รูปแบบการส่ง Access Token ใน HTTP Header: Authorization: Bearer <token> ใครมี Token ก็ใช้ได้ จึงต้องส่งผ่าน HTTPS เท่านั้น |
| PKCE (Proof Key for Code Exchange) | มาตรการเสริมความปลอดภัยของ Authorization Code Flow ใช้ code_verifier + code_challenge ป้องกันการดักจับ authorization code |
| OpenID Connect (OIDC) | โปรโตคอลที่ต่อยอดจาก OAuth 2.0 เพิ่มการ Authentication โดยส่ง ID Token (JWT) กลับมาด้วย ตัวอย่าง: ThaiD Login, Google Login |
| JWT (JSON Web Token) | รูปแบบ Token ที่เข้ารหัสข้อมูลผู้ใช้ไว้ภายใน ตรวจสอบได้โดยไม่ต้องเรียก database ทุกครั้ง ใช้เป็น ID Token ใน OIDC |
| Consent Screen | หน้าจอที่ถามผู้ใช้ว่า "อนุญาตให้แอปนี้เข้าถึงข้อมูลของคุณหรือไม่?" แสดง Scope ที่แอปร้องขอ |
ความสัมพันธ์ระหว่าง OAuth 2.0 กับ RBAC
OAuth 2.0 และ RBAC (Role-Based Access Control) ทำงานคนละระดับแต่เสริมกัน:
- OAuth 2.0 — ควบคุมว่า "แอปไหนเข้าถึง API ไหนได้บ้าง" (ระดับ Application)
- RBAC — ควบคุมว่า "ผู้ใช้คนไหนเห็นเมนูไหนได้บ้าง" (ระดับ User)
- ใช้คู่กัน — เมื่อผู้ใช้ login ผ่าน OAuth 2.0/OIDC เข้ามาแล้ว ระบบ ERP จะใช้ RBAC กำหนดว่าผู้ใช้คนนั้นเห็นข้อมูลอะไรบ้าง
- ร่วมกับ 2FA — เพิ่มความปลอดภัยอีกชั้นด้วย Two-Factor Authentication ก่อนออก Token
