Session​,​ ​Cookie​ ​และ​ ​JWT​ ​ต่าง​กัน​อย่างไร​ใน​การ​ทำ​ระบบ​ ​Login

Session, Cookie และ JWT ไม่ใช่ทางเลือกสามอย่างในระดับเดียวกัน Cookie เป็นกลไกที่ Browser ใช้เก็บและส่งข้อมูลกับเว็บไซต์ Session เป็นสถานะการใช้งานที่ผูกกับผู้ใช้และต้องมีวิธีจัดการอายุ/การยกเลิก ส่วน JWT เป็นรูปแบบ Token ที่บรรจุ Claim และตรวจความถูกต้องตามมาตรฐาน การทำ Login อาจใช้ Cookie ส่งรหัส Session หรือส่ง Token บางชนิดก็ได้

วิธี Session ฝั่ง Server

หลังยืนยันตัวตน Server สร้างตัวระบุ Session และส่งให้ Browser ผ่าน Cookie ที่ตั้งค่าป้องกันเหมาะสม เมื่อมีคำขอใหม่ Server ใช้ตัวระบุค้นสถานะ ผู้ดูแลสามารถยกเลิก Session ฝั่ง Server ตามนโยบาย ข้อแลกเปลี่ยนคือระบบต้องเก็บหรือเข้าถึงสถานะนี้อย่างเชื่อถือได้

ภาพที่ 1: ไม่ว่าส่งรหัส Session หรือ Token ระบบยังต้องตรวจตัวตน อายุ และสิทธิ์ทุกครั้ง

JWT ช่วยอะไรและไม่ช่วยอะไร

JWT บรรจุ Claim เช่น ผู้ใช้และเวลาหมดอายุในรูปแบบที่ลงลายเซ็นหรือตามมาตรฐานที่รองรับ แต่การมี JWT ไม่ทำให้ข้อมูลใน Token ลับโดยอัตโนมัติ และไม่ได้แก้ปัญหาการถอนสิทธิ์ทันที ต้องออกแบบอายุ Token การเปลี่ยนคีย์ และการตรวจ Claim ให้ถูก หากบทบาทถูกเปลี่ยนแต่ Token เก่ายังใช้ได้ ระบบต้องมีวิธีจัดการให้ตรงนโยบาย

ตัวอย่างสมมติ: พนักงานออกจากทีม

องค์กรต้องปิดสิทธิ์พนักงานเมื่อออกจากงาน หากใช้ Session ฝั่ง Server อาจยกเลิก Session ที่เกี่ยวข้องได้โดยตรง หากใช้ Token ที่ตรวจโดยไม่ถาม Server เลย ต้องวางอายุสั้นหรือกลไกยกเลิกที่เหมาะสม ทางเลือกขึ้นกับความเสี่ยงและโครงสร้างระบบ ไม่ใช่คำกล่าวว่า JWT “ทันสมัยกว่า”

สำหรับรายงาน

วาดว่าอะไรอยู่ใน Browser อะไรอยู่บน Server ระบุอายุการใช้งาน การออกจากระบบ และการถอนสิทธิ์ แยกความปลอดภัยของ Cookie จากรูปแบบข้อมูลใน JWT เพราะทั้งสองเป็นคนละประเด็น หลีกเลี่ยงการใส่ข้อมูลลับหรือข้อมูลส่วนบุคคลเกินจำเป็นใน Claim

อ่าน Authentication กับ Authorization หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ แผน Cookie, Session ID หรือ JWT, อายุ, refresh และการเพิกถอน ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ ทดสอบหมดอายุ ออกจากระบบ และการถูกขโมย token ในระดับที่กำหนด ส่วนข้อจำกัดที่ต้องระบุคือ Cookie เป็นช่องทางเก็บหรือส่งค่า ส่วน JWT เป็นรูปแบบ token ไม่ใช่สิ่งเดียวกัน หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• OWASP: Session Management Cheat Sheet — วิธีดูแล Session
• RFC 7519: JSON Web Token — นิยามและโครงสร้าง JWT