צלילה לעומק של AgentAuth: הבנת UUIDs בעלי אימות עצמי
להראות סוכן AI מסך התחברות זה פשוט לא הגיוני.
סוכנים לא יושבים מול דפדפנים. הם מבצעים קריאות לכלים (tool calls) בשלוש לפנות בבוקר. הם רצים במקביל. שיטות מסורתיות כמו OAuth או עוגיות סשן (session cookies) נכשלות כי הן מניחות שנוכח אדם שיקליק על כפתורי אישור.
AgentAuth פותרת זאת באמצעות דבר אחד: UUID.
היא אינה משתמשת בסשנים או בתשתית נוספת. היא משתמשת בקריפטוגרפיה של מפתח ציבורי כדי לאחד זהות ואימות לערך יחיד.
כך זה עובד:
• ה-Token: מפתח פרטי (secp256k1). הוא נשאר סודי במחשב שלך. • ה-Address: ערך ציבורי הנגזר מה-token. • ה-ID: UUID יציב שנבנה מה-address.
הזרימה היא חד-כיוונית. ניתן לעבור מ-Token ל-ID, אך לא ניתן לחזור מ-ID ל-Token. זה הופך את ה-ID לזהות יציבה.
כיצד זה מונע התחזות?
למרות שה-ID הוא ציבורי, תוקף לא יכול להשתמש בו. כל בקשה כוללת חתימה דיגיטלית.
- הלקוח חותם על ה-payload של הבקשה באמצעות ה-Token הפרטי.
- השרת מקבל את החתימה ואת ה-Address המוצהר.
- השרת משתמש בחתימה כדי לשחזר את ה-Address.
- אם ה-Address המשוחזר תואם ל-Address המוצהר, הבקשה תקפה.
תהליך זה הוא stateless. השרת אינו זקוק למסד נתונים של סשנים פעילים כדי לאמת את המשתמש. הוא זקוק רק למתמטיקה.
כדי למנוע התקפות replay, AgentAuth משתמשת בחלון זמן של 60 שניות (timestamp). אם תוקף גונב בקשה חתומה, יש לו דקה אחת בלבד להשתמש בה לפני שהחתימה תהפוך ללא תקפה.
הבחנה חשובה: AgentAuth נועדה לאימות (Authentication - מי אתה?). היא אינה נועדה להרשאה (Authorization - מה מותר לך לעשות?).
אל תבלבלו בין זה לבין מפרט ה-MCP OAuth 2.1 הרשמי.
- השתמשו ב-AgentAuth כאשר אתם שולטים בשני הקצוות ורוצים IDs יציבים למעקב שימוש או להגבלת רמות (tier gating).
- השתמשו ב-MCP OAuth 2.1 כאשר עליכם להאציל הרשאות ל-APIs של צד שלישי בשם אדם.
השניים יכולים לעבוד יחד. השתמשו ב-AgentAuth כדי לזהות את הסוכן וב-OAuth כדי לנהל את הגישה שלו לנתונים חיצוניים.
AgentAuth הופכת מפתח פרטי לזהות יציבה הניתנת לאימות, ללא צורך במסך התחברות אחד.
Optional learning community: https://t.me/GyaanSetuAi