• auth
  • agent
  • agent auth

การตรวจสอบสิทธิ์ของ AI: กรณีการใช้งานและความต้องการทางด้านอัตลักษณ์

ปี 2025 คือปีของ AI เมื่อ LLMs และประสบการณ์จากตัวแทนพัฒนา ความท้าทายเกี่ยวกับการตรวจสอบสิทธิ์และการอนุญาตใหม่ก็เกิดขึ้น บทความนี้สะท้อนถึงการทำงานร่วมกันของ AI agent โดยเน้นสถานการณ์ด้านความปลอดภัยและการตรวจสอบสิทธิ์ที่สำคัญ

Guamian
Guamian
Product & Design

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้
เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ
เริ่มต้นใช้งาน
Product screenshot

ปี 2025 กำลังเป็นปีที่ AI ก้าวสู่เป็นที่ยอมรับ ด้วยการเติบโตอย่างรวดเร็วของ LLMs และประสบการณ์จากตัวแทน พวกเรามักถูกถาม: ทำอย่างไรถึงจะยอมรับยุคใหม่นี้ได้? แล้วกรณีการใช้งานใหม่ๆ สำหรับการตรวจสอบสิทธิ์และการอนุญาตของ AI agent มีอะไรบ้าง? ในบทความนี้ เราจะสำรวจประสบการณ์ของตัวแทนทั่วไปและชี้ให้เห็นสถานการณ์ด้านความปลอดภัยและการตรวจสอบสิทธิ์ตามทาง

ประสบการณ์การตรวจสอบสิทธิ์ของตัวแทน ChatGPT

ฉันได้ซื้อ ChatGPT Operator และสำรวจการทำงานทั่วไปบางอย่าง ตัวอย่างหนึ่งคือการจองที่พักในโตเกียว ประเทศญี่ปุ่น Operator ได้ทำให้การหาห้องที่เหมาะสมตามคำของฉันเป็นเรื่องง่ายมาก

ในระหว่างการชำระเงิน มันขอให้ฉันเข้าสู่ระบบแล้วส่งการควบคุมกลับมาที่ฉัน

airbnb-checkout.png ask-for-login.png sign-in-google.png enter-password.png

ประสบการณ์นี้ทำให้ฉันรู้สึกไม่สะดวกใจ ถึงแม้ว่าฉันจะมีการควบคุมและตัวแทนไม่สามารถเข้าสู่ระบบให้ฉันได้ แต่ฉันยังคงต้องใส่อีเมลและรหัสผ่านในเบราว์เซอร์ของ Operator นี่หมายความว่าหากคุณเข้าสู่อีเมล (หรือบริการใดๆ) ผ่าน Operator ข้อมูลการเข้าสู่ระบบของคุณจะถูกเก็บในคุกกี้

OpenAI’s Operator ระบุว่ามันไม่เคยเก็บข้อมูลการเข้าสู่ระบบของผู้ใช้และปฏิบัติตามมาตรฐานความเป็นส่วนตัว เช่น SOC II อย่างไรก็ตาม เมื่อตัวแทนของบุคคลที่สามมีการโต้ตอบกับบริการภายนอกในนามของคุณ ความเสี่ยงด้านความปลอดภัยจะเพิ่มขึ้นอย่างมาก

โดยทั่วไปแล้ว การให้การเข้าถึงบัญชีและข้อมูลการเข้าสู่ระบบของคุณแก่ตัวแทนโดยตรงเป็นความคิดที่ไม่ดี

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

เหมือนที่ X Threads กล่าวถึง

ข้อมูลการเข้าสู่ระบบถูกจัดการอย่างไร และมีความเสี่ยงด้านความปลอดภัยอะไรบ้าง?

ให้ตัวแทน AI ข้อมูลการเข้าสู่ระบบของคุณโดยตรง

ในวิธีนี้ AI ป้อนข้อมูลการเข้าสู่ระบบแบบข้อความธรรมดา (เช่น อีเมลและรหัสผ่าน) ในนามของคุณ ตัวอย่างเช่น ai agent อาจร้องขอรายละเอียดการเข้าสู่ระบบของคุณและใส่มันให้กับคุณ

อย่างไรก็ตาม วิธีนี้มีความเสี่ยงด้านความปลอดภัยเนื่องจากสามารถเปิดเผยข้อมูลสำคัญ หากการใช้งานเป็นสิ่งจำเป็น การผสานรวมกับผู้จัดการรหัสผ่านหรือระบบการจัดการความลับจะปลอดภัยกว่า นอกจากนี้ การจำกัดระยะเวลาที่ข้อมูลการเข้าสู่ระบบถูกจัดเก็บสามารถช่วยลดความเสี่ยงของการรั่วไหลได้

แทนที่จะเป็นข้อมูลการเข้าสู่ระบบแบบข้อความธรรมดา Personal Access Tokens (PATs) เสนอวิธีที่ปลอดภัยกว่าในการให้อำนาจโดยไม่ต้องใช้รหัสผ่านหรือการเข้าสู่ระบบแบบโต้ตอบ PAT useful มากสำหรับ CI/CD, scripts, และแอปพลิเคชันที่จำเป็นต้องเข้าถึงทรัพยากรแบบโปรแกรม ในการเพิ่มความปลอดภัย ควรจำกัดขอบเขตของ PAT, ตั้งเวลาหมดอายุ และรองรับการเพิกถอนเพื่อป้องกันการรั่วไหลและการขโมยบัญชี

การมอบอำนาจจากผู้ใช้ผ่าน OAuth

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

โดยสรุปแล้ว OAuth สามารถแก้ไขปัญหาการมอบอำนาจในการเข้าถึงอย่างปลอดภัยได้: ตัวอย่างเช่น คุณสามารถให้สิทธิ์แอปการเดินทางอ่าน Google Calendar ของคุณโดยไม่ต้องให้รหัสผ่าน Google ให้กับแอป ซึ่งทำได้โดยการให้ผู้ใช้ตรวจสอบสิทธิ์กับผู้ให้บริการข้อมูล (เช่น Google) แล้วจึงออกโทเค็นให้กับแอปของบุคคลที่สามแทนที่จะเปิดเผยข้อมูลการเข้าสู่ระบบของผู้ใช้

วิธีที่ดีกว่าในการจัดการสถานการณ์นี้ คือการอนุญาต ChatGPT Operator (หรือ agent ใดๆ) เพื่ออ่านและเขียนบน Airbnb โดยไม่ต้องแชร์รหัสผ่านหรือข้อมูลการเข้าสู่ระบบของคุณแทนการให้ Operator เข้าสู่ระบบโดยตรง คุณสามารถมอบอำนาจผ่านกระบวนการให้สิทธิ์ที่ปลอดภัย

ในมุมมองของฉัน หาก OpenAI Operator ต้องการเสริมสร้างความไว้วางใจและความปลอดภัยทางอัตลักษณ์ มีวิธีหลายอย่างที่สามารถทำได้

  1. ย้ายกระบวนการเข้าสู่ระบบออกไปจาก Operator: การจัดการการเข้าสู่ระบบผู้ใช้นอก ChatGPT Operator นั่นหมายความว่าคุณอาจคลิกปุ่ม “เข้าสู่ระบบด้วย [บริการ]” และถูกเปลี่ยนเส้นทางไปยังหน้าการเข้าสู่ระบบที่ปลอดภัยของบริการเพื่อยืนยันตัวตนของคุณอย่างสมบูรณ์นอก chat หรือ ChatGPT Operator ตัวอย่างเช่น หากมีปลั๊กอินของ Airbnb คุณจะถูกส่งไปยังเว็บไซต์ Airbnb เพื่อใส่ข้อมูลการเข้าสู่ระบบและอนุญาต ChatGPT และจากนั้นปลั๊กอินจะได้รับโทเค็น ChatGPT จะได้รับโทเค็นหรือคีย์การเข้าถึงชั่วคราวเท่านั้น ที่ให้การเข้าถึงที่จำกัด (เช่น “อ่านเส้นทางการเดินทางของฉัน”) แทนที่การเห็นรหัสผ่านของคุณจริงๆ

  2. ให้ผู้ใช้เสร็จสิ้นกระบวนการยินยอมก่อนที่ AI agent จะดำเนินงานใดๆ วิถีนี้คล้ายกับวิธีที่หลายผลิตภัณฑ์จัดการกับการผสานรวม ตลาด และบริการที่เชื่อมต่อ

    notion-marketplace หน้าเชื่อมต่อของ Notion

    นี่คือตัวอย่างอีกกรณีหนึ่ง เช่น การผสานรวมตลาดของ Slack กับ Notion Slack ขอสิทธิ์การเข้าถึงพื้นที่ทำงาน specific ของ Notion ซึ่งสามารถอ่านบทความและแสดงในช่องทางของ Slack ของคุณ

consent-1.png consent-2.png consent-notion

ในขณะเดียวกัน Slack ยังให้หน้าการยินยอมเพื่อให้ Notion สามารถเข้าถึงพื้นที่ทำงานได้ในกระบวนการนี้

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

การยืนยันตัวตนเพิ่มขึ้นสำหรับการดำเนินการที่อ่อนไหว

AI agent สามารถจัดการกับงานประจำได้เองและอัตโนมัติได้ แต่สำหรับการกระทำที่มีความเสี่ยงสูง จำเป็นต้องมีการตรวจสอบเพิ่มเติมเพื่อให้มั่นใจความปลอดภัย — เช่น การส่งเงินหรือการปรับเปลี่ยนการตั้งค่าความปลอดภัย — ผู้ใช้ต้องยืนยันอัตลักษณ์ของตนผ่าน การยืนยันตัวตนหลายปัจจัย (MFA) สิ่งนี้สามารถทำได้ผ่านการแจ้งเตือนแบบพุช, รหัสผ่านครั้งเดียว (OTPs) หรือการยืนยันด้วยการวัดชีวภาพ

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

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

อัตลักษณ์เชื่อมโยงและการเข้าสู่ระบบครั้งเดียว (SSO) สำหรับระบบหลายตัวแทน

ในระบบหลายตัวแทนสำหรับองค์กร AI agent มักจะต้องทำงานข้ามแพลตฟอร์มต่างๆ เพื่อให้การตรวจสอบสิทธิ์เป็นไปอย่างราบรื่น ผู้ใช้ยืนยันตัวตนหนึ่งครั้งผ่านผู้ให้บริการอัตลักษณ์ (IdP) เช่น Okta, Azure AD, หรือ Google Workspace ตัวแทนจะเข้าสู่ระบบโดยใช้ SAML, OpenID Connect (OIDC) โดยมีการจัดการการเข้าถึงผ่าน บทบาท (RBAC) หรือ การควบคุมการเข้าถึงตามแอตทริบิวต์ (ABAC)

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

การจัดการขอบเขตและการอนุญาต

เนื่องจาก Operators และ Agents สามารถทำงานในนามของผู้ใช้ การให้ผู้มีมนุษฐานสิทธิ์เพียงพอและการกำหนดสิทธิ์ของ AI agent อย่างละเอียดรอบคอบเป็นสิ่งสำคัญ หลักการสองข้อที่ควรปฏิบัติคือ:

  1. สิทธิ์น้อยที่สุด – ให้สิทธิ์ที่จำเป็นสำหรับการงานเท่านั้น
  2. การเข้าถึงที่มีระยะเวลาจำกัด – จำกัดระยะเวลาการเข้าถึงเพื่อลดความเสี่ยงทางความปลอดภัย

การควบคุมการเข้าถึงแบบอิงตามบทบาท (RBAC) ช่วยจัดการขอบเขตของ agent โดยการกำหนดบทบาทเฉพาะสำหรับบางงาน สำหรับการควบคุมที่ละเอียดกว่า การควบคุมการเข้าถึงแบบอิงตามแอตทริบิวต์ (ABAC) ช่วยให้สามารถจัดการสิทธิ์ที่เข้าใจตามบริบทและพลวัต มั่นใจว่า AI agent สามารถเข้าถึงข้อมูลที่จำเป็นเฉพาะเมื่อพวกเขาต้องการ

เชื่อมต่อเซิร์ฟเวอร์ MCP กับ Auth

MCP กำลังเป็นที่นิยมมากขึ้นในการเพิ่มประสิทธิภาพของ AI agents โดยให้ข้อมูลที่มีบริบทมากขึ้น ปรับปรุงประสิทธิภาพและประสบการณ์ของผู้ใช้

เหตุใดเซิร์ฟเวอร์ MCP จึงเกี่ยวข้องกับการรับรองสิทธิ์ และเหตุใดจึงสำคัญ?

เราเขียนบทความมาก่อนหน้านี้เพื่อช่วยให้คุณเข้าใจว่า เซิร์ฟเวอร์ MCP คืออะไร.

เซิร์ฟเวอร์ MCP เป็นส่วนสำคัญของ Model Context Protocol ซึ่งทำหน้าที่เป็นสะพานระหว่าง AI models และแหล่งข้อมูลภายนอก มันช่วยให้การทำข้อมูลเรียลไทม์และการดึงข้อมูลแบบเรียลไทม์จากบริการเช่น Slack, Gmail, และ Google Calendar โดยการสร้างเซิร์ฟเวอร์ MCP คุณสามารถเชื่อมต่อบริการระยะไกลเหล่านี้กับ LLMs เพิ่มประสิทธิภาพ AI-powered applications ของคุณด้วยข้อมูลที่เป็นบริบทและการดำเนินงานอัจฉริยภาพ

แตกต่างจาก ระบบการสร้างโดยการดึงข้อมูล (Retrieval-Augmented Generation, RAG) ซึ่งต้องการการสร้าง embeddings และการจัดเก็บเอกสารในฐานข้อมูลเวกเตอร์ เซิร์ฟเวอร์ MCP เข้าถึงข้อมูลได้โดยตรงโดยไม่ต้องมีการจัดทำดัชนีข้อมูลล่วงหน้า นั่นหมายความว่าข้อมูลไม่เพียงแต่แม่นยำและทันสมัยมากขึ้นแต่ยังผสานเข้ากับภาระการคำนวณต่ำกว่าและไม่ต้องเสียสละความปลอดภัย

mcp-overview อ้างอิง: https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained

สำหรับ AI agents ที่ใช้เซิร์ฟเวอร์ MCP จะเกิดการปฏิสัมพันธ์หลายรูปแบบระหว่าง เซิร์ฟเวอร์ MCP, LLM, agent, และ user

ในโลกที่ขับเคลื่อนโดย AI วันนี้ ที่ตัวแทนจัดการงานหลายรูปแบบข้ามบริการ การรวมพวกเขากับเซิร์ฟเวอร์ MCP หลายที่กำลังมีความต้องการมากขึ้น

การตรวจสอบสิทธิ์ของ agent กำลังปรากฏ — ผลิตภัณฑ์ของคุณควรปรับตัว

ตัวอย่างที่ดีคือ Composio.dev แพลตฟอร์มการรวมที่มุ่งเน้นนักพัฒนาที่ง่ายต่อการเชื่อมต่อ ai agents และ LLMs กับแอปและบริการภายนอก ตั้งชื่อว่า “รับรองสิทธิ์สำหรับ ai agents ที่การปฏิบัติงานในนามของผู้ใช้” ซึ่งโดยพื้นฐานแล้วมีการให้บริการเซิร์ฟเวอร์ MCP (ตัวเชื่อมต่อ) ที่สามารถผสานรวมได้อย่างง่ายดายกับผลิตภัณฑ์ที่ขับเคลื่อนโดย AI

ในฐานะคนที่อยู่ในพื้นที่ของการรับรองสิทธิ์ แต่ในความเป็นจริง มันเป็นเพียงส่วนเล็กๆ ของสนาม CIAM (Customer Identity and Access Management) ที่กว้างกว่า สิ่งที่พวกเขาสร้างขึ้นจริงแล้วเป็นการรวมเซิร์ฟเวอร์ MCP (เชื่อมต่อ) — มีประโยชน์แต่เพียงเศษเสี้ยวของสิ่งที่ CIAM solutions ที่สมบูรณ์ประกอบด้วย

จากตัวอย่างก่อนหน้า ถ้าเราพิจารณา Google Drive (บริการระยะไกล) เป็นเซิร์ฟเวอร์ MCP แทนที่จะเป็น Airbnb มันกลายเป็นมากกว่าการผสานรวมของบุคคลที่สาม — หนนี้ทำหน้าที่เป็นแหล่งข้อมูลภายนอก ที่ให้ agent สามารถเข้าถึงข้อมูลทั้งที่มีบริบท ปฏิสัมพันธ์กับ LLM และอาจได้การอนุญาตให้สร้าง อ่าน อัปเดต และลบ (CRUD) ไฟล์

อย่างไรก็ตาม ความต้องการหลักในด้านการตรวจสอบสิทธิ์และการอนุญาตยังคงเหมือนเดิม

ใช้ Logto เพื่อจัดการการตรวจสอบสิทธิ์สำหรับผลิตภัณฑ์ผู้จัดจำหน่าย

Logto คือโซลูชัน CIAM ที่หลากหลายที่สนับสนุนผลิตภัณฑ์ SaaS และผลิตภัณฑ์ ai agent ทำให้การตรวจสอบสิทธิ์และการอนุญาตเป็นไปอย่างราบรื่น นี่คือเหตุผล:

  1. การจัดการการตรวจสอบสิทธิ์สำหรับผลิตภัณฑ์ ai agent – Logto สนับสนุน OAuth 2.0, SAML, คีย์ API, Personal Access Tokens, และ JWT ช่วยให้การเชื่อมต่อกับเซิร์ฟเวอร์ MCP หลายตัวเป็นเรื่องง่าย คุณสามารถสร้างเซิร์ฟเวอร์ MCP ของคุณเองและเชื่อมต่อกับ Logto ได้ด้วยแพลตฟอร์มที่เป็นมาตรฐานเปิด
  2. ความสามารถของผู้ให้บริการอัตลักษณ์ (IdP) – เมื่อผลิตภัณฑ์ของคุณมีผู้ใช้ที่กำหนดแล้ว Logto สามารถทำหน้าที่เป็น IdP ปรับบริการของคุณให้เป็นเซิร์ฟเวอร์ MCP และบูรณาการเข้าในระบบนิเวศ AI
  3. การอนุญาตขั้นสูง
    1. การควบคุมการเข้าถึงโดยใช้บทบาท (RBAC) สำหรับการจัดการบทบาทของผู้ใช้
    2. ABAC แบบกำหนดเองที่ใช้ JWT สำหรับการควบคุมการเข้าถึงที่ละเอียดอ่อนและเปลี่ยนแปลงได้
  4. ความปลอดภัยที่เพิ่มขึ้น – คุณลักษณะที่เช่น การตรวจสอบสิทธิ์หลายปัจจัย (MFA) และการตรวจสอบสิทธิ์เพิ่มเติมช่วยปกป้องการดำเนินการที่สำคัญและปรับปรุงความปลอดภัยของตัวแทน

มีคำถาม? ติดต่อ ทีมของเราเพื่อเรียนรู้ว่า Logto สามารถเพิ่มประสบการณ์ AI agent ของคุณและตอบสนองความต้องการทางด้านความปลอดภัยของคุณได้อย่างไร