แนวทางการทำ Authentication สำหรับ Web Application
- เขียนโดย Gemini
การยืนยันตัวตน (Authentication) เป็นหัวใจสำคัญของความปลอดภัยใน Web Application บทความนี้จะอธิบายและเปรียบเทียบระหว่างสองแนวทางหลักที่นิยมใช้ในปัจจุบัน คือ Session-based และ Token-based
1. Session-based Authentication
เป็นวิธีการแบบดั้งเดิม (Traditional) ที่เน้นการเก็บสถานะการล็อกอินไว้ที่ฝั่ง Server (Stateful)
กระบวนการทำงาน (Workflow)
- User Login: ผู้ใช้ส่ง Username/Password จาก Frontend ไปยัง Backend
- Create Session: เมื่อตรวจสอบข้อมูลถูกต้อง Backend จะสร้าง "Session ID" และบันทึกข้อมูลผู้ใช้ (เช่น User ID, Role) ลงในหน่วยความจำของ Server หรือ Database
- Set Cookie: Backend ส่ง Session ID กลับมาหา Frontend ผ่านทาง Set-Cookie header (มักจะตั้งค่าเป็น HttpOnly เพื่อความปลอดภัย)
- Authenticated Request: ในทุกๆ Request ถัดไป Browser จะแนบ Cookie ที่มี Session ID ไปให้ Server โดยอัตโนมัติ
- Validation: Server ตรวจสอบ Session ID จาก Cookie เทียบกับข้อมูลใน Storage หากตรงกันถือว่ายืนยันตัวตนสำเร็จ
ข้อดีและข้อเสีย
| ข้อดี |
ข้อเสีย
|
- Security: ควบคุมได้ง่าย (เช่น สั่ง Invalidate session เพื่อเตะผู้ใช้ออกได้ทันที)
- Code Simplicity: Framework ส่วนใหญ่รองรับมาแต่กำเนิด
- Cookie Handling: Browser จัดการการส่ง Cookie ให้เองโดยอัตโนมัติ
|
- Scalability: หากมี Server หลายตัว (Load Balancing) ต้องทำ Sticky Session หรือใช้ Redis เพื่อแชร์ Session Store ร่วมกัน
- Performance: เปลืองทรัพยากร Server ในการเก็บข้อมูล Session ของผู้ใช้ทุกคน
- CSRF: มีความเสี่ยงต่อการโจมตีแบบ CSRF (Cross-Site Request Forgery) หากไม่ป้องกันให้ดี
|
2. Token-based Authentication (JWT)
เป็นวิธีการที่นิยมใน Modern Web App และ Microservices โดยเน้นการไม่เก็บสถานะที่ Server (Stateless) แต่ใช้การเข้ารหัสข้อมูลยืนยันตัวตนส่งไปให้ Client ถือไว้แทน (นิยมใช้มาตรฐาน JSON Web Token - JWT)
กระบวนการทำงาน (Workflow)
- User Login: ผู้ใช้ส่ง Username/Password ไปยัง Backend
- Generate Token: Backend ตรวจสอบข้อมูล หากถูกต้องจะสร้าง Token (String ยาวๆ ที่ผ่านการเข้ารหัสและลงลายเซ็น Digital Signature) ซึ่งบรรจุข้อมูลผู้ใช้ (Payload) ไว้ข้างใน
- Send Token: Backend ส่ง Token กลับไปให้ Frontend (ปกติส่งเป็น JSON response)
- Store Token: Frontend ต้องเขียนโค้ดเพื่อเก็บ Token เอง (เช่น เก็บใน LocalStorage หรือ Cookie)
- Authenticated Request: Frontend ต้องแนบ Token ไปใน HTTP Header (มักใช้ header:
Authorization: Bearer <token>)
- Validation: Server ตรวจสอบความถูกต้องของลายเซ็น (Signature) ใน Token โดยใช้ Secret Key หากถอดรหัสได้และ Token ยังไม่หมดอายุ ก็จะอนุญาตให้เข้าถึงข้อมูล (ไม่ต้อง Query Database เพื่อหา Session)
ข้อดีและข้อเสีย
| ข้อดี |
ข้อเสีย
|
- Stateless & Scalable: Server ไม่ต้องจำอะไร ขยาย Server (Scale out) ได้ง่ายมาก
- Cross-Domain: สามารถใช้ Token เดียวกันกับหลายๆ Domain หรือ Mobile App ได้ง่าย
- Performance: ลดภาระการอ่านเขียน Database/Memory เพื่อตรวจสอบ Session
|
- Revocation Difficulties: การยกเลิก Token ก่อนหมดอายุทำได้ยาก (เพราะ Server ไม่ได้เก็บสถานะ) ต้องใช้เทคนิค Blacklist หรือลดอายุ Token ให้สั้นลง (Short-lived)
- Storage Security: หากเก็บใน LocalStorage อาจเสี่ยงต่อ XSS
- Payload Size: Token มีขนาดใหญ่กว่า Session ID อาจเปลือง Bandwidth หากข้อมูลเยอะ
|
ตารางเปรียบเทียบ (Comparison)
| หัวข้อ |
Session-based |
Token-based (JWT)
|
| State |
Stateful (เก็บที่ Server) |
Stateless (เก็บที่ Client/Token)
|
| Storage |
Server Memory / Database |
Client (LocalStorage / Cookie)
|
| Scalability |
ยากกว่า (ต้องจัดการ Session Store) |
ง่ายมาก
|
| Logout/Revoke |
ง่ายดาย (ลบ Session ทิ้ง) |
ยาก (ต้องรอ Expire หรือทำ Blacklist)
|
| เหมาะสำหรับ |
Web App ทั่วไป, CMS, องค์กรที่เน้นความปลอดภัยสูง |
SPA (Single Page App), Mobile App, API Service
|
คำแนะนำเพิ่มเติมในการนำไปใช้:
- Session-based: เหมาะที่สุดสำหรับระบบหลังบ้าน (Back-office), ระบบการเงิน หรือเว็บที่ไม่ซับซ้อนมาก และต้องการควบคุมความปลอดภัยในการ Log out สูงสุด
- Token-based: เหมาะที่สุดสำหรับ Frontend ที่เป็น JavaScript Framework (React, Vue, Angular) หรือกรณีที่มี Mobile Application ใช้งาน API ร่วมด้วย
