ถ้าคุณเพิ่งเริ่มต้นกับระบบการยืนยันตัวตน และกำลังสร้างแอปที่เกี่ยวข้องกับการล็อกอิน การชำระเงิน หรือข้อมูลผู้ใช้ คุณน่าจะเคยเจอคำว่า JWT และ OAuth มาก่อน มันอาจฟังดูเหมือนเป็นเรื่องซับซ้อนสำหรับฝั่ง Backend แต่จริง ๆ ไม่ได้จำกัดแค่คนที่รับผิดชอบความปลอดภัยเท่านั้น
ด้วย API การเชื่อมต่อกับบริการภายนอก และเทคโนโลยีใหม่อย่าง AI, MCP และระบบแบบตัวแทน ทั้งสองเทคโนโลยีนี้มีบทบาทตรงต่อความสามารถใช้งาน ความปลอดภัย และการเติบโตของผลิตภัณฑ์คุณ เข้าใจพื้นฐานจะช่วยให้คุณ:
- ออกแบบฟีเจอร์ที่มีความปลอดภัยตั้งแต่แรก
- สื่อสารกับทีมวิศวกรรมได้อย่างเข้าใจ
- ตัดสินใจเชิงผลิตภัณฑ์ด้าน authentication และโฟลว์ของผู้ใช้ได้ดีขึ้น
- หลีกเลี่ยงข้อผิดพลาดด้านความปลอดภัยที่มีต้นทุนสูงซึ่งอาจทำให้ผู้ใช้สูญเสียความเชื่อมั่น
ตัวอย่างเช่น MCP spec ล่าสุด ระบบ authorization ถูกสร้างบนมาตรฐานที่ได้รับการยอมรับ:
ทำไมเรื่องนี้ถึงสำคัญ#
ถึงแม้คุณจะไม่ได้เขียนโค้ดฝั่ง backend:
- นักพัฒนาจะได้เรียนรู้วิธีป้องกัน API, จัดการ session, และเชื่อมต่อกับบริการ third-party ได้
- ผู้จัดการโปรดักต์เข้าใจศัพท์เฉพาะในเรื่องโฟลว์ล็อกอิน การเชื่อมต่อ และ compliance กับทีมและพาร์ทเนอร์
- ผู้ก่อตั้งและทีมระยะแรกหลีกเลี่ยงการสร้างระบบล็อกอินที่เปราะบางหรือเปิดช่องให้โดนโจมตี
JWT กับ OAuth: สองแนวคิดหลัก#
JWT (JSON Web Token) และ OAuth (Open Authorization) มักถูกนำมาใช้ร่วมกัน แต่จริง ๆ แล้วมีหน้าที่ต่างกัน
เปรียบเทียบง่าย ๆ ว่า:
- OAuth คือ วิธีให้กุญแจ กับคนอื่น โดยกำหนดว่าพวกเขาจะเข้าได้แค่ห้องที่อนุญาต
- JWT คือ บัตรประจำตัว ที่เขาพก ตอกย้ำว่าเป็นใครและมีสิทธิ์อะไรบ้าง
ในหัวข้อต่อไป เราจะเปรียบเทียบให้เห็นความแตกต่างชัด ๆ และวิธีการเสริมกันของสองระบบนี้
OAuth 2.0 คืออะไร#
OAuth 2.0 คือ เฟรมเวิร์กการอนุญาต ที่ถูกใช้อย่างแพร่หลาย ช่วยให้แอป (client) เข้าถึงทรัพยากรของผู้ใช้แบบมีขอบเขต โดยไม่ต้องให้แอปเห็นข้อมูลลับของผู้ใช้ (เช่น พาสเวิร์ด)
บทบาทหลักใน OAuth#
- Client: แอปที่ร้องขอการเข้าถึง
- Resource owner: ผู้เป็นเจ้าของทรัพยากร (ปกติคือผู้ใช้)
- Authorization server: เซิร์ฟเวอร์ที่ออก access token เมื่อลงนามอนุญาต
- Resource server: เซิร์ฟเวอร์ที่เก็บข้อมูลและตรวจสอบ token
Grant Type หรือ Flow ที่พบบ่อยใน OAuth#
- Authorization Code Grant: ปลอดภัยที่สุดและแนะนำโดยเฉพาะเมื่อใช้ PKCE เหมาะสำหรับเว็บ browser, SPA และแอปมือถือ
- Implicit Grant: ตอนนี้ไม่แนะนำตาม OAuth 2.1 ด้วยเหตุผลด้านความปลอดภัย
- Resource Owner Password Credentials (ROPC): ส่ง username กับ password แลกเปลี่ยน token โดยตรง; ความปลอดภัยต่ำกว่า
- Client Credentials Grant: ใช้สำหรับ server-to-server หรือ machine-to-machine
- Device Flow: สำหรับอุปกรณ์ที่ไม่มีคีย์บอร์ด (เช่น ทีวีอัจฉริยะ) ให้ผู้ใช้อนุญาตจากอีกอุปกรณ์หนึ่ง
JWT (JSON Web Token) คืออะไร#
JWT เป็นมาตรฐานเปิด (RFC 7519) สำหรับส่งข้อมูลอ้างสิทธิ์ (claim) อย่างปลอดภัยระหว่างสองฝ่ายในรูปแบบกระชับและปลอดภัยต่อ URL
โครงสร้างของ JWT#
JWT มี 3 ส่วน base64url-encoded ที่คั่นด้วยจุด (.)
- Header: ระบุอัลกอริทึม (เช่น HS256, RS256) และชนิด token (JWT)
- Payload: บรรจุ claim ต่าง ๆ เช่น
- iss (issuer)
- sub (subject, เช่น user ID)
- aud (audience)
- exp (วันหมดอายุ)
- claim กำหนดเอง
- Signature – ตรวจสอบว่า token ไม่ถูกแก้ไข
ตัวอย่าง:
ตัวอย่าง JWT#
ด้านล่างเป็นตัวอย่าง JWT ทั่วไป ในแบบเข้ารหัส พร้อมโครงสร้างแบบถอดรหัส เพื่อให้คุณเห็นว่าแต่ละส่วนแทนอะไร
Encoded JWT (Base64URL)
ซึ่งประกอบด้วยสามส่วนที่คั่นด้วยเครื่องหมายจุด: header.payload.signature
โครงสร้างแบบถอดรหัส
payload จะบรรจุ claim ต่าง ๆ
signature บ่งบอกว่า token นี้ไม่ถูกแก้ไข
คุณลักษณะสำคัญ#
- Self-contained: มีข้อมูลจำเป็นครบใน token
- Stateless: ไม่ต้องเก็บ session ฝั่ง server
- Signed: (และเข้ารหัสได้ถ้าต้องการ) เพื่อรับประกันความถูกต้อง
JWT กับ OAuth: ความแตกต่างหลัก#
| แง่มุม | JWT | OAuth 2.0 |
|---|
| คำจำกัดความ | รูปแบบ token | เฟรมเวิร์กการอนุญาต |
| วัตถุประสงค์ | ขนส่งตัวตน/claim อย่างปลอดภัย | กำหนดวิธีมอบ/จัดการสิทธิ์การเข้าถึง |
| ขอบเขต | การแทนข้อมูล | กระบวนการและ flow |
| ใช้งานเดี่ยว? | ได้ ในกรณีบริหาร token ภายใน | ไม่ได้ ต้องมี token format (เช่น JWT) |
| ตัวอย่าง | API ออก JWT ให้ client โดยตรง | แอปขอ access token ผ่าน flow ของ OAuth |
สรุปสั้น ๆ:
- JWT เหมือนภาชนะ: เฉกเช่นพาสปอร์ตที่ถือรายละเอียดตัวตน
- OAuth เป็นระบบ: เหมือน ตม. ตัดสินว่าใครได้พาสปอร์ตและเข้าถึงอะไร
ใช้ JWT เดี่ยว ๆ เมื่อใด#
ใช้ JWT เพียงอย่างเดียวเมื่อ:
- ยืนยันตัวในระบบเดียว แอปออกและตรวจสอบ token เองโดยไม่ต้องใช้ identity provider ภายนอก
- จัดการ session แบบ stateless ตรวจสอบตัวตนผู้ใช้โดยไม่ฝากข้อมูล session ฝั่ง server
- ยืนยัน API แบบง่าย ๆ เหมาะกับ internal APIs ที่ตรวจสอบสิทธิ์เบื้องต้นโดยไม่ซับซ้อน
- ตรวจสอบแบบเน้นประสิทธิภาพ resource server ตรวจ token ได้ local โดยไม่ติดต่อ auth server
ตัวอย่าง:
SPA และ backend API ที่คุณดูแลเอง API ออก JWT มี claim sub (user ID), role, และ exp (วันหมดอายุ)
ใช้ OAuth เดี่ยว ๆ เมื่อใด#
ใช้ OAuth โดยไม่พ่วง JWT เมื่อ:
- ไม่จำเป็นต้องมี token แบบ self-contained และการใช้ opaque token ที่ต้อง lookup ก็เพียงพอ
- ต้องการให้ resource server ตรวจสอบกับ authorization server ทุกครั้งก่อนให้เข้าถึง
- ระบบ legacy หรือภายใต้ข้อกำหนดที่ไม่เหมาะสมกับ JWT
- ต้องการ delegated authorization เพื่อมอบสิทธิ์ใช้งานให้แอป third-party อย่างปลอดภัย
ตัวอย่าง:
API ที่ออก opaque access token และตรวจสอบแต่ละคำขอโดยเช็คกับ authorization server
ใช้ JWT และ OAuth ร่วมกันเมื่อใด#
ใช้ทั้งสองอย่างร่วมกันเมื่อ:
- คุณมีหลาย service หรือ API และต้องการ OAuth เพื่อความปลอดภัยของ flow พร้อม JWT ที่ตรวจสอบข้าม service ได้
- คุณให้ผู้ใช้ล็อกอินด้วย third-party (เช่น “Sign in with Google”) OAuth ดูแลการยินยอม JWT ถือข้อมูล access หรือ ID token
- รันระบบ microservices ที่แต่ละ service ตรวจ JWT ได้เอง
- ต้องการนำข้อดีของ OAuth (delegation) และ JWT (stateless verification) มารวมกันเพื่อความขยายตัว
ตัวอย่าง:
แอปของคุณให้ผู้ใช้ล็อกอินด้วย Google OAuth จัดการ flow การอนุญาต Google ออก JWT access token API ของคุณตรวจสอบ token นั้นเองก่อนคืนข้อมูลให้ผู้ใช้
วิธีการทำงานร่วมกันของ JWT และ OAuth#
ระบบ authentication/authorization ยุคใหม่ทำงานแบบนี้:
- OAuth จัดการ flow การมอบสิทธิ์
- Authorization Server ออก access token (มักจะเป็น JWT)
- JWT ถูกส่งไปกับ request API เพื่อยืนยันตัวตนและสิทธิ์
โทเค็นพิเศษใน OAuth#
- ID token: ใช้ใน OpenID Connect เพื่อพิสูจน์ตัวตนผู้ใช้ เป็น JWT เสมอ
- Access token: อาจเป็น JWT หรือ opaque token ก็ได้
แนวทางปฏิบัติที่ดีที่สุดของ JWT และ OAuth#
- ใช้ HTTPS ป้องกัน token ขณะส่งผ่านเครือข่าย
- ตั้งอายุ JWT ให้สั้น ใช้ refresh token สำหรับ session ที่นานขึ้น
- ตรวจสอบ signature ก่อนเชื่อ claim ใด ๆ
- เช็ค aud claim ให้แน่ใจว่า token ใช้งานได้เฉพาะกับแอปคุณ
- อย่าเก็บ token ใน localStorage ถ้า XSS เป็นความเสี่ยง ควรใช้ secure cookie
สรุปท้ายบทความ#
- OAuth 2.0 กำหนด วิธี ได้มาซึ่ง token และการใช้งาน
- JWT กำหนด รูปร่าง และรายละเอียดที่ token บรรจุ
- ทั้งคู่ เสริมกัน ไม่ได้ใช้แทนกันได้
API สมัยใหม่ส่วนใหญ่ใช้ OAuth สำหรับกำหนด flow และ JWT สำหรับแจกจ่ายตัวตน รู้อย่างถ่องแท้ถึงทั้งสองอย่าง จะช่วยให้คุณออกแบบระบบยืนยันตัวตนที่ปลอดภัยและขยายตัวได้
