Session vs Token
ในระบบที่ต้องมีการยืนยันตัวตน(Authentication) เราจำเป็นต้องมีวิธีเก็บสถานะของผู้ใช้ว่าได้ Login เข้ามาแล้วรึยัง ซึ่งจะมีอยู่ 2 วิธีหลักๆ ดังนี้
- Session-based Authentication
- Token-based Authentication โดยเฉพาะ JWT (JSON Web Token) ซึ่งเป็นวิธีที่ถูกนำไป Implement มากที่สุดในปัจจุบัน
ในบทความนี้จะพาทุกท่านไปดูความแตกต่างระหว่าง Session และ Token เพื่อที่คุณจะได้เลือกใช้งานได้อย่างถูกต้อง
Session คืออะไร?
Session คือข้อมูลฝั่ง Server ที่ผูกกับผู้ใช้คนหนึ่ง หลังจากผู้ใช้ล็อกอินสำเร็จ ระบบจะสร้าง session ID ให้ และเก็บข้อมูลนี้ไว้ใน server ส่วน session ID จะถูกส่งไปเก็บที่ browser ของผู้ใช้ (ผ่าน cookie)
ตัวอย่างการทำงาน
- ผู้ใช้ล็อกอิน → server สร้าง session ID
- browser เก็บ session ID ไว้ใน cookie
- ทุกครั้งที่ส่ง request → browser ส่ง session ID ไปด้วย
- server ตรวจสอบ session ID เพื่อยืนยันตัวตน
ข้อดี
- ง่ายต่อการควบคุมและจัดการจากฝั่ง server
- สามารถ “ลบ session” ได้จาก server ทันที (เช่น เมื่อล็อกเอาต์)
ข้อเสีย
- ต้องใช้พื้นที่เก็บ session ใน server
- ไม่เหมาะกับระบบที่ต้อง scale หลายเครื่อง (หากไม่ใช้ session store ร่วมกัน)
Token คืออะไร?
Token โดยเฉพาะ JWT (JSON Web Token) คือข้อมูลยืนยันตัวตนที่สร้างหลังจากผู้ใช้ล็อกอิน และถูกฝังข้อมูลไว้ในตัว token เอง เช่น user ID, roles, expiration time เป็นต้น
Token จะถูกส่งกลับไปให้ client และ client จะเก็บไว้ (เช่น ใน localStorage หรือ sessionStorage) แล้วแนบ token นี้ไปกับทุก request (ใน header)
ตัวอย่างการทำงาน
- ผู้ใช้ล็อกอิน → server สร้าง token (JWT) และส่งให้ client
- client เก็บ token และส่งพร้อมทุก request ผ่าน HTTP header (เช่น
Authorization: Bearer <token>) - server ตรวจสอบและถอดรหัส token เพื่อตรวจสอบสิทธิ์
ข้อดี
- ไม่ต้องเก็บข้อมูลฝั่ง server → รองรับการ scale ได้ดี
- ใช้งานสะดวกในระบบ API หรือ Mobile app
- ใช้งานร่วมกับ CORS ได้ง่าย (ไม่มีปัญหา cookie)
ข้อเสีย
- Token ที่หมดอายุยากจะ “ลบออกทันที” (ไม่มี centralized revoke เหมือน session)
- ถ้า token ถูกขโมย อาจนำไปใช้ได้จนหมดอายุ
- Token ใหญ่กว่าค่า session ID (payload เยอะ)
ตารางเปรียบเทียบ Session และ Token
| หัวข้อ | Session | Token (JWT) |
|---|---|---|
| การเก็บข้อมูล | เก็บที่ Server | ฝังข้อมูลในตัว Token |
| การจัดการ | Server ควบคุมได้ | ต้องมีการวางแผนควบคุม (เช่น revoke) |
| การใช้งานกับ API | ไม่เหมาะนัก (ต้องจัดการ cookie) | เหมาะมาก โดยเฉพาะ RESTful API |
| การทำงานแบบ Distributed | ต้องใช้ session store ร่วมกัน | ไม่ต้อง แชร์ข้อมูลระหว่างเซิร์ฟเวอร์ |
| ความปลอดภัย | ปลอดภัยกว่า ถ้าใช้ HTTPS + Secure | เสี่ยงหาก token รั่ว |
| ใช้งานกับ Mobile | ไม่เหมาะ | เหมาะ |
แล้วควรเลือกแบบไหนดี?
- Web Application ทั่วไปที่ใช้โครงสร้างแบบ MVC หรือ Frontend และ Backend อยู่รวมกัน Web Application แบบนี้จะเหมาะกับการใช้ Session มากกว่า
- REST API หรือ Mobile App จะเหมาะกับการใช้งาน Token มากกว่าเพราะต้องการความเป็น Stateless เพื่อให้สามารถ Scale ได้ง่าย
- Enterprise Application ที่มีขนาดใหญ่และต้องมีการเชื่อมต่อกับระบบอื่นๆ จะเหมาะกับการใช้งาน Token มากกว่า
- ระบบที่ต้องการความปลอดภัยสูง จะเหมาะกับการใช้งาน Token แต่จะต้องเป็น Token แบบ By-Reference ที่เก็บ State หรือข้อมูลของ Client ไว้ที่ Authorization Server
สรุป
ทั้ง Session และ Token ต่างมีข้อดีข้อเสียในแบบของตัวเอง การเลือกใช้งานขึ้นอยู่กับประเภทของ Application และรูปแบบการสื่อสาร รวมทั้งการวางแผนด้านความปลอดภัยก็จะมีผลต่อการเลือกเช่นเดียวกัน
