Authentication​ ​กับ​ ​Authorization​ ​ต่าง​กัน​อย่างไร

Authentication ตอบว่า “ผู้ใช้นี้เป็นใคร” เช่น ตรวจบัญชีและรหัสผ่านหรือวิธียืนยันอื่น Authorization ตอบว่า “ผู้ใช้นี้ทำอะไรกับข้อมูลใดได้” การ Login สำเร็จจึงไม่ได้ให้สิทธิ์อ่านคำขอของทุกคน การแยกสองเรื่องนี้เป็นฐานของการออกแบบระบบที่มีหลายบทบาทหรือหลายองค์กร

ลำดับเมื่อผู้ใช้เรียก API

Server รับคำขอแล้วตรวจหลักฐานตัวตน จากนั้นตรวจสิทธิ์ของการกระทำและรายการที่ขอ เช่น ผู้ใช้ A อ่านคำขอหมายเลข 123 ได้หรือไม่ การซ่อนปุ่มบน Frontend ทำให้ใช้งานง่ายขึ้น แต่ไม่ป้องกันผู้ใช้เปลี่ยน URL หรือส่ง Request ตรงไปยัง API

ภาพที่ 1: ผ่าน Login แล้ว ยังต้องตรวจสิทธิ์ของการกระทำและขอบเขตข้อมูลในทุกคำขอ

ตัวอย่างสมมติ: ระบบเอกสารหลายทีม

พนักงานสองคน Login ถูกต้องทั้งคู่ แต่คนหนึ่งอยู่ฝ่ายขาย อีกคนอยู่บัญชี หากเอกสารหมายเลข 55 เป็นของบัญชี ฝ่ายขายไม่ควรเปิดได้เพียงเพราะเดารหัสเอกสารถูก ข้อกำหนดจึงต้องระบุทั้งบทบาท ทีม และความเป็นเจ้าของ เมื่อย้ายทีม ระบบต้องมีวิธีถอนสิทธิ์เดิมตามนโยบาย

ข้อผิดพลาดที่ควรทดสอบ

ทดสอบบัญชีที่ไม่ Login บัญชีที่ Login แต่ไม่มีสิทธิ์ บัญชีที่มีบทบาทถูกแต่ขอรายการข้ามองค์กร และบัญชีที่ถูกปิดหลังเคยมี Session อยู่ ใช้หลักปฏิเสธเป็นค่าเริ่มต้นและให้สิทธิ์เฉพาะที่กำหนด OWASP แนะนำให้ตรวจสิทธิ์ทุกคำขอและทุกทรัพยากร ไม่เชื่อเพียงการซ่อนตัวเลือกใน UI

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

ทำตารางผู้ใช้–ทรัพยากร–การกระทำ–ขอบเขต พร้อมกรณีผ่านและถูกปฏิเสธอย่างละหนึ่งกรณี ระบุว่าระบบยืนยันตัวตนอย่างไรและตรวจสิทธิ์จุดใด หากยังไม่ได้ทดสอบ Server จริง ให้เรียกว่าแบบออกแบบสิทธิ์ ไม่อ้างว่าระบบปลอดภัยแล้ว

อ่าน RBAC และ Login กับสิทธิ์ผู้ใช้เว็บแอป หรือดู บริการ Web Application

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

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

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

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

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

• OWASP: Authentication Cheat Sheet — หลักยืนยันตัวตน
• OWASP: Authorization Cheat Sheet — การตรวจสิทธิ์และขอบเขตข้อมูล