---
title: JWT (JSON Web Token) คืออะไร ใช้ทำอะไร และมีความสำคัญอย่างไรในการพัฒนา Web Application
---
ในยุคที่เทคโนโลยีพัฒนาไปอย่างรวดเร็ว ความปลอดภัยออนไลน์เป็นประเด็นที่มีความสำคัญมากขึ้นแทบทุกวัน นักพัฒนาเว็บไซต์และแอปพลิเคชันต่างต้องพิจารณาถึงวิธีการรักษาความปลอดภัยของข้อมูลและการตรวจสอบสิทธิ์ใช้งาน (Authentication) ของผู้ใช้ เพื่อให้แน่ใจว่าข้อมูลส่วนบุคคลและการดำเนินการต่างๆ เป็นไปอย่างมีความปลอดภัย ในการเข้าถึงระบบ เรามักจะพบกับเทคโนโลยีหนึ่งที่ช่วยในการจัดการเรื่องนี้ นั่นก็คือ JWT (JSON Web Token) นั่นเอง
JWT ย่อมาจาก JSON Web Token เป็นมาตรฐานของการสร้าง access token ที่อนุญาตให้สามารถแลกเปลี่ยนข้อมูลชุดเล็กๆ ระหว่างสองฝ่ายได้อย่างปลอดภัย มันทำงานร่วมกับโปรโตคอล OAuth 2.0 และ OpenID Connect ได้เป็นอย่างดี ถูกใช้กันอย่างแพร่หลายในการประกันความถูกต้องของข้อมูลและการส่งข้อมูลระหว่างบริการต่างๆ
ประเด็นหลักๆ คือ ระบบ Authen เดียวนี้มันซับซ้อนเพราะ ว่า เราทำงานแบบ Horizontal Scaling บางครั้งเวลาส่งข้อมูลไป หา Server ไม่ใช่เครื่องเดิมหรือ Process เดิมที่รับเรื่องแล้ว ทีนี้ มันก็ต้องมีการจำ Session ใช่ไหม ซึ่งอันนั้นจะเป็นแบบ stateful ซึ่งบางครั้งก็ไม่สะดวก เพราะว่าต้องมีการติดต่อ module หรือ microservice อื่นๆ เพื่อขอ ความรู้เกี่ยวกับ user ที่เกี่ยวกับ session นั้นๆ
เช่น ในระบบของเรามี Server A , Server B , Server C ตอนที่ ผู้ใช้ Login เข้ามาครั้งแรก อาจจะติดต่อกับ Server A แต่หลังจาก นั้น เมื่อเวลาผ่านไป 0.1 วินาที User Connect เข้ามาใหม่ แต่ตอนนี้ load balancer ของเราส่งไป ให้ Server B บางคนอาจจะด่าในใจ ว่าทำไมไม่ set ให้ load balancer ใช้วิธีแบบ sticky session สะเลยง่ายดี แต่ในหลายๆ งานอาจจะไม่สะดวก ก็เป็นไปได้
เราเลยอยากให้ข้อมูลบางอย่างอยู่ใน Client ที่ส่งมาด้วย ซึ่งก็จะคร้ายๆ กับ Cookies ที่ web browser ทำอยู่แล้วนั้นเอง แต่เพื่อความเป็นระบบ และความปลอดภัยมากยิ่งขึ้นเราเลย จับ payload หรือข้อมูลที่อยากจะเก็บ มาเข้ารหัสสะ แค่นั้นเองและเรียกชื่อใหม่ให้มันเท่ๆ ว่า JSON WEB Token นั้นเอง
อ่าว อ่านมาตรงนี้หลายท่านอาจจะส่งสัยมันก็คือ Cookies นี่น่าแล้วเรามี JWT ทำไม
คุณ MVDD ใน stackoverflow เขียนอธิบายไว้อย่างดีดังนี้
....
ความแตกต่างที่ใหญ่ที่สุดระหว่างโทเค็นผู้ถือและคุกกี้คือเบราว์เซอร์จะส่งคุกกี้โดยอัตโนมัติ โดยที่โทเค็นผู้ถือจะต้องเพิ่มลงในคำขอ HTTP อย่างชัดเจน
คุณลักษณะนี้ทำให้คุกกี้เป็นวิธีที่ดีในการรักษาความปลอดภัยเว็บไซต์ โดยที่ผู้ใช้เข้าสู่ระบบและนำทางระหว่างหน้าต่างๆ โดยใช้ลิงก์
เบราว์เซอร์ที่ส่งคุกกี้โดยอัตโนมัติก็มีข้อเสียใหญ่เช่นกัน ซึ่งก็คือการโจมตี CSRF ในการโจมตี CSRF เว็บไซต์ที่เป็นอันตรายจะใช้ประโยชน์จากข้อเท็จจริงที่ว่าเบราว์เซอร์ของคุณจะแนบคุกกี้การรับรองความถูกต้องเข้ากับคำขอไปยังโดเมนนั้นโดยอัตโนมัติ และหลอกให้เบราว์เซอร์ของคุณดำเนินการตามคำขอ
สมมติว่าเว็บไซต์ https://www.example.com อนุญาตให้ผู้ใช้ที่ได้รับการรับรองความถูกต้องสามารถเปลี่ยนรหัสผ่านได้โดย POST ป้อนรหัสผ่านใหม่ไปที่ https://www.example.com/changepassword โดยไม่ต้องโพสต์ชื่อผู้ใช้หรือรหัสผ่านเก่า .
หากคุณยังคงเข้าสู่ระบบเว็บไซต์นั้นเมื่อคุณเยี่ยมชมเว็บไซต์ที่เป็นอันตรายซึ่งโหลดหน้าเว็บในเบราว์เซอร์ของคุณที่ทริกเกอร์ POST ไปยังที่อยู่นั้น เบราว์เซอร์ของคุณจะแนบคุกกี้การรับรองความถูกต้องอย่างซื่อสัตย์ ช่วยให้ผู้โจมตีสามารถเปลี่ยนรหัสผ่านของคุณได้
คุกกี้ยังสามารถใช้เพื่อปกป้องบริการบนเว็บได้ แต่ปัจจุบันโทเค็นผู้ถือถูกใช้บ่อยที่สุด หากคุณใช้คุกกี้เพื่อปกป้องบริการเว็บของคุณ บริการนั้นจะต้องอยู่บนโดเมนที่มีการตั้งค่าคุกกี้การรับรองความถูกต้อง เนื่องจากนโยบายต้นทางเดียวกันจะไม่ส่งคุกกี้ไปยังโดเมนอื่น
นอกจากนี้ คุกกี้ยังทำให้แอปพลิเคชันที่ไม่ใช่เบราว์เซอร์ (เช่น แอปบนมือถือไปจนถึงแท็บเล็ต) ใช้งาน API ของคุณได้ยากขึ้น
...
การทำงาน
1 client (web browser of application) ---> connect to server ---> server
2 server create JWT with data
3 client (web browser of application) <--- server send JWT to client <--- server
4 ....
5 client (web browser of application) ---> sen JWT to server fot Authen ---> server2
6 server2 ตรวจสอบ JWT นั้นๆ หากผ่านก็ ให้ สิทธิ์ในการเข้า resource ต่างๆ ได้
สังเกตว่า SERVER ในข้อ 5 ไม่จำเป็น ต้องเป็นตัวเดียวกับ ใน 1 และ 3 เพราะข้อมูลที่ต้องใข้อยู่ใน Payload เรียบร้อยแบ้วววววว
- ข้อสังเกต JWT ไม่ได้ป้องกัน man in the middle attrack
- data เก็บอยู่ที่ผู้ใช้
- Both API key and JWT can provide authentication and authorization. API key is on project scope and JWT is on user scope.
- JWT server จะเป็นผู้เก็บ Secret และ Key ทั้งหมด
JWT ประกอบด้วยสามส่วนหลัก ๆ คือ Header, Payload และ Signature แต่ละส่วนถูกแยกออกจากกันด้วยจุด (.) และส่วนใหญ่จะถูกเข้ารหัสด้วย Base64 URL encoding:
1. Header: ประกอบไปด้วยชนิดของ token (เช่น JWT) และอัลกอริธึมที่ใช้ในการเข้ารหัส (เช่น HS256, RS256 หรือจะใช้ Asymetric key อื่นๆ ก็ได้)
2. Payload: บรรจุข้อมูล Claims เช่นข้อมูลผู้ใช้ หรือค่าของ session
3. Signature: เป็นการเซ็นสัญญาระหว่าง Header และ Payload ด้วย secret key ที่เซิร์ฟเวอร์ถือเพียงฝ่ายเดียว
JWT มีบทบาทในหลายด้านเมื่อพูดถึง web application:
การ Authentication
JWT มักจะถูกใช้ในการตรวจสอบสิทธิ์ว่าผู้ใช้นั้นได้เข้าสู่ระบบแล้ว (logged in) ผ่านการตรวจสอบ signature ที่ถูกต้อง
การ Authorization
เมื่อผู้ใช้ได้รับการตรวจสอบแล้ว JWT จะถูกใช้เพื่อดูสิทธิ์ในการเข้าถึงทรัพยากรต่างๆ ในระบบ
การแลกเปลี่ยนข้อมูล
JWT สามารถถูกส่งระหว่างบริการต่างๆ เพื่อให้สามารถส่งข้อมูลที่มีการตรวจสอบแล้วได้อย่างปลอดภัย
นี่คือตัวอย่างโค้ดเบื้องต้นในการสร้างและตรวจสอบ JWT โดยใช้ภาษา JavaScript และไลบรารี jsonwebtoken:
const jwt = require('jsonwebtoken');
// สร้าง JWT
const token = jwt.sign({ user_id: user._id }, 'your-256-bit-secret', {
expiresIn: '1h'
});
// ตรวจสอบ JWT
jwt.verify(token, 'your-256-bit-secret', function(err, decoded) {
if (err) {
// มีข้อผิดพลาดในการตรวจสอบ
console.log(err.message);
} else {
// JWT ถูกต้อง
console.log(decoded);
}
});
จากโค้ดด้านบน คุณทำการ "สร้าง" JWT โดยใช้ user_id ที่เป็น unique กับ user คนนั้น และใช้ secret key ที่ควรจะถูกเก็บเป็นความลับ จากนั้นคุณ "ตรวจสอบ" JWT ด้วยการใช้การ verify ที่ตรวจสอบว่า JWT นั้นถูกสร้างขึ้นโดย server ของคุณหรือไม่ และยังไม่หมดอายุ
อ่านเพิ่มเติมที่ https://codinggun.com/security/jwt/#:~:text=JWT(Json%20Web%20Tokens)%20%E0%B8%84%E0%B8%B7%E0%B8%AD,%E0%B8%95%E0%B8%AD%E0%B8%99%E0%B8%95%E0%B9%88%E0%B8%B2%E0%B8%87%E0%B9%86%20%E0%B8%95%E0%B8%B2%E0%B8%A1%E0%B8%A3%E0%B8%B9%E0%B8%9B%E0%B8%99%E0%B8%B5%E0%B9%89
ที่ EPT, หรือ Expert-Programming-Tutor, เราอุทิศตนในการสอนและพัฒนาทักษะของนักพัฒนาซอฟต์แวร์ทุกระดับ เทคโนโลยีเกี่ยวกับการตรวจสอบสิทธิ์ที่มั่นใจต่างๆ รวมถึง JWT นั้นเป็นส่วนสำคัญที่เราให้ความสำคัญ หากคุณมีความสนใจในการเขียนโค้ดอย่างมีความปลอดภัยและเชี่ยวชาญ เรายินดีที่จะเชิญคุณมาศึกษาและพัฒนาทักษะกับเราที่ EPT
ปิดท้ายด้วยคำถามที่อาจพบบ่อย: ใช่ว่าสิ่งดีเสมอมาในแพคเกจที่สมบูรณ์ การใช้ JWT ต้องพิจารณาถึงความเสี่ยงและข้อจำกัดที่อาจตามมา เช่นความเปราะบางต่อการโจมตีแบบ Cross-Site Scripting (XSS) หรือสถานการณ์ที่ต้องการ revoke tokens ก่อนหมดอายุ ในงานสัมมนาและหลักสูตรของ EPT เราจะครอบคลุมถึงภาพใหญ่และลึกถึงการใช้ JWT และการปกป้องระบบของคุณให้ห่างไกลจากความเสี่ยงดังกล่าว
สนใจที่จะเรียนรู้เพิ่มเติม ลงทะเบียนหลักสูตรของเราวันนี้ และปลดล็อคโลกของการเขียนโค้ดและการพัฒนาซอฟต์แวร์ที่ปลอดภัยไปด้วยกัน!
หมายเหตุ: ข้อมูลในบทความนี้อาจจะผิด โปรดตรวจสอบความถูกต้องของบทความอีกครั้งหนึ่ง บทความนี้ไม่สามารถนำไปใช้อ้างอิงใด ๆ ได้ ทาง EPT ไม่ขอยืนยันความถูกต้อง และไม่ขอรับผิดชอบต่อความเสียหายใดที่เกิดจากบทความชุดนี้ทั้งทางทรัพย์สิน ร่างกาย หรือจิตใจของผู้อ่านและผู้เกี่ยวข้อง
หากเจอข้อผิดพลาด หรือต้องการพูดคุย ติดต่อได้ที่ https://m.me/expert.Programming.Tutor/
หากมีข้อผิดพลาด/ต้องการพูดคุยเพิ่มเติมเกี่ยวกับบทความนี้ กรุณาแจ้งที่ http://m.me/Expert.Programming.Tutor
085-350-7540 (DTAC)
084-88-00-255 (AIS)
026-111-618
หรือทาง EMAIL: NTPRINTF@GMAIL.COM