เลิกขอสิทธิ์แบบ all-or-nothing: ออกแบบหน้าจอยินยอม OAuth ให้ผู้ใช้เลือกได้ตามงาน

หน้าจอขอสิทธิ์ OAuth ส่วนใหญ่บังคับให้ผู้ใช้เลือกระหว่างยอมทั้งหมดหรือไม่ยอมเลย ซึ่งกลายเป็นปัญหาหนักขึ้นในยุคที่ AI agent ต้องขอสิทธิ์กว้าง บทความนี้สรุปแนวคิด optional scopes ที่ Cloudflare เพิ่งเปิดใช้ พร้อมสิ่งที่นักพัฒนาต้องแก้ในโค้ดฝั่งแอปเพื่อรองรับการอนุมัติเพียงบางส่วน

ปัญหาของหน้าจอยินยอมแบบยอมทั้งหมดหรือไม่ยอมเลย

ในระบบ OAuth แบบดั้งเดิม ผู้พัฒนาแอปเป็นฝ่ายกำหนดว่าจะขอสิทธิ์ (scope) อะไรบ้าง ส่วนผู้ใช้มีทางเลือกแค่สองทางคือกดอนุญาตทั้งชุดหรือปฏิเสธไปเลย ถ้าแอปขอสิทธิ์มากเกินกว่าที่ผู้ใช้สบายใจ ผลลัพธ์มักจบลงที่การกดอนุญาตทั้งที่ไม่เต็มใจ เพราะไม่มีทางเลือกอื่นที่ยังใช้งานแอปต่อได้

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

optional scopes ทำงานอย่างไร

แนวทางที่ Cloudflare เลือกใช้คือเปิดให้ผู้พัฒนาทำเครื่องหมายว่าสิทธิ์ตัวใดเป็นสิทธิ์ที่ไม่บังคับ โดยแยกรายการ optional_scopes ออกจากรายการ scopes ปกติในขั้นตอนตั้งค่า client เมื่อถึงหน้าจอยินยอม ผู้ใช้จะสามารถติ๊กออกเฉพาะสิทธิ์ที่เป็น optional ได้ แล้วระบบจะออกโทเคนที่มีเฉพาะสิทธิ์ที่ผู้ใช้ยินยอมจริงเท่านั้น

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

สิ่งที่ต้องแก้ในโค้ดฝั่งแอป

การเปลี่ยนแปลงที่สำคัญที่สุดสำหรับนักพัฒนาคือ ห้ามสมมติว่าโทเคนที่ได้กลับมามีสิทธิ์ครบตามที่ขอ หลังแลกเปลี่ยน authorization code เป็น access token แล้ว แอปต้องอ่านชุดสิทธิ์ที่ได้รับจริงจากผลลัพธ์เสมอ แล้วปรับพฤติกรรมตามนั้น

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

ทำไมเรื่องนี้สำคัญกับยุค AI agent

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

นำไปใช้กับระบบของคุณอย่างไร

ถ้าทีมของคุณเป็นผู้ให้บริการ OAuth เอง สิ่งที่ควรทำคือแยกสิทธิ์ให้ละเอียดพอที่จะทำเป็น optional ได้ อย่ารวมทุกอย่างไว้ในสิทธิ์เดียวแบบ read/write ทั้งบัญชี และควรออกแบบหน้าจอยินยอมให้อธิบายด้วยภาษาคนว่าแต่ละสิทธิ์ทำให้แอปทำอะไรได้จริง ไม่ใช่โชว์ชื่อ scope ดิบ ๆ

ส่วนทีมที่เป็นฝั่งผู้เรียกใช้ ควรขอสิทธิ์เท่าที่จำเป็นต่องานในขณะนั้นและใช้การขอสิทธิ์แบบเพิ่มทีหลัง (incremental authorization) แทนการขอทุกอย่างตั้งแต่ครั้งแรก แนวทางนี้ทั้งเพิ่มอัตราการอนุมัติและลดความเสียหายหากโทเคนหลุด ซึ่งสอดคล้องกับหลักสิทธิ์น้อยที่สุดที่ผู้ตรวจสอบตาม พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคลมักถามหา