Authentication & Session Management (ใช้ HTTPS, HttpOnly/Secure Cookies, Token Refresh)

ในยุคที่ข้อมูลส่วนบุคคลเป็นสินทรัพย์ที่มีมูลค่าสูง การรักษาความปลอดภัยในการเข้าถึงระบบ (Authentication) และการจัดการสถานะผู้ใช้งาน (Session Management) จึงเป็นรากฐานที่สำคัญที่สุดของการพัฒนาซอฟต์แวร์ที่เชื่อถือได้ ระบบที่ปลอดภัยต้องทำงานบนหลักการป้องกันหลายชั้น (Defense in Depth) ซึ่งไม่ได้จำกัดอยู่แค่การตั้งรหัสผ่านที่ซับซ้อนเท่านั้น แต่ต้องรวมถึงการเข้ารหัสการสื่อสารและการจัดการโทเคนอย่างรอบด้าน

หลักการพื้นฐานด้านความปลอดภัยในการสื่อสาร

ก่อนที่เราจะเข้าสู่การจัดการเซสชันในระดับฐานข้อมูล เราต้องเข้าใจถึงโครงสร้างพื้นฐานที่ต้องใช้ก่อน นั่นคือการบังคับใช้ HTTPS เสมอ การใช้ HTTPS ทำให้มั่นใจได้ว่าข้อมูลทั้งหมดที่ส่งระหว่างไคลเอนต์และเซิร์ฟเวอร์จะถูกเข้ารหัส (TLS/SSL) ป้องกันการดักจับข้อมูล (Man-in-the-Middle Attacks) อย่างเด็ดขาด

ในส่วนของการเก็บสถานะผู้ใช้งาน (Session State) ผ่าน Cookies เราต้องกำหนด Security Flags ที่สำคัญ 2 อย่าง:

• HttpOnly: ป้องกันไม่ให้โค้ด JavaScript ฝั่งไคลเอนต์เข้าถึง Cookie นั้นได้ ซึ่งช่วยลดความเสี่ยงจากการโจมตีแบบ Cross-Site Scripting (XSS)
• Secure: รับประกันว่า Cookie จะถูกส่งผ่านเครือข่ายก็ต่อเมื่อมีการเชื่อมต่อแบบเข้ารหัส (HTTPS) เท่านั้น

การจัดการ Authentication และ Token ด้วย PostgreSQL

เมื่อใช้สถาปัตยกรรมแบบ Token-Based (เช่น JWT) แทนการพึ่งพา Session ID ที่เก็บในเซิร์ฟเวอร์โดยตรง PostgreSQL จะเข้ามามีบทบาทสำคัญในการจัดเก็บข้อมูลผู้ใช้และโทเคนต่างๆ อย่างปลอดภัย

1. การจัดเก็บรหัสผ่านอย่างปลอดภัย (Hashing)

ห้ามเก็บรหัสผ่านเป็น Plain Text เด็ดขาด เราต้องใช้ฟังก์ชันการแฮชที่แข็งแกร่ง เช่น bcrypt หรือ Argon2 ซึ่งสามารถทำได้ในระดับแอปพลิเคชัน แต่เราสามารถออกแบบตารางผู้ใช้เพื่อรองรับการจัดเก็บค่าแฮชได้ดังนี้:

SQL

CREATE TABLE users (
    user_id SERIAL PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL, -- ใช้เก็บค่าแฮช
    is_active BOOLEAN DEFAULT TRUE
);

-- ตัวอย่างการเพิ่มข้อมูล (สมมติว่า hash ถูกสร้างจากแอปพลิเคชันแล้ว)
INSERT INTO users (username, password_hash) VALUES ('user1', 'hashed_password_example');

2. การจัดการ Refresh Token

เนื่องจาก Access Token มีอายุสั้นเพื่อลดความเสี่ยง เราจึงใช้ Refresh Token ซึ่งมีอายุยาวกว่า และต้องถูกเก็บไว้ในฐานข้อมูลเพื่อการตรวจสอบ เมื่อผู้ใช้พยายามเข้าถึงระบบและ Access Token หมดอายุ ระบบจะต้องตรวจสอบ Refresh Token ใน PostgreSQL ก่อน:

SQL

CREATE TABLE refresh_tokens (
    token_id SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(user_id),
    token_hash VARCHAR(255) UNIQUE NOT NULL, -- เก็บแฮชของ Refresh Token
    expires_at TIMESTAMP WITHOUT TIME ZONE NOT NULL
);

-- ตัวอย่างการตรวจสอบและสร้างโทเคนใหม่ (Conceptual Query)
SELECT generate_jwt_token(user_id, 'new_access_token') 
FROM refresh_tokens 
WHERE token_hash = 'hashed_refresh_token_from_client' 
AND expires_at > NOW();

บทสรุป: การป้องกันแบบหลายชั้น

การจัดการเซสชันที่สมบูรณ์แบบคือการผสานรวมเทคโนโลยีหลายส่วนเข้าด้วยกัน ตั้งแต่การบังคับใช้ HTTPS ในระดับเครือข่าย การใช้ HttpOnly/Secure Cookies ในระดับเบราว์เซอร์ การแฮชรหัสผ่านที่แข็งแกร่งใน PostgreSQL และการใช้กลไก Token Refresh ที่มีอายุจำกัด การปฏิบัติตามหลักการเหล่านี้จะช่วยสร้างระบบที่ทนทานต่อการโจมตีทางไซเบอร์ได้อย่างมีประสิทธิภาพ