ในยุคที่เว็บแอปพลิเคชันและ API เชื่อมต่อกันอย่างซับซ้อน การจัดการสิทธิ์การเข้าถึงและการยืนยันตัวตนเป็นเรื่องสำคัญที่นักพัฒนาและผู้ดูแลระบบทุกคนต้องเข้าใจ OAuth 2.0 และ OpenID Connect (OIDC) คือมาตรฐานที่ใช้กันทั่วโลกสำหรับสองสิ่งนี้ครับ

OAuth 2.0 คืออะไร?

OAuth 2.0 ย่อมาจาก Open Authorization 2.0 เป็น framework มาตรฐานสำหรับการให้ Authorization (การมอบสิทธิ์) ให้แอปพลิเคชันหนึ่งสามารถเข้าถึงทรัพยากรของอีกแอปพลิเคชันในนามของผู้ใช้ โดยที่ไม่ต้องแชร์ Password ครับ

ตัวอย่างที่ง่ายที่สุดคือปุ่ม “Login with Google” หรือ “Login with Facebook” ที่เห็นตามเว็บไซต์ต่างๆ เมื่อคุณกดปุ่มนั้น เว็บไซต์ไม่ได้รู้จัก Password Gmail ของคุณเลย แต่ Google อนุญาตให้เว็บไซต์นั้นเข้าถึงข้อมูลบางส่วนของคุณแทน

ความแตกต่างระหว่าง Authentication กับ Authorization

ก่อนเข้าใจ OAuth ต้องแยกสองคำนี้ให้ชัดก่อนครับ:

• Authentication (AuthN) — การพิสูจน์ว่า คุณคือใคร เช่น การล็อกอินด้วย Username/Password
• Authorization (AuthZ) — การกำหนดว่า คุณทำอะไรได้บ้าง เช่น สิทธิ์อ่านไฟล์ แก้ไขข้อมูล หรือลบบัญชี

OAuth 2.0 ออกแบบมาสำหรับ Authorization เท่านั้น ไม่ใช่ Authentication ครับ นี่คือจุดที่หลายคนเข้าใจผิด

OAuth 2.0 ทำงานอย่างไร?

OAuth 2.0 มี 4 ฝ่ายหลักที่เกี่ยวข้อง:

1. Resource Owner — เจ้าของข้อมูล (ตัวผู้ใช้เอง)
2. Client — แอปพลิเคชันที่ต้องการเข้าถึงข้อมูล
3. Authorization Server — เซิร์ฟเวอร์ที่ออก Token (เช่น Google, Facebook)
4. Resource Server — เซิร์ฟเวอร์ที่เก็บข้อมูลจริง (เช่น Google Drive API)

ขั้นตอนการทำงานแบบ Authorization Code Flow

Flow ที่ปลอดภัยที่สุดและใช้กันมากที่สุดคือ Authorization Code Flow:

1. ผู้ใช้คลิก “Login with Google” บนแอปของคุณ
2. แอปส่งผู้ใช้ไปยัง Google Authorization Server พร้อม client_id, redirect_uri, scope
3. ผู้ใช้ล็อกอินที่ Google และกด “อนุญาต”
4. Google ส่ง Authorization Code กลับมาที่ redirect_uri ของแอป
5. แอปนำ Authorization Code ไปแลก Access Token กับ Google (ฝั่ง Server)
6. แอปใช้ Access Token เรียก Google API เพื่อดึงข้อมูลที่ได้รับอนุญาต

OAuth 2.0 Grant Types ที่ควรรู้

OpenID Connect (OIDC) คืออะไร?

เนื่องจาก OAuth 2.0 ออกแบบมาสำหรับ Authorization เท่านั้น ทำให้นักพัฒนาหลายคนนำมาใช้สำหรับ Authentication ด้วยแบบผิดวิธี จึงเกิด OpenID Connect (OIDC) ขึ้นมาครับ

OIDC คือ Layer การ Authentication ที่สร้างต่อยอดบน OAuth 2.0 โดยเพิ่มกลไกยืนยันตัวตนผู้ใช้เข้ามา ทำให้แอปรู้ได้ว่า ผู้ใช้คนนี้คือใคร

ID Token คืออะไร?

สิ่งที่ OIDC เพิ่มเข้ามาคือ ID Token ซึ่งเป็น JWT (JSON Web Token) ที่มีข้อมูลเกี่ยวกับผู้ใช้ เรียกว่า Claims เช่น:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "name": "Somchai Jaidee",
  "email": "[email protected]",
  "iat": 1711500000,
  "exp": 1711503600
}

ความแตกต่างระหว่าง OAuth 2.0 และ OIDC

Scope ใน OAuth 2.0 คืออะไร?

Scope คือการกำหนดขอบเขตสิทธิ์ที่แอปพลิเคชันขอจากผู้ใช้ เช่น:

• openid — ขอ ID Token (OIDC)
• profile — ขอข้อมูลชื่อ รูปภาพ
• email — ขออีเมล
• read:files — ขอสิทธิ์อ่านไฟล์
• write:posts — ขอสิทธิ์เขียนโพสต์

หลักการสำคัญคือ Principle of Least Privilege — ขอสิทธิ์เท่าที่จำเป็นเท่านั้น

JWT (JSON Web Token) คืออะไร?

ทั้ง OAuth 2.0 และ OIDC มักใช้ JWT เป็น Token format ครับ JWT มีโครงสร้าง 3 ส่วนคั่นด้วย .:

1. Header — ระบุ algorithm การเซ็น เช่น RS256, HS256
2. Payload — ข้อมูล Claims ของผู้ใช้
3. Signature — ลายเซ็นดิจิทัลป้องกันการปลอมแปลง

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ข้อสำคัญ: Payload ของ JWT ไม่ได้ถูกเข้ารหัส (เป็นแค่ Base64) ใครก็ decode ได้ แต่ แก้ไขไม่ได้ เพราะ Signature จะเสีย ดังนั้นอย่าเก็บข้อมูลลับใน JWT

PKCE คืออะไร ทำไมต้องใช้กับ Mobile/SPA?

PKCE (Proof Key for Code Exchange, ออกเสียงว่า “pixie”) เป็นส่วนเสริมสำหรับ Authorization Code Flow ที่ป้องกันการโจมตีแบบ Authorization Code Interception Attack ครับ

เหมาะสำหรับ Public Clients เช่น Mobile App และ Single Page Application (SPA) ที่ไม่สามารถเก็บ Client Secret ได้อย่างปลอดภัย วิธีการทำงานคือ:

1. แอปสร้าง code_verifier แบบ Random ขึ้นมา
2. Hash ด้วย SHA-256 ได้ code_challenge
3. ส่ง code_challenge พร้อม Authorization Request
4. เมื่อแลก Token ส่ง code_verifier เดิมไปด้วย
5. Server ตรวจสอบว่า Hash ตรงกันไหม

Refresh Token คืออะไร?

Access Token มีอายุสั้น (ปกติ 15 นาที ถึง 1 ชั่วโมง) เพื่อความปลอดภัย แต่ถ้าหมดอายุแล้วต้องให้ผู้ใช้ล็อกอินใหม่ทุกครั้งก็ไม่สะดวก นี่คือที่มาของ Refresh Token ครับ

Refresh Token มีอายุนาน (หลายวันถึงหลายเดือน) และใช้แลก Access Token ใหม่ได้โดยไม่ต้องให้ผู้ใช้ทำอะไร แต่ต้องเก็บอย่างปลอดภัยและส่งผ่าน HTTPS เท่านั้น

ความปลอดภัยที่ต้องระวังเมื่อใช้ OAuth บน Cloud VPS

สำหรับการ Deploy บน Cloud VPS ของ DE มีสิ่งที่ควรคำนึงถึงครับ:

ตั้งค่า HTTPS บังคับ

OAuth 2.0 และ OIDC ต้องใช้ HTTPS เสมอ ห้ามใช้ HTTP เด็ดขาด เพราะ Token จะถูก intercept ได้ง่ายมาก ตั้งค่า SSL Certificate ผ่าน Let’s Encrypt บน Plesk หรือ Nginx ก่อนเสมอ

ระวัง Redirect URI Manipulation

ต้อง Whitelist redirect_uri ที่อนุญาตอย่างเข้มงวด ห้ามใช้ Wildcard เช่น https://de.co.th/* เพราะจะถูกโจมตีแบบ Open Redirect ได้

เก็บ Client Secret อย่างปลอดภัย

เก็บ Client Secret ใน Environment Variables ไม่ใช่ใน Source Code ใช้ไฟล์ .env และอย่า commit ขึ้น Git ครับ

# ไฟล์ .env
OAUTH_CLIENT_ID=your-client-id
OAUTH_CLIENT_SECRET=your-client-secret
OAUTH_REDIRECT_URI=https://de.co.th/callback

Identity Provider ที่นิยมใช้

สรุป: OAuth 2.0 vs OpenID Connect ใช้อะไรเมื่อไหร่?

• ต้องการให้แอปเข้าถึง API ในนามผู้ใช้ → ใช้ OAuth 2.0
• ต้องการล็อกอินและรู้ว่าผู้ใช้คือใคร → ใช้ OpenID Connect
• ต้องการ Single Sign-On → ใช้ OpenID Connect
• Server-to-Server API โดยไม่มีผู้ใช้ → ใช้ OAuth 2.0 Client Credentials
• ทั้ง Login และเข้าถึง API → ใช้ OIDC + OAuth 2.0 ร่วมกัน (ซึ่ง OIDC ทำให้โดย default)

หากคุณกำลังสร้างระบบ Authentication บน Cloud VPS ของ DE การใช้ OpenID Connect ร่วมกับ Self-hosted Identity Provider อย่าง Keycloak หรือ Authentik เป็นทางเลือกที่ดีมากครับ ควบคุมข้อมูลได้เองและไม่ต้องพึ่ง Third-party Service