01204223/authentication

แนวทางการทำ Authentication สำหรับ Web Application

เขียนโดย Gemini

การยืนยันตัวตน (Authentication) เป็นหัวใจสำคัญของความปลอดภัยใน Web Application บทความนี้จะอธิบายและเปรียบเทียบระหว่างสองแนวทางหลักที่นิยมใช้ในปัจจุบัน คือ Session-based และ Token-based

1. Session-based Authentication

เป็นวิธีการแบบดั้งเดิม (Traditional) ที่เน้นการเก็บสถานะการล็อกอินไว้ที่ฝั่ง Server (Stateful)

กระบวนการทำงาน (Workflow)

1. User Login: ผู้ใช้ส่ง Username/Password จาก Frontend ไปยัง Backend
2. Create Session: เมื่อตรวจสอบข้อมูลถูกต้อง Backend จะสร้าง "Session ID" และบันทึกข้อมูลผู้ใช้ (เช่น User ID, Role) ลงในหน่วยความจำของ Server หรือ Database
3. Set Cookie: Backend ส่ง Session ID กลับมาหา Frontend ผ่านทาง Set-Cookie header (มักจะตั้งค่าเป็น HttpOnly เพื่อความปลอดภัย)
4. Authenticated Request: ในทุกๆ Request ถัดไป Browser จะแนบ Cookie ที่มี Session ID ไปให้ Server โดยอัตโนมัติ
5. 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)

1. User Login: ผู้ใช้ส่ง Username/Password ไปยัง Backend
2. Generate Token: Backend ตรวจสอบข้อมูล หากถูกต้องจะสร้าง Token (String ยาวๆ ที่ผ่านการเข้ารหัสและลงลายเซ็น Digital Signature) ซึ่งบรรจุข้อมูลผู้ใช้ (Payload) ไว้ข้างใน
3. Send Token: Backend ส่ง Token กลับไปให้ Frontend (ปกติส่งเป็น JSON response)
4. Store Token: Frontend ต้องเขียนโค้ดเพื่อเก็บ Token เอง (เช่น เก็บใน LocalStorage หรือ Cookie)
5. Authenticated Request: Frontend ต้องแนบ Token ไปใน HTTP Header (มักใช้ header: Authorization: Bearer <token>)
6. 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 ร่วมด้วย