ภาพรวม: การยืนยันตัวตน (Authentication) และการจัดการสิทธิ์ (Authorization)

ก่อนที่เราจะไปเจาะลึกเรื่อง Basic Authentication (ซึ่งเป็นแค่วิธีหนึ่งที่เก่าแก่มากๆ) เรามาทำความเข้าใจภาพใหญ่ของระบบยืนยันตัวตนและจัดการสิทธิ์กันก่อนดีกว่าครับ เพราะสองเรื่องนี้เป็นหัวใจสำคัญของแอปพลิเคชันที่ปลอดภัยเกือบทุกตัว

Authentication (AuthN): "คุณคือใคร?"

Authentication คือกระบวนการ พิสูจน์ว่าคุณคือคนที่คุณอ้างว่าเป็นจริง (Verifying your identity) เหมือนกับการแสดงบัตรประชาชนให้ยามดู หรือการใส่รหัส ATM เพื่อยืนยันว่าเป็นเจ้าของบัญชีจริงๆ

ในโลกเว็บ/แอป มันคือการที่ผู้ใช้ต้องแสดงหลักฐานบางอย่าง (เช่น Username/Password, ลายนิ้วมือ, รหัส OTP) เพื่อให้ระบบเชื่อว่า "อ๋อ นี่คือ User A ตัวจริงนะ ไม่ใช่ใครแอบอ้าง"

เป้าหมายหลัก: ป้องกันไม่ให้คนที่ไม่เกี่ยวข้องเข้าถึงข้อมูลหรือระบบได้

Authorization (AuthZ): "คุณทำอะไรได้บ้าง?"

หลังจากที่ระบบรู้แล้วว่า "คุณคือใคร" (ผ่าน Authentication) ขั้นตอนต่อไปคือ การกำหนดว่าคุณมีสิทธิ์ทำอะไรได้บ้าง (Determining your permissions) หรือที่มักเรียกว่า Access Control

เหมือนกับการที่ยามรู้แล้วว่าคุณคือพนักงาน แต่บัตรของคุณอาจจะเข้าได้แค่ชั้น 1-5 เข้าชั้นผู้บริหารไม่ได้ หรือในแอป E-commerce คุณอาจจะดูสินค้าได้ สั่งซื้อได้ แต่ลบสินค้าออกจากระบบไม่ได้ (ซึ่ง Admin ทำได้)

เป้าหมายหลัก: ควบคุมการเข้าถึงทรัพยากรและฟังก์ชันต่างๆ ตามบทบาทหรือสิทธิ์ของผู้ใช้แต่ละคน

สรุปง่ายๆ:

• AuthN: เช็คว่าเป็นตัวจริงไหม?
• AuthZ: เช็คว่ามีสิทธิ์ทำสิ่งนี้ไหม?

Workflow การยืนยันตัวตนทั่วไป

แม้จะมีรายละเอียดต่างกันไปในแต่ละวิธี แต่ Workflow พื้นฐานมักจะคล้ายๆ กัน:

1. ผู้ใช้พยายามเข้าถึง: ผู้ใช้เปิดหน้า Login หรือพยายามเข้าถึงหน้าที่ต้องมีการยืนยันตัวตน
2. ผู้ใช้ส่ง Credentials: ผู้ใช้กรอก Username/Password หรือใช้วิธีอื่น (เช่น Biometrics, Social Login) แล้วส่งข้อมูลให้ Server
3. Server ตรวจสอบ: Server นำ Credentials ที่ได้รับไปตรวจสอบกับข้อมูลในฐานข้อมูล
4. Server ตอบสนอง:
   • ถ้าถูกต้อง: Server จะสร้าง "หลักฐานการยืนยันตัวตน" (Proof of Authentication) บางอย่างขึ้นมา (อาจจะเป็น Session ID หรือ Token) แล้วส่งกลับไปให้ Client เก็บไว้
   • ถ้าไม่ถูกต้อง: Server แจ้งข้อผิดพลาดกลับไป
5. การเข้าถึงครั้งถัดไป: Client (เช่น Browser) จะแนบ "หลักฐาน" นั้นไปกับทุกๆ คำขอที่ส่งไปยัง Server
6. Server ตรวจสอบหลักฐาน: Server เช็คว่าหลักฐานที่ส่งมาถูกต้องและยังไม่หมดอายุหรือไม่ ถ้าใช่ ก็อนุญาตให้เข้าถึงทรัพยากรได้

"หลักฐานการยืนยันตัวตน" (Proof of Authentication) มีแบบไหนบ้าง?

สิ่งที่ Server ส่งกลับมาให้ Client เก็บไว้ใช้ยืนยันตัวตนในครั้งถัดๆ ไป มีหลายรูปแบบ ที่พบบ่อยๆ คือ:

1. Credentials เดิม (เช่น Username/Password): นี่คือวิธีที่ Basic Authentication ใช้ครับ Client จะส่ง Username/Password (ที่แปลง Base64 แล้ว) ไปกับ ทุก Request วิธีนี้ไม่ปลอดภัยอย่างยิ่ง เพราะเหมือนส่งกุญแจบ้านไปกับจดหมายทุกฉบับ
2. Session ID: Server สร้าง ID เฉพาะสำหรับ Session การล็อกอินนั้นๆ แล้วเก็บข้อมูลผู้ใช้ไว้ฝั่ง Server เอง Client จะส่งแค่ Session ID (มักจะอยู่ใน Cookie) กลับไป Server ก็จะรู้ว่าเป็นใคร วิธีนี้ Server ต้องรับภาระเก็บข้อมูล Session ทั้งหมด (Stateful)
3. Token (เช่น JWT - JSON Web Token): Server สร้าง Token ที่มีข้อมูลผู้ใช้และลายเซ็นดิจิทัลฝังอยู่ข้างใน แล้วส่งให้ Client เก็บ Client ส่ง Token นี้กลับไปใน Header ของทุก Request Server สามารถตรวจสอบความถูกต้องของ Token ได้โดยไม่ต้องเก็บข้อมูลอะไรเพิ่ม (Stateless) วิธีนี้กำลังเป็นที่นิยมมากสำหรับ APIs และแอปสมัยใหม่

Basic Authentication ที่เรากำลังจะเรียนรู้ในบทถัดๆ ไป จัดอยู่ในประเภทแรก ซึ่งมีความปลอดภัยต่ำที่สุดและไม่แนะนำให้ใช้ในระบบงานจริงปัจจุบันครับ

User Management: จัดการผู้ใช้ในระบบ

นอกจากการยืนยันตัวตนแล้ว ระบบส่วนใหญ่ยังต้องการ การจัดการผู้ใช้ (User Management) ด้วย ซึ่งหมายถึงความสามารถในการ:

• สร้าง (Create): เพิ่มผู้ใช้ใหม่เข้าระบบ (เช่น การสมัครสมาชิก)
• อ่าน (Read): ดูข้อมูลผู้ใช้ (เช่น หน้า Profile)
• แก้ไข (Update): เปลี่ยนแปลงข้อมูลผู้ใช้ (เช่น เปลี่ยนรหัสผ่าน, อัปเดตข้อมูลส่วนตัว)
• ลบ (Delete): ลบผู้ใช้ออกจากระบบ
• (เพิ่มเติม) การกำหนด Roles & Permissions: กำหนดบทบาท (เช่น admin, editor, viewer) และสิทธิ์การเข้าถึงต่างๆ ให้กับผู้ใช้ ซึ่งเกี่ยวข้องกับ Authorization (AuthZ) โดยตรง

เครื่องมือหรือ Service ด้าน Authentication สมัยใหม่หลายตัว (เช่น Supabase Auth, Auth0, Firebase Auth, WorkOS) มักจะมีฟังก์ชัน User Management มาให้พร้อมใช้งาน ช่วยลดภาระของนักพัฒนาไปได้มาก

---

ตอนนี้เราพอเห็นภาพรวมของ Authentication และ Authorization แล้ว ในบทถัดไป เราจะกลับไปเจาะลึกที่ Basic Authentication โดยเฉพาะ เพื่อทำความเข้าใจกลไกการทำงาน ข้อจำกัด และเหตุผลว่าทำไมเราถึงควรหลีกเลี่ยงมันครับ