JWT กับ OAuth: ความแตกต่างหลัก วิธีการทำงานร่วมกัน และแนวทางการใช้งานที่ดีที่สุด

ถ้าคุณเพิ่งเริ่มต้นกับระบบการยืนยันตัวตน และกำลังสร้างแอปที่เกี่ยวข้องกับการล็อกอิน การชำระเงิน หรือข้อมูลผู้ใช้ คุณน่าจะเคยเจอคำว่า JWT และ OAuth มาก่อน มันอาจฟังดูเหมือนเป็นเรื่องซับซ้อนสำหรับฝั่ง Backend แต่จริง ๆ ไม่ได้จำกัดแค่คนที่รับผิดชอบความปลอดภัยเท่านั้น

ด้วย API การเชื่อมต่อกับบริการภายนอก และเทคโนโลยีใหม่อย่าง AI, MCP และระบบแบบตัวแทน ทั้งสองเทคโนโลยีนี้มีบทบาทตรงต่อความสามารถใช้งาน ความปลอดภัย และการเติบโตของผลิตภัณฑ์คุณ เข้าใจพื้นฐานจะช่วยให้คุณ:

• ออกแบบฟีเจอร์ที่มีความปลอดภัยตั้งแต่แรก
• สื่อสารกับทีมวิศวกรรมได้อย่างเข้าใจ
• ตัดสินใจเชิงผลิตภัณฑ์ด้าน authentication และโฟลว์ของผู้ใช้ได้ดีขึ้น
• หลีกเลี่ยงข้อผิดพลาดด้านความปลอดภัยที่มีต้นทุนสูงซึ่งอาจทำให้ผู้ใช้สูญเสียความเชื่อมั่น

ตัวอย่างเช่น MCP spec ล่าสุด ระบบ authorization ถูกสร้างบนมาตรฐานที่ได้รับการยอมรับ:

• OAuth 2.1 IETF Draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

ทำไมเรื่องนี้ถึงสำคัญ#

ถึงแม้คุณจะไม่ได้เขียนโค้ดฝั่ง 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 ที่คั่นด้วยจุด (.)

1. Header: ระบุอัลกอริทึม (เช่น HS256, RS256) และชนิด token (JWT)
2. Payload: บรรจุ claim ต่าง ๆ เช่น
   • iss (issuer)
   • sub (subject, เช่น user ID)
   • aud (audience)
   • exp (วันหมดอายุ)
   • claim กำหนดเอง
3. Signature – ตรวจสอบว่า token ไม่ถูกแก้ไข

ตัวอย่าง:

ตัวอย่าง JWT#

ด้านล่างเป็นตัวอย่าง JWT ทั่วไป ในแบบเข้ารหัส พร้อมโครงสร้างแบบถอดรหัส เพื่อให้คุณเห็นว่าแต่ละส่วนแทนอะไร

Encoded JWT (Base64URL)

ซึ่งประกอบด้วยสามส่วนที่คั่นด้วยเครื่องหมายจุด: header.payload.signature

โครงสร้างแบบถอดรหัส

• Header

• Payload

payload จะบรรจุ claim ต่าง ๆ

• Signature

signature บ่งบอกว่า token นี้ไม่ถูกแก้ไข

คุณลักษณะสำคัญ#

• Self-contained: มีข้อมูลจำเป็นครบใน token
• Stateless: ไม่ต้องเก็บ session ฝั่ง server
• Signed: (และเข้ารหัสได้ถ้าต้องการ) เพื่อรับประกันความถูกต้อง

JWT กับ 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 ยุคใหม่ทำงานแบบนี้:

1. OAuth จัดการ flow การมอบสิทธิ์
2. Authorization Server ออก access token (มักจะเป็น JWT)
3. JWT ถูกส่งไปกับ request API เพื่อยืนยันตัวตนและสิทธิ์

โทเค็นพิเศษใน OAuth#

• ID token: ใช้ใน OpenID Connect เพื่อพิสูจน์ตัวตนผู้ใช้ เป็น JWT เสมอ
• Access token: อาจเป็น JWT หรือ opaque token ก็ได้

แนวทางปฏิบัติที่ดีที่สุดของ JWT และ OAuth#

• ใช้ HTTPS ป้องกัน token ขณะส่งผ่านเครือข่าย
• ตั้งอายุ JWT ให้สั้น ใช้ refresh token สำหรับ session ที่นานขึ้น
  • https://auth.wiki/offline-access
• ตรวจสอบ signature ก่อนเชื่อ claim ใด ๆ
• เช็ค aud claim ให้แน่ใจว่า token ใช้งานได้เฉพาะกับแอปคุณ
• อย่าเก็บ token ใน localStorage ถ้า XSS เป็นความเสี่ยง ควรใช้ secure cookie

สรุปท้ายบทความ#

• OAuth 2.0 กำหนด วิธี ได้มาซึ่ง token และการใช้งาน
• JWT กำหนด รูปร่าง และรายละเอียดที่ token บรรจุ
• ทั้งคู่ เสริมกัน ไม่ได้ใช้แทนกันได้

API สมัยใหม่ส่วนใหญ่ใช้ OAuth สำหรับกำหนด flow และ JWT สำหรับแจกจ่ายตัวตน รู้อย่างถ่องแท้ถึงทั้งสองอย่าง จะช่วยให้คุณออกแบบระบบยืนยันตัวตนที่ปลอดภัยและขยายตัวได้