OAuth 2.0 และ JWT Authentication คู่มือครบถ้วน

ในโลกของการพัฒนาเว็บและแอปพลิเคชันยุคใหม่ การรักษาความปลอดภัยของข้อมูลผู้ใช้และการควบคุมการเข้าถึงทรัพยากรต่างๆ เป็นหัวใจสำคัญที่ไม่สามารถมองข้ามได้เลยครับ ไม่ว่าจะเป็นการเข้าสู่ระบบด้วยบัญชีโซเชียลมีเดีย, การเชื่อมต่อแอปพลิเคชันหนึ่งเข้ากับอีกแอปพลิเคชันหนึ่ง, หรือแม้แต่การเรียกใช้ API เพื่อดึงข้อมูลเฉพาะสำหรับผู้ใช้งานแต่ละราย กลไกเบื้องหลังเหล่านี้ล้วนต้องอาศัยระบบการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) ที่แข็งแกร่งและน่าเชื่อถือ และเมื่อพูดถึงสองสิ่งนี้ ชื่อของ OAuth 2.0 และ JWT (JSON Web Token) ก็มักจะถูกกล่าวถึงควบคู่กันไปเสมอครับ

บทความนี้จะพาคุณเจาะลึกถึงแก่นแท้ของ OAuth 2.0 และ JWT Authentication ตั้งแต่พื้นฐานไปจนถึงการนำไปประยุกต์ใช้จริง รวมถึงแนวทางปฏิบัติที่ดีที่สุด เพื่อให้คุณเข้าใจถึงบทบาทที่แตกต่างแต่ส่งเสริมกันของทั้งสองเทคโนโลยีนี้ และสามารถนำไปออกแบบระบบความปลอดภัยให้กับแอปพลิเคชันของคุณได้อย่างมีประสิทธิภาพสูงสุดครับ พร้อมแล้ว เรามาเริ่มกันเลย!

สารบัญ

• ทำไมต้องเข้าใจ OAuth 2.0 และ JWT Authentication?
• เจาะลึก OAuth 2.0: การอนุญาตที่ยืดหยุ่นและปลอดภัย
  • OAuth 2.0 คืออะไร?
  • บทบาทของผู้ที่เกี่ยวข้องใน OAuth 2.0
  • ประเภทของ Grant Type (Flow การทำงาน)
  • ส่วนประกอบสำคัญของ OAuth 2.0
  • ตัวอย่างการใช้งาน OAuth 2.0 ในชีวิตจริง
• เจาะลึก JWT (JSON Web Token): Token ยืนยันตัวตนแบบ Stateless
  • JWT คืออะไร?
  • โครงสร้างของ JWT
  • ประเภทของ JWT Claims
  • Flow การทำงานของ JWT Authentication
  • ข้อดีและข้อเสียของ JWT
  • ตัวอย่าง Code Snippet: การสร้างและตรวจสอบ JWT
• การนำ OAuth 2.0 และ JWT มาใช้งานร่วมกัน: พลังที่สมบูรณ์แบบ
  • บทบาทที่แตกต่างแต่ส่งเสริมกัน
  • Flow การทำงานที่ผสมผสาน
  • ประโยชน์ของการใช้ร่วมกัน
• ความปลอดภัยและการใช้งานที่ดีที่สุด (Best Practices)
  • สำหรับ OAuth 2.0
  • สำหรับ JWT
  • สำหรับทั้งสองเทคโนโลยี
• ตารางเปรียบเทียบ: OAuth 2.0 vs. JWT
• คำถามที่พบบ่อย (FAQ)
• สรุปและก้าวต่อไป

ทำไมต้องเข้าใจ OAuth 2.0 และ JWT Authentication?

ในปัจจุบันนี้ การที่เราใช้บริการออนไลน์ต่างๆ เช่น Facebook, Google, Twitter หรือแม้แต่แอปพลิเคชันธนาคาร เรามักจะพบกับการเชื่อมต่อข้อมูลระหว่างแอปพลิเคชันหนึ่งไปยังอีกแอปพลิเคชันหนึ่ง ยกตัวอย่างเช่น คุณต้องการให้แอปพลิเคชันรูปภาพเข้าถึงรูปภาพของคุณที่เก็บไว้ใน Google Photos โดยที่คุณไม่จำเป็นต้องให้รหัสผ่านบัญชี Google แก่แอปพลิเคชันรูปภาพนั้น หรือเมื่อคุณเข้าสู่ระบบเว็บไซต์อีคอมเมิร์ซด้วยบัญชี Facebook แทนการสมัครสมาชิกใหม่ สิ่งเหล่านี้ล้วนเป็นผลมาจากการทำงานของระบบ Authorization และ Authentication ที่ซับซ้อนภายใต้แนวคิดของ OAuth 2.0 และ JWT ครับ

ความท้าทายหลักในโลกดิจิทัลคือการสร้างสมดุลระหว่างความสะดวกสบายในการใช้งานและความปลอดภัยของข้อมูลผู้ใช้ การให้รหัสผ่านแก่แอปพลิเคชันภายนอกนั้นเป็นสิ่งที่อันตรายอย่างยิ่ง เพราะแอปพลิเคชันนั้นจะสามารถเข้าถึงข้อมูลทั้งหมดของคุณได้ หากระบบของแอปพลิเคชันนั้นถูกโจมตี ข้อมูลส่วนตัวของคุณก็อาจรั่วไหลได้ทันทีครับ นี่คือจุดที่ OAuth 2.0 เข้ามาแก้ปัญหา โดยการอนุญาตให้แอปพลิเคชันเข้าถึงข้อมูลบางส่วนในนามของผู้ใช้งาน โดยไม่จำเป็นต้องรู้รหัสผ่าน ส่วน JWT ก็เข้ามาเสริมประสิทธิภาพในการยืนยันตัวตนของผู้ใช้ที่ได้รับอนุญาตแล้ว เพื่อให้การสื่อสารระหว่าง Client และ Server เป็นไปอย่างรวดเร็วและปลอดภัยครับ

การทำความเข้าใจสองเทคโนโลยีนี้จึงเป็นสิ่งสำคัญสำหรับนักพัฒนาทุกคน เพื่อให้สามารถออกแบบและสร้างระบบที่มีความปลอดภัยสูง ตอบโจทย์การใช้งานที่หลากหลาย และรองรับการขยายตัวในอนาคตได้อย่างมั่นคงครับ

เจาะลึก OAuth 2.0: การอนุญาตที่ยืดหยุ่นและปลอดภัย

OAuth 2.0 คืออะไร?

OAuth 2.0 (Open Authorization 2.0) คือเฟรมเวิร์กมาตรฐานสำหรับ Authorization (การอนุญาต) ไม่ใช่ Authentication (การยืนยันตัวตน) นะครับ! จุดประสงค์หลักของ OAuth 2.0 คือการอนุญาตให้แอปพลิเคชันหนึ่ง (Client) สามารถเข้าถึงข้อมูลหรือฟังก์ชันการทำงานของอีกแอปพลิเคชันหนึ่ง (Resource Server) ในนามของผู้ใช้งาน (Resource Owner) โดยที่ Client ไม่จำเป็นต้องรู้รหัสผ่านของผู้ใช้งานครับ

ลองนึกภาพว่าคุณต้องการให้เพื่อนไปหยิบหนังสือจากห้องสมุดส่วนตัวของคุณ คุณคงไม่อยากให้กุญแจห้องสมุดกับเพื่อนไปเลยใช่ไหมครับ? แต่คุณอาจจะเขียนโน้ตเล็กๆ บอกบรรณารักษ์ว่า “อนุญาตให้เพื่อนคนนี้หยิบหนังสือ ‘OAuth 2.0 For Dummies’ ได้” แล้วให้เพื่อนนำโน้ตนั้นไปยื่น บรรณารักษ์ก็จะตรวจสอบโน้ตและอนุญาตให้เพื่อนหยิบหนังสือได้ นี่แหละครับคือแนวคิดพื้นฐานของ OAuth 2.0

ในบริบทของเว็บและแอปพลิเคชัน ผู้ใช้งานจะ “อนุญาต” ให้แอปพลิเคชันภายนอกเข้าถึงข้อมูลบางอย่างของตนที่อยู่บนบริการอื่น (เช่น Google Photos, Facebook Profile) โดยกระบวนการอนุญาตนี้จะอยู่ภายใต้การควบคุมของผู้ใช้งานและบริการเจ้าของข้อมูลครับ และผลลัพธ์ของการอนุญาตนี้คือการได้รับ Access Token ซึ่งเป็นกุญแจชั่วคราวที่ Client จะใช้ในการเข้าถึงข้อมูลตามขอบเขตที่กำหนดไว้ครับ

บทบาทของผู้ที่เกี่ยวข้องใน OAuth 2.0

เพื่อให้เห็นภาพชัดเจนยิ่งขึ้น เรามาทำความรู้จักกับบทบาทหลักๆ ในกระบวนการของ OAuth 2.0 กันครับ:

• Resource Owner (เจ้าของทรัพยากร): คือผู้ใช้งานตัวจริง เช่น คุณเอง ที่เป็นเจ้าของข้อมูล (รูปภาพ, รายชื่อเพื่อน, ข้อมูลโปรไฟล์) และเป็นผู้ให้การอนุญาต (Grant permission) ให้แอปพลิเคชันภายนอกเข้าถึงข้อมูลเหล่านั้น
• Client (ไคลเอนต์): คือแอปพลิเคชันที่ต้องการเข้าถึงทรัพยากรของ Resource Owner เช่น แอปพลิเคชันแต่งรูป, เว็บไซต์อีคอมเมิร์ซที่ต้องการใช้ข้อมูลโปรไฟล์ของคุณ
• Authorization Server (เซิร์ฟเวอร์ผู้อนุญาต): เป็นเซิร์ฟเวอร์ที่ทำหน้าที่ยืนยันตัวตนของ Resource Owner และออก Access Token ให้กับ Client เมื่อได้รับการอนุญาตแล้วครับ ตัวอย่างเช่น Google’s Authorization Server หรือ Facebook’s Authorization Server
• Resource Server (เซิร์ฟเวอร์ทรัพยากร): เป็นเซิร์ฟเวอร์ที่เก็บข้อมูลหรือทรัพยากรที่ Client ต้องการเข้าถึง โดยจะตรวจสอบ Access Token ที่ Client ส่งมา เพื่อยืนยันว่า Client มีสิทธิ์เข้าถึงข้อมูลนั้นๆ หรือไม่ ตัวอย่างเช่น Google Photos API, Facebook Graph API

ทั้ง Authorization Server และ Resource Server มักจะเป็นส่วนหนึ่งของบริการเดียวกัน (เช่น ทั้งคู่เป็นของ Google) แต่มีบทบาทที่แตกต่างกันชัดเจนครับ

ประเภทของ Grant Type (Flow การทำงาน)

OAuth 2.0 กำหนด “Grant Types” หรือ “Flows” หลายรูปแบบ เพื่อรองรับลักษณะการใช้งานที่แตกต่างกันของ Client แต่ละประเภทครับ

Authorization Code Grant (แนะนำที่สุด)

เป็น Flow ที่ปลอดภัยที่สุดและเป็นที่นิยมใช้สำหรับแอปพลิเคชันเว็บฝั่งเซิร์ฟเวอร์ (Server-side Web Applications) หรือแอปพลิเคชันมือถือครับ

1. Request Authorization: Client (เว็บแอปฯ ของคุณ) ส่งผู้ใช้ไปยัง Authorization Server พร้อมระบุ client_id, redirect_uri, และ scope ที่ต้องการ
2. User Authorization: Authorization Server ยืนยันตัวตนผู้ใช้ (ถ้ายังไม่ได้เข้าสู่ระบบ) และแสดงหน้าจอขออนุญาต ผู้ใช้กด “อนุญาต”
3. Authorization Code: Authorization Server ส่ง authorization_code กลับไปยัง redirect_uri ของ Client
4. Request Access Token: Client นำ authorization_code ที่ได้รับ พร้อม client_id และ client_secret (ซึ่งควรเก็บเป็นความลับบนเซิร์ฟเวอร์) ไปแลก Access Token กับ Authorization Server (เป็นการสื่อสารแบบ Server-to-Server)
5. Issue Access Token: Authorization Server ตรวจสอบข้อมูลและออก access_token (และอาจมี refresh_token) ให้กับ Client
6. Access Resource: Client ใช้ access_token เพื่อเข้าถึง Resource Server

ข้อดี: มีความปลอดภัยสูง เพราะ access_token ไม่ได้ส่งผ่าน Browser โดยตรง และ client_secret ถูกเก็บไว้อย่างปลอดภัยบน Server
ข้อควรระวัง: ต้องจัดการ redirect_uri อย่างระมัดระวัง เพื่อป้องกันการโจมตีแบบ Code Injection

Client Credentials Grant

Flow นี้ใช้เมื่อ Client ต้องการเข้าถึงทรัพยากรของตนเอง ไม่ใช่ในนามของผู้ใช้งาน หรือใช้สำหรับการสื่อสารระหว่างเซิร์ฟเวอร์กับเซิร์ฟเวอร์ (Server-to-Server) ครับ

1. Client ส่ง client_id และ client_secret ไปยัง Authorization Server
2. Authorization Server ตรวจสอบข้อมูลและออก access_token ให้กับ Client
3. Client ใช้ access_token เพื่อเข้าถึง Resource Server

ข้อดี: ง่าย เหมาะสำหรับ Machine-to-Machine communication
ข้อควรระวัง: ไม่มีผู้ใช้งานจริงเข้ามาเกี่ยวข้อง ดังนั้นจึงไม่มีการอนุญาตจาก Resource Owner

Resource Owner Password Credentials Grant (ไม่แนะนำ)

ใน Flow นี้ Client จะขอรหัสผ่านของผู้ใช้งานโดยตรง แล้วนำรหัสผ่านนั้นไปแลก access_token กับ Authorization Server ครับ

ข้อควรระวังอย่างยิ่ง: ไม่แนะนำให้ใช้ในกรณีส่วนใหญ่ เพราะ Client จะต้องเก็บรหัสผ่านของผู้ใช้ ซึ่งขัดกับหลักการพื้นฐานของ OAuth 2.0 ที่ไม่ต้องการให้ Client รู้รหัสผ่านของผู้ใช้ ใช้เฉพาะในกรณีที่ Client เป็นส่วนหนึ่งของบริการที่เชื่อถือได้มากๆ (เช่น แอปพลิเคชันของบริษัทเดียวกัน) และ Authorization Server ก็เป็นของบริษัทเดียวกันครับ

Implicit Grant (ไม่แนะนำแล้ว)

เคยใช้สำหรับแอปพลิเคชันฝั่ง Client (เช่น Single Page Application) ที่ไม่สามารถเก็บ client_secret ได้อย่างปลอดภัย

1. Client ส่งผู้ใช้ไปยัง Authorization Server พร้อม client_id และ redirect_uri
2. ผู้ใช้ให้การอนุญาต
3. Authorization Server ส่ง access_token กลับไปยัง redirect_uri โดยตรงใน URL fragment

ข้อเสีย: มีความเสี่ยงด้านความปลอดภัยสูง เนื่องจาก access_token ถูกส่งผ่าน Browser และอาจถูกดักจับได้ง่าย ปัจจุบันแนะนำให้ใช้ Authorization Code Grant with PKCE แทนครับ

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ PKCE (Proof Key for Code Exchange) ซึ่งเป็นส่วนเสริมที่สำคัญในการเพิ่มความปลอดภัยให้กับ Authorization Code Grant โดยเฉพาะสำหรับ Client สาธารณะ (Public Client) เช่น แอปพลิเคชันมือถือ หรือ Single Page Application คุณสามารถ อ่านเพิ่มเติมได้ที่นี่ ครับ

ส่วนประกอบสำคัญของ OAuth 2.0

ในการทำความเข้าใจ OAuth 2.0 อย่างถ่องแท้ เราจำเป็นต้องรู้จักคำศัพท์และส่วนประกอบหลักๆ เหล่านี้ครับ:

• Client ID (รหัสไคลเอนต์): เป็นตัวระบุที่ไม่ซ้ำกันสำหรับ Client แอปพลิเคชันของคุณที่ลงทะเบียนไว้กับ Authorization Server
• Client Secret (ความลับของไคลเอนต์): เป็นรหัสลับที่ใช้คู่กับ Client ID เพื่อยืนยันตัวตนของ Client กับ Authorization Server ควรเก็บเป็นความลับสูงสุดและไม่เปิดเผยสู่สาธารณะ (ใช้เฉพาะกับ Confidential Client เช่น Server-side app)
• Authorization Code (รหัสการอนุญาต): เป็นรหัสชั่วคราวที่ Authorization Server ออกให้หลังจากผู้ใช้งานให้การอนุญาต Client ใช้รหัสนี้เพื่อแลกเป็น Access Token
• Access Token (โทเค็นการเข้าถึง): เป็นกุญแจชั่วคราวที่ Client ใช้เพื่อเข้าถึงทรัพยากรบน Resource Server ในนามของผู้ใช้งาน มีอายุจำกัดและมักจะเป็น JWT
• Refresh Token (โทเค็นรีเฟรช): เป็นโทเค็นที่มีอายุยืนยาวกว่า Access Token ใช้เพื่อขอ Access Token ใหม่โดยไม่ต้องให้ผู้ใช้เข้าสู่ระบบและให้การอนุญาตซ้ำอีกครั้ง ควรเก็บไว้อย่างปลอดภัยบนเซิร์ฟเวอร์
• Scope (ขอบเขต): คือสิทธิ์ที่ Client ต้องการเข้าถึง เป็นการระบุอย่างชัดเจนว่า Client ต้องการเข้าถึงข้อมูลประเภทใดบ้าง เช่น read:profile, write:photos ผู้ใช้งานจะเป็นผู้พิจารณาว่าจะอนุญาตสิทธิ์เหล่านี้หรือไม่
• Redirect URI (URI สำหรับเปลี่ยนเส้นทาง): เป็น URL ที่ Authorization Server จะส่งผู้ใช้งานกลับไปหลังจากกระบวนการอนุญาตเสร็จสิ้น ต้องลงทะเบียน URL นี้ไว้ล่วงหน้ากับ Authorization Server เพื่อความปลอดภัย

ตัวอย่างการใช้งาน OAuth 2.0 ในชีวิตจริง

ตัวอย่างที่พบบ่อยที่สุดคือ “Login with Google”, “Login with Facebook”, “Login with Twitter” ครับ เมื่อคุณคลิกปุ่มเหล่านี้บนเว็บไซต์หรือแอปพลิเคชัน:

1. เว็บไซต์/แอปพลิเคชัน (Client) จะส่งคุณไปยังหน้า Login ของ Google/Facebook (Authorization Server)
2. คุณเข้าสู่ระบบ Google/Facebook (ถ้ายังไม่ได้เข้า) และจะเห็นหน้าจอขออนุญาตว่า “เว็บไซต์นี้ต้องการเข้าถึงข้อมูลโปรไฟล์ของคุณ, รายชื่อเพื่อนของคุณ, ฯลฯ คุณอนุญาตหรือไม่?”
3. หากคุณ “อนุญาต” Google/Facebook จะส่งคุณกลับมายังเว็บไซต์/แอปพลิเคชันนั้น พร้อมกับ authorization_code หรือ access_token (ขึ้นอยู่กับ Grant Type)
4. เว็บไซต์/แอปพลิเคชันของคุณจะใช้ access_token นั้นเพื่อดึงข้อมูลโปรไฟล์ของคุณจาก Google/Facebook และสร้างบัญชีผู้ใช้หรือเข้าสู่ระบบให้คุณโดยอัตโนมัติ

อีกตัวอย่างคือการให้แอปพลิเคชันอื่นเข้าถึงข้อมูลในบัญชีของคุณ เช่น การเชื่อมต่อแอปพลิเคชันจัดการงาน (Task Management App) เข้ากับ Google Calendar เพื่อให้แอปนั้นสามารถอ่านและเขียนกิจกรรมในปฏิทินของคุณได้ครับ

เจาะลึก JWT (JSON Web Token): Token ยืนยันตัวตนแบบ Stateless

JWT คืออะไร?

JWT (JSON Web Token) คือมาตรฐานเปิด (RFC 7519) สำหรับการสร้างโทเค็นที่ปลอดภัยสำหรับการส่งข้อมูลระหว่างสองฝ่าย โดยข้อมูลจะถูกเข้ารหัสและลงชื่อกำกับ ทำให้สามารถตรวจสอบความถูกต้องและความสมบูรณ์ของข้อมูลได้ครับ JWT ถูกออกแบบมาให้ Compact (กระชับ), URL-safe (ปลอดภัยสำหรับ URL) และ Self-contained (มีข้อมูลในตัวเอง)

ความหมายของ “Self-contained” คือ JWT จะบรรจุข้อมูลที่จำเป็นเกี่ยวกับผู้ใช้งานและสิทธิ์การเข้าถึงไว้ภายในตัวมันเอง เมื่อ Resource Server ได้รับ JWT ก็ไม่จำเป็นต้องสอบถามฐานข้อมูลหรือเซสชันเพิ่มเติมเพื่อตรวจสอบข้อมูลของผู้ใช้ ทำให้ระบบมีความรวดเร็วและ Scalable มากขึ้น โดยเฉพาะในสถาปัตยกรรมแบบ Microservices หรือ Stateless API ครับ

JWT มักถูกนำมาใช้เป็น Access Token ใน OAuth 2.0 หรือใช้สำหรับการยืนยันตัวตน (Authentication) ใน API ที่เป็นแบบ Stateless ครับ

โครงสร้างของ JWT

JWT ประกอบด้วยสามส่วนหลักๆ ที่คั่นด้วยจุด (.) และเข้ารหัสด้วย Base64Url-encoded:

Header.Payload.Signature

Header (ส่วนหัว)

ส่วนนี้เป็น JSON object ที่ระบุประเภทของโทเค็น (typ) ซึ่งมักจะเป็น “JWT” และอัลกอริทึมที่ใช้ในการเข้ารหัสลายเซ็น (alg) เช่น HS256 (HMAC SHA256) หรือ RS256 (RSA SHA256) ครับ

ตัวอย่าง Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

เมื่อเข้ารหัส Base64Url จะได้เป็นสตริงที่คล้ายกับ eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload (ส่วนข้อมูล)

ส่วนนี้เป็น JSON object ที่บรรจุ “Claims” ซึ่งเป็นข้อความที่บ่งบอกถึงคุณสมบัติของเอนทิตี (โดยทั่วไปคือผู้ใช้งาน) และข้อมูลเพิ่มเติมอื่นๆ ครับ Claims มีสามประเภทหลักๆ:

1. Registered Claims: Claims ที่ถูกกำหนดไว้ในมาตรฐาน JWT เพื่อวัตถุประสงค์เฉพาะ ไม่จำเป็นต้องใช้ทั้งหมด แต่แนะนำให้ใช้เพื่อความสามารถในการทำงานร่วมกัน (interoperability) เช่น:
   • iss (issuer): ผู้ออกโทเค็น
   • sub (subject): หัวข้อของโทเค็น (มักเป็น ID ผู้ใช้)
   • aud (audience): ผู้รับโทเค็น
   • exp (expiration time): เวลาหมดอายุของโทเค็น (เป็น Unix timestamp)
   • iat (issued at): เวลาที่ออกโทเค็น
2. Public Claims: Claims ที่กำหนดขึ้นเองได้ แต่ควรระบุใน IANA JSON Web Token Registry หรือ URL ที่มี Collision-Resistant ครับ
3. Private Claims: Claims ที่กำหนดขึ้นเองเพื่อใช้ภายในแอปพลิเคชันเท่านั้น ไม่จำเป็นต้องเป็นมาตรฐาน แต่ควรระวังชื่อซ้ำกับ Registered Claims

ตัวอย่าง Payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iss": "siamlancard.com",
  "exp": 1678886400, // ตัวอย่าง: March 15, 2023 12:00:00 AM GMT+7
  "iat": 1678800000  // ตัวอย่าง: March 14, 2023 12:00:00 AM GMT+7
}

เมื่อเข้ารหัส Base64Url จะได้เป็นสตริงที่คล้ายกับ eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlzcyI6InNpYW1sYW5jYXJkLmNvbSIsImV4cCI6MTY3ODg4NjQwMCwiaWF0IjoxNjc4ODAwMDAwfQ

Signature (ลายเซ็น)

ส่วนนี้ใช้ในการยืนยันว่าโทเค็นนั้นไม่ถูกแก้ไขระหว่างทาง และมาจากผู้ออกที่ถูกต้องครับ การสร้าง Signature ทำได้โดยการนำ Header ที่เข้ารหัสแล้ว, Payload ที่เข้ารหัสแล้ว, และ Secret Key (หรือ Private Key สำหรับ asymmetric algorithms) มารวมกัน แล้วทำการแฮชด้วยอัลกอริทึมที่ระบุใน Header ครับ

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

ผลลัพธ์ที่ได้จะเป็นสตริง Base64Url-encoded ที่เป็นลายเซ็นครับ

ตัวอย่าง JWT ที่สมบูรณ์:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlzcyI6InNpYW1sYW5jYXJkLmNvbSIsImV4cCI6MTY3ODg4NjQwMCwiaWF0IjoxNjc4ODAwMDAwfQ.signature_string_here

ประเภทของ JWT Claims

เราได้กล่าวถึงไปบ้างแล้วในส่วนของ Payload แต่ขอขยายความเพิ่มเติมเพื่อให้เข้าใจถึงความสำคัญของ Claims แต่ละประเภทครับ

• Registered Claims: คือ Claims ที่กำหนดไว้ใน IANA JSON Web Token Registry ซึ่งเป็นมาตรฐานที่ถูกยอมรับร่วมกันเพื่อวัตถุประสงค์เฉพาะ เช่น iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), jti (JWT ID) การใช้ Registered Claims ช่วยให้ JWT สามารถทำงานร่วมกันได้กับหลายแพลตฟอร์มและไลบรารี
• Public Claims: คือ Claims ที่กำหนดขึ้นโดยผู้ใช้งานทั่วไป แต่เพื่อให้มั่นใจว่าชื่อ Claims ไม่ซ้ำกัน (collision-resistant) ควรจะมีการลงทะเบียนใน IANA JSON Web Token Registry หรือกำหนดโดยใช้ URI ที่มี Collision-Resistant ครับ
• Private Claims: คือ Claims ที่ตกลงกันเองระหว่างผู้ส่งและผู้รับ JWT โดยไม่ได้ถูกกำหนดไว้ในมาตรฐานหรือลงทะเบียนไว้ที่ใด เหมาะสำหรับข้อมูลเฉพาะของแอปพลิเคชัน เช่น user_role, department_id เป็นต้น การใช้ Private Claims ต้องแน่ใจว่าทั้งสองฝ่ายเข้าใจความหมายของ Claims เหล่านี้ตรงกันครับ

Flow การทำงานของ JWT Authentication

JWT มักถูกใช้ในกระบวนการยืนยันตัวตนแบบ Stateless ซึ่งมีขั้นตอนดังนี้ครับ

1. User Login: ผู้ใช้ส่งชื่อผู้ใช้และรหัสผ่านไปยัง Authentication Server (หรือ API Endpoint)
2. Authenticate and Issue Token: Authentication Server ตรวจสอบข้อมูลประจำตัวของผู้ใช้ หากถูกต้อง จะสร้าง JWT ที่มีข้อมูลผู้ใช้และสิทธิ์ต่างๆ แล้วลงชื่อ (sign) ด้วย Secret Key จากนั้นส่ง JWT นั้นกลับไปยัง Client
3. Store Token: Client (เช่น Browser หรือ Mobile App) จัดเก็บ JWT ไว้ โดยทั่วไปจะเก็บไว้ใน Local Storage, Session Storage, หรือ Cookie (สำหรับเว็บ)
4. Access Protected Resources: เมื่อ Client ต้องการเข้าถึงทรัพยากรที่ได้รับการป้องกันบน Resource Server Client จะแนบ JWT ไปกับทุกๆ คำขอ โดยมักจะส่งไปใน Header Authorization ในรูปแบบ Bearer <token>
5. Verify Token: Resource Server (หรือ API Gateway) ได้รับคำขอพร้อม JWT จะตรวจสอบลายเซ็นของ JWT โดยใช้ Secret Key เดียวกันกับที่ Authentication Server ใช้ในการลงชื่อ หากลายเซ็นถูกต้องและโทเค็นยังไม่หมดอายุ Resource Server จะเชื่อถือข้อมูลใน Payload และอนุญาตให้เข้าถึงทรัพยากรนั้นๆ ได้ครับ

กระบวนการนี้ทำให้ Resource Server ไม่จำเป็นต้องเก็บสถานะ (session) ของผู้ใช้งาน ทำให้ระบบ Scalable และทนทานต่อความผิดพลาดได้ดีขึ้นครับ

ข้อดีและข้อเสียของ JWT

ข้อดี (Pros)

• Statelessness: Server ไม่จำเป็นต้องเก็บ Session State ของผู้ใช้ ทำให้ Scalable ได้ดี เหมาะสำหรับ Microservices และ Load Balancing
• Compact: ขนาดเล็ก ส่งผ่าน HTTP Header ได้ง่ายและรวดเร็ว
• Self-contained: มีข้อมูลผู้ใช้และสิทธิ์ต่างๆ อยู่ในตัว ทำให้ Resource Server ไม่ต้องสอบถามฐานข้อมูลทุกครั้งที่ได้รับคำขอ
• Decoupled: Client, Authorization Server, Resource Server สามารถทำงานแยกกันได้อย่างอิสระ
• Cross-domain: สามารถใช้ JWT ข้ามโดเมนได้ง่าย เพราะเป็นเพียงสตริง

ข้อเสีย (Cons)

• Token Size: หาก Payload มีข้อมูลมากเกินไป จะทำให้ Token มีขนาดใหญ่ขึ้น ส่งผลต่อประสิทธิภาพในการส่งข้อมูล
• No Built-in Revocation: JWT ไม่มีกลไกในการเพิกถอน (revoke) ได้ทันทีเมื่อถูกออกไปแล้ว หากต้องการเพิกถอน ต้องใช้กลไกเพิ่มเติม เช่น Blacklist หรือ Short Expiration Time คู่กับ Refresh Token
• Security Concerns: หาก Secret Key รั่วไหล ผู้โจมตีสามารถสร้าง JWT ปลอมได้ หาก JWT ถูกดักจับและขโมยไป (เช่น XSS attack) ผู้โจมตีสามารถนำไปใช้ได้จนกว่าจะหมดอายุ
• Sensitive Data in Payload: ข้อมูลใน Payload ไม่ได้ถูกเข้ารหัส เพียงแค่ Base64Url-encoded เท่านั้น ไม่ควรใส่ข้อมูลที่อ่อนไหวมากๆ ลงไป

ตัวอย่าง Code Snippet: การสร้างและตรวจสอบ JWT

เราจะใช้ Python สำหรับตัวอย่างนี้ โดยใช้ไลบรารี PyJWT ครับ

การติดตั้งไลบรารี

pip install PyJWT

ตัวอย่างการสร้าง JWT (Token Issuance)

ในโค้ดด้านล่างนี้ เราจะสร้าง JWT ด้วยอัลกอริทึม HS256 โดยมี Payload ที่ประกอบด้วย Registered Claims และ Private Claims พร้อมกำหนดวันหมดอายุของโทเค็นครับ

import jwt
import datetime
import time

# กำหนด Secret Key สำหรับเซ็นชื่อ (Sign) และตรวจสอบ (Verify) JWT
# ควรเก็บไว้ใน Environment Variable หรือ Key Vault ไม่ใช่ในโค้ดโดยตรง!
SECRET_KEY = "your-very-secret-key-that-no-one-should-know"

# ข้อมูล Payload ที่จะใส่ใน JWT
payload = {
    "user_id": 123,
    "username": "siamlancard_dev",
    "roles": ["admin", "editor"],
    "iss": "siamlancard.com",  # ผู้ออก (Issuer)
    "exp": datetime.datetime.utcnow() + datetime.timedelta(hours=1), # หมดอายุใน 1 ชั่วโมง
    "iat": datetime.datetime.utcnow() # ออกเมื่อ (Issued at)
}

# สร้าง JWT
try:
    token = jwt.encode(payload, SECRET_KEY, algorithm="HS256")
    print("Generated JWT:", token)
except Exception as e:
    print("Error generating JWT:", e)

# ตัวอย่าง JWT ที่ได้: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsInVzZXJuYW1lIjoic2lhbWxhbmNhcmRfZGV2Iiwicm9sZXMiOlsiYWRtaW4iLCJlZGl0b3IiXSwiaXNzIjoic2lhbWxhbmNhcmQuY29tIiwiZXhwIjoxNjc5NTc3NzY2LCJpYXQiOjE2Nzk1NzQxNjZ9.SOME_SIGNATURE_STRING

ตัวอย่างการตรวจสอบ JWT (Token Verification)

โค้ดนี้จะสาธิตวิธีการตรวจสอบ JWT ที่ได้รับมา โดยจะตรวจสอบลายเซ็น, วันหมดอายุ, และ Claims ต่างๆ ครับ

import jwt
import datetime
import time

# Secret Key ต้องตรงกับตอนที่ใช้สร้างโทเค็น
SECRET_KEY = "your-very-secret-key-that-no-one-should-know"

# ตัวอย่าง JWT ที่เราเพิ่งสร้าง
# ถ้าต้องการทดสอบ JWT ที่หมดอายุ ให้เปลี่ยน exp ใน payload ตอนสร้างให้เป็นอดีต
# หรือใช้โทเค็นจริงที่หมดอายุแล้ว
generated_token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsInVzZXJuYW1lIjoic2lhbWxhbmNhcmRfZGV2Iiwicm9sZXMiOlsiYWRtaW4iLCJlZGl0b3IiXSwiaXNzIjoic2lhbWxhbmNhcmQuY29tIiwiZXhwIjoxNjc5NTc3NzY2LCJpYXQiOjE2Nzk1NzQxNjZ9.SOME_SIGNATURE_STRING"
# **สำคัญ:** แทนที่ 'generated_token' ด้วย JWT ที่คุณสร้างขึ้นจริงจากการรันโค้ดด้านบน

# การตรวจสอบ JWT
try:
    # ตรวจสอบว่าโทเค็นถูกต้องและยังไม่หมดอายุ
    decoded_payload = jwt.decode(generated_token, SECRET_KEY, algorithms=["HS256"])
    print("Decoded Payload:", decoded_payload)

    # ตรวจสอบ Claims เพิ่มเติม (ถ้ามี)
    if decoded_payload.get("iss") == "siamlancard.com":
        print("Issuer is valid.")
    else:
        print("Invalid issuer!")

    if "admin" in decoded_payload.get("roles", []):
        print("User has admin role.")
    else:
        print("User does not have admin role.")

except jwt.ExpiredSignatureError:
    print("Token has expired!")
except jwt.InvalidTokenError as e:
    print("Invalid token:", e)
except Exception as e:
    print("An unexpected error occurred:", e)

โค้ดข้างต้นแสดงให้เห็นถึงความง่ายในการสร้างและตรวจสอบ JWT ด้วยไลบรารีมาตรฐาน การจัดการ Secret Key อย่างปลอดภัยเป็นสิ่งสำคัญที่สุดในกระบวนการนี้ครับ

การนำ OAuth 2.0 และ JWT มาใช้งานร่วมกัน: พลังที่สมบูรณ์แบบ

บทบาทที่แตกต่างแต่ส่งเสริมกัน

บ่อยครั้งที่เกิดความสับสนระหว่าง OAuth 2.0 และ JWT ว่าเป็นสิ่งเดียวกัน หรือใช้แทนกันได้ แท้จริงแล้วทั้งสองมีบทบาทที่แตกต่างกันอย่างชัดเจนแต่ทำงานร่วมกันได้อย่างมีประสิทธิภาพครับ

• OAuth 2.0: มุ่งเน้นไปที่ “การอนุญาต (Authorization)”
  • เป้าหมาย: อนุญาตให้ Client เข้าถึง Resource Server ในนามของผู้ใช้ โดยไม่เปิดเผยรหัสผ่านของผู้ใช้
  • ผลลัพธ์: Client ได้รับ Access Token
  • บอกว่า: “แอปพลิเคชัน A ได้รับอนุญาตให้เข้าถึงข้อมูล B ของผู้ใช้ C”
• JWT: มุ่งเน้นไปที่ “การยืนยันตัวตน (Authentication)” และ “การถ่ายทอดข้อมูลที่เชื่อถือได้”
  • เป้าหมาย: เป็นรูปแบบของโทเค็นที่ใช้ยืนยันตัวตนของผู้ใช้ที่ได้รับอนุญาตแล้ว และส่งข้อมูลเกี่ยวกับผู้ใช้นั้นๆ อย่างปลอดภัยระหว่างระบบ
  • ผลลัพธ์: เป็นรูปแบบของ Access Token (ที่ OAuth 2.0 ออกให้)
  • บอกว่า: “โทเค็นนี้ยืนยันว่าผู้ใช้คนนี้คือใคร และมีสิทธิ์อะไรบ้าง”

ดังนั้น, OAuth 2.0 คือ “วิธีการ” ในการรับ Access Token ส่วน JWT คือ “รูปแบบ” ของ Access Token นั้นๆ ครับ

Flow การทำงานที่ผสมผสาน

เมื่อนำ OAuth 2.0 และ JWT มาใช้ร่วมกัน Flow การทำงานจะดูเหมือนเป็นส่วนขยายของ OAuth 2.0 โดยที่ Access Token ที่ถูกออกให้มีรูปแบบเป็น JWT ครับ

1. Request Authorization (OAuth 2.0):
   • Client (เช่น เว็บแอปฯ ของคุณ) ต้องการเข้าถึงข้อมูลผู้ใช้จาก Google Photos (Resource Server)
   • Client ส่งผู้ใช้ไปยัง Google’s Authorization Server เพื่อขออนุญาต
2. User Grants Permission (OAuth 2.0):
   • ผู้ใช้เข้าสู่ระบบ Google และให้การอนุญาตแก่ Client ตาม Scope ที่ร้องขอ
3. Authorization Server Issues JWT Access Token (OAuth 2.0 + JWT):
   • Google’s Authorization Server (หลังจากได้รับ authorization_code จาก Client และตรวจสอบ client_secret แล้ว) จะออก Access Token ในรูปแบบ JWT ให้กับ Client
   • JWT นี้จะประกอบด้วยข้อมูลของผู้ใช้ (เช่น ID, ชื่อ) และสิทธิ์ (Scope) ที่ได้รับอนุญาต และถูกลงชื่อด้วย Secret Key ของ Google
   • อาจมี Refresh Token ออกมาพร้อมกันด้วย
4. Client Uses JWT Access Token (JWT):
   • Client ได้รับ JWT Access Token และจัดเก็บไว้
   • เมื่อ Client ต้องการเรียกใช้ Google Photos API (Resource Server) ก็จะแนบ JWT Access Token ไปใน Header Authorization: Bearer <JWT_token>
5. Resource Server Verifies JWT (JWT):
   • Google Photos API (Resource Server) ได้รับคำขอพร้อม JWT
   • API จะตรวจสอบลายเซ็นของ JWT โดยใช้ Public Key หรือ Secret Key ที่ได้รับจาก Google’s Authorization Server
   • หากลายเซ็นถูกต้องและโทเค็นยังไม่หมดอายุ API จะเชื่อถือข้อมูลใน JWT (เช่น user ID, สิทธิ์) และอนุญาตให้เข้าถึงทรัพยากรตามที่ระบุในโทเค็นได้ทันที โดยไม่จำเป็นต้องสอบถามฐานข้อมูลผู้ใช้เพิ่มเติมครับ

จะเห็นได้ว่า OAuth 2.0 จัดการกระบวนการขอและออกโทเค็น ส่วน JWT เข้ามาเติมเต็มในส่วนของ “รูปแบบ” ของโทเค็นนั้น ทำให้การยืนยันตัวตนและการอนุญาตในการเข้าถึงทรัพยากรเป็นไปอย่างมีประสิทธิภาพและ Stateless ครับ

ประโยชน์ของการใช้ร่วมกัน

การผสมผสาน OAuth 2.0 และ JWT เข้าด้วยกันนำมาซึ่งประโยชน์มากมายครับ:

• ความปลอดภัยที่เพิ่มขึ้น: OAuth 2.0 จัดการกระบวนการอนุญาตได้อย่างปลอดภัย โดยเฉพาะ Authorization Code Grant ที่แยกการส่ง Code และ Token ออกจากกัน ส่วน JWT รับรองความสมบูรณ์และที่มาของข้อมูลใน Token
• ประสิทธิภาพและ Scalability: JWT ช่วยให้ Resource Server ไม่ต้องเก็บ Session State และไม่ต้องสอบถามฐานข้อมูลเพื่อตรวจสอบผู้ใช้ทุกครั้ง ทำให้ระบบตอบสนองเร็วขึ้นและรองรับผู้ใช้จำนวนมากได้ดีขึ้น
• ความยืดหยุ่น: JWT สามารถบรรจุ Claims ที่หลากหลาย ทำให้ปรับแต่งข้อมูลสิทธิ์และบทบาทของผู้ใช้ได้ตามต้องการ ส่วน OAuth 2.0 มี Grant Types ที่รองรับ Client หลายประเภท
• การทำงานร่วมกัน: ทั้งสองเป็นมาตรฐานเปิด ทำให้ไลบรารีและแพลตฟอร์มต่างๆ สามารถทำงานร่วมกันได้ง่าย
• การจัดการ Access Token และ Refresh Token ที่มีประสิทธิภาพ: OAuth 2.0 ช่วยให้สามารถออก Refresh Token เพื่อขอ Access Token (JWT) ใหม่ได้เมื่อโทเค็นเดิมหมดอายุ โดยไม่ต้องให้ผู้ใช้เข้าสู่ระบบใหม่ ทำให้ประสบการณ์ใช้งานราบรื่นขึ้นครับ

ความปลอดภัยและการใช้งานที่ดีที่สุด (Best Practices)

การนำ OAuth 2.0 และ JWT ไปใช้ต้องคำนึงถึงความปลอดภัยเป็นสำคัญ เพื่อป้องกันการโจมตีและการรั่วไหลของข้อมูลครับ

สำหรับ OAuth 2.0

• ใช้ Authorization Code Grant with PKCE เสมอ: สำหรับ Public Client (เช่น SPA, Mobile App) เพื่อป้องกันการโจมตีแบบ Code Injection
• รักษา Client Secret ให้เป็นความลับสูงสุด: เฉพาะ Confidential Client (Server-side app) เท่านั้นที่ควรมี Client Secret และควรเก็บไว้ใน Environment Variable หรือ Key Vault ไม่ใช่ในโค้ด
• จำกัด Redirect URI: ลงทะเบียน Redirect URI ที่ถูกต้องและเจาะจงกับ Authorization Server ให้มากที่สุด เพื่อป้องกันการโจมตีแบบ Redirect Hijacking
• กำหนด Scope ที่เหมาะสม: ให้สิทธิ์แก่ Client เท่าที่จำเป็นเท่านั้น ไม่ให้สิทธิ์มากเกินไป เพื่อลดความเสียหายหาก Client ถูกโจมตี
• ใช้ HTTPS เสมอ: การสื่อสารทุกขั้นตอนใน OAuth 2.0 ควรอยู่ภายใต้ HTTPS เพื่อป้องกันการดักจับข้อมูล (Man-in-the-Middle Attack)
• จัดการ Refresh Token อย่างปลอดภัย: เก็บ Refresh Token ไว้ใน Secure Storage บน Server-side เท่านั้น และมีกลไกในการเพิกถอน (Revoke) ได้เมื่อมีการละเมิด

สำหรับ JWT

• ใช้ Secret Key ที่แข็งแกร่งและเป็นความลับ: Secret Key ที่ใช้ในการเซ็นชื่อ JWT ต้องยาว, สุ่ม, และเป็นความลับสูงสุด การรั่วไหลของ Secret Key หมายถึงผู้โจมตีสามารถสร้าง JWT ปลอมได้ครับ
• กำหนดวันหมดอายุ (Expiration Time, exp) ที่เหมาะสม: JWT ควรมีอายุสั้น (เช่น 5-15 นาที) เพื่อลดความเสี่ยงหากถูกขโมยไป
• ไม่ใส่ข้อมูลที่อ่อนไหวใน Payload: ข้อมูลใน Payload ของ JWT ไม่ได้ถูกเข้ารหัส เพียงแค่ Base64Url-encoded เท่านั้น ดังนั้นไม่ควรใส่ข้อมูลส่วนตัวที่อ่อนไหว เช่น รหัสผ่าน, เลขบัตรเครดิต
• ตรวจสอบ Signature เสมอ: ทุกครั้งที่ Resource Server ได้รับ JWT ต้องตรวจสอบลายเซ็นก่อนเสมอ เพื่อยืนยันความถูกต้องและความสมบูรณ์ของโทเค็น
• พิจารณา Token Revocation: แม้ JWT จะไม่มีกลไกเพิกถอนในตัว แต่สามารถทำได้โดยการเก็บ JWT ID (jti claim) ไว้ใน Blacklist หรือ Redis เพื่อตรวจสอบว่าโทเค็นนั้นถูกเพิกถอนไปแล้วหรือไม่
• เลือกอัลกอริทึมการเข้ารหัสที่แข็งแกร่ง: ใช้ HS256 หรือ RS256/ES256 ขึ้นไป หลีกเลี่ยง alg: none
• ป้องกัน XSS Attack: หาก JWT ถูกเก็บไว้ใน Local Storage หรือ Session Storage อาจเสี่ยงต่อ XSS Attack ซึ่งผู้โจมตีสามารถดึง JWT ไปใช้ได้ การเก็บใน HTTP-only cookie สามารถช่วยลดความเสี่ยงนี้ได้ (แต่ก็มีข้อจำกัดอื่นๆ)

หากคุณสนใจการจัดการ Session และ Token ด้วยวิธีต่างๆ เพื่อเพิ่มความปลอดภัยให้กับแอปพลิเคชันของคุณ อ่านเพิ่มเติมได้ที่นี่ ครับ

สำหรับทั้งสองเทคโนโลยี

• ใช้ HTTPS (SSL/TLS) ในทุกการสื่อสาร: เพื่อป้องกันการดักจับข้อมูลระหว่าง Client และ Server
• ตรวจสอบ Input Validation: ตรวจสอบและกรองข้อมูลที่ได้รับจาก Client เสมอ เพื่อป้องกัน Injection Attacks
• อัปเดตไลบรารีและเฟรมเวิร์กอย่างสม่ำเสมอ: เพื่อให้มั่นใจว่าคุณได้รับแพตช์ความปลอดภัยล่าสุด
• การบันทึก Log ที่เหมาะสม: บันทึกเหตุการณ์ที่เกี่ยวข้องกับการออก/ตรวจสอบโทเค็นและการอนุญาต เพื่อช่วยในการตรวจสอบและแก้ไขปัญหาด้านความปลอดภัย

ตารางเปรียบเทียบ: OAuth 2.0 vs. JWT

เพื่อให้เห็นภาพความแตกต่างและความสัมพันธ์ของทั้งสองเทคโนโลยีได้อย่างชัดเจน ตารางนี้จะสรุปประเด็นสำคัญสำหรับการเปรียบเทียบครับ

คำถามที่พบบ่อย (FAQ)

Q1: OAuth 2.0 เป็น Authentication หรือ Authorization?

A1: OAuth 2.0 เป็น Authorization (การอนุญาต) ครับ ไม่ใช่ Authentication (การยืนยันตัวตน) โดยมีวัตถุประสงค์เพื่ออนุญาตให้แอปพลิเคชันหนึ่งเข้าถึงทรัพยากรของผู้ใช้บนอีกบริการหนึ่ง โดยที่แอปพลิเคชันนั้นไม่จำเป็นต้องรู้รหัสผ่านของผู้ใช้ครับ การยืนยันตัวตน (Authentication) เกิดขึ้นระหว่างผู้ใช้กับ Authorization Server ในขั้นตอนแรกของ Flow เท่านั้นครับ

Q2: ทำไมไม่ควรเก็บ JWT ใน Local Storage?

A2: การเก็บ JWT ใน Local Storage มีความเสี่ยงสูงต่อการโจมตีแบบ Cross-Site Scripting (XSS) ครับ ถ้าหากมีช่องโหว่ XSS บนเว็บไซต์ ผู้โจมตีสามารถรันสคริปต์ที่เป็นอันตรายเพื่อดึง JWT จาก Local Storage ของผู้ใช้ไปได้ และนำไปใช้ปลอมตัวเป็นผู้ใช้คนนั้นได้จนกว่าโทเค็นจะหมดอายุครับ วิธีที่ปลอดภัยกว่าคือการใช้ HTTP-only cookies หรือเก็บในหน่วยความจำ (in-memory) แล้วส่งผ่าน HTTP Header ครับ

Q3: ควรใช้ JWT Access Token ที่มีอายุยาวนานแค่ไหน?

A3: JWT Access Token ควรมีอายุสั้นที่สุดเท่าที่จะเป็นไปได้ครับ โดยทั่วไปแล้วแนะนำให้อายุประมาณ 5-15 นาที เพื่อลดความเสี่ยงหากโทเค็นถูกขโมยไป หากต้องการให้ผู้ใช้ไม่ต้องเข้าสู่ระบบบ่อยๆ ควรใช้ Access Token ที่มีอายุสั้นคู่กับ Refresh Token ที่มีอายุยาวนานกว่า โดย Refresh Token จะใช้สำหรับขอ Access Token ใหม่เมื่อโทเค็นเดิมหมดอายุ และ Refresh Token ควรเก็บไว้บน Server-side และมีการป้องกันอย่างรัดกุมครับ

Q4: ถ้า JWT ถูกขโมยไป จะเพิกถอนได้อย่างไร?

A4: JWT โดยตัวมันเองไม่มีกลไกในการเพิกถอน (revocation) ในทันทีครับ เนื่องจากเป็น Stateless Token ที่ Resource Server ตรวจสอบจาก Signature และวันหมดอายุเท่านั้น อย่างไรก็ตาม มีแนวทางในการจัดการคือ:

• กำหนดอายุสั้น: อย่างที่กล่าวไปแล้ว ทำให้โทเค็นที่ถูกขโมยไปใช้งานได้ไม่นาน
• Blacklist: เก็บ JWT ID (jti claim) ของโทเค็นที่ต้องการเพิกถอนไว้ในฐานข้อมูล (เช่น Redis) และทุกครั้งที่ Resource Server ได้รับ JWT ก็จะตรวจสอบกับ Blacklist นี้ก่อนว่าโทเค็นถูกเพิกถอนไปแล้วหรือไม่
• ใช้ Refresh Token: เมื่อสงสัยว่า Access Token รั่วไหล สามารถเพิกถอน Refresh Token ได้ ซึ่งจะทำให้ผู้ใช้ไม่สามารถขอ Access Token ใหม่ได้อีกต่อไป และต้องเข้าสู่ระบบใหม่ครับ

Q5: OAuth 2.0 และ JWT จำเป็นต้องใช้คู่กันเสมอไปหรือไม่?

A5: ไม่จำเป็นต้องใช้คู่กันเสมอไปครับ

• OAuth 2.0: สามารถออก Access Token ที่ไม่ใช่ JWT ก็ได้ (เช่น เป็น opaque string ที่ต้องไปตรวจสอบกับ Authorization Server ทุกครั้ง)
• JWT: สามารถนำไปใช้ในการยืนยันตัวตนในระบบที่ไม่เกี่ยวข้องกับ OAuth 2.0 ก็ได้ เช่น การใช้ JWT สำหรับ Single Sign-On (SSO) ภายใน Microservices ขององค์กร หรือการยืนยันตัวตนผ่าน API Key ที่เป็น JWT

แต่การใช้คู่กันทำให้ได้ประโยชน์ทั้งเรื่องการอนุญาตที่ยืดหยุ่นของ OAuth 2.0 และประสิทธิภาพแบบ Stateless ของ JWT ครับ มันคือการรวมพลังเพื่อสร้างระบบที่แข็งแกร่งและ Scalable ครับ

สรุปและก้าวต่อไป

เราได้เดินทางมาร่วมกันในโลกของ OAuth 2.0 และ JWT Authentication อย่างครอบคลุมแล้วนะครับ ทั้งสองเทคโนโลยีนี้เป็นเสาหลักสำคัญในการสร้างระบบความปลอดภัยสำหรับแอปพลิเคชันยุคใหม่ OAuth 2.0 ทำหน้าที่เป็นกรอบการทำงานสำหรับการอนุญาต (Authorization) ที่ยืดหยุ่นและปลอดภัย ทำให้ผู้ใช้งานสามารถให้สิทธิ์แอปพลิเคชันภายนอกเข้าถึงข้อมูลได้โดยไม่ต้องเปิดเผยรหัสผ่าน ส่วน JWT คือรูปแบบของโทเค็นที่ใช้ในการยืนยันตัวตน (Authentication) และถ่ายทอดข้อมูลผู้ใช้ได้อย่างรวดเร็วและมีประสิทธิภาพในสภาพแวดล้อมแบบ Stateless ครับ

การเข้าใจบทบาทที่แตกต่างแต่ส่งเสริมกันของ OAuth 2.0 และ JWT จะช่วยให้คุณสามารถออกแบบสถาปัตยกรรมความปลอดภัยที่แข็งแกร่ง, Scalable และตอบสนองความต้องการที่หลากหลายของการพัฒนาแอปพลิเคชันได้เป็นอย่างดีครับ อย่างไรก็ตาม สิ่งสำคัญที่สุดคือการนำแนวทางปฏิบัติที่ดีที่สุด (Best Practices) มาใช้อย่างเคร่งครัด โดยเฉพาะเรื่องการจัดการ Secret Key, การกำหนดอายุโทเค็น, และการป้องกันการโจมตีต่างๆ ครับ

ในฐานะนักพัฒนา การเรียนรู้และปรับตัวเข้ากับเทคโนโลยีใหม่ๆ อยู่เสมอเป็นสิ่งจำเป็นครับ หวังว่าบทความนี้จะเป็นประโยชน์และเป็นจุดเริ่มต้นที่ดีในการนำ OAuth 2.0 และ JWT ไปประยุกต์ใช้ในโปรเจกต์ของคุณนะครับ หากมีข้อสงสัยเพิ่มเติม หรือต้องการเจาะลึกในประเด็นใดเป็นพิเศษ อย่าลังเลที่จะศึกษาค้นคว้าเพิ่มเติม หรือปรึกษาผู้เชี่ยวชาญได้เลยครับ โลกของความปลอดภัยไซเบอร์ไม่เคยหยุดนิ่งครับ!

ขอให้สนุกกับการพัฒนาแอปพลิเคชันที่ปลอดภัยนะครับ!