OAuth 2.0 برای عصر هوش مصنوعی کافی نیست
هوش مصنوعیخلاصهٔ کاملتر
OAuth 2.0 از وقتی که دیک هارت در سال ۲۰۱۲ اون رو نوشت، قلب سیستم احراز هویت وب شده. اپها باهاش به API دسترسی میگیرن، دکمههای «ورود با گوگل» بهش وابستهان، و میلیاردها درخواست روزانه ازش عبور میکنه. مشکل اینجاست که OAuth برای دنیایی طراحی شده که یه انسان پشت مرورگر نشسته، یه صفحه consent میبینه و کلیک میکنه. ایجنتهای هوش مصنوعی اما در شب کار میکنن، بلیط میخرن، فاکتور بررسی میکنن و پرداخت انجام میدن، بدون اینکه کسی «بله» بزنه.
مشکل فنی هم جدیه: در OAuth هر client_id فقط برای یه سرویس معنی داره. client_id شما در گوگل نزد گیتهاب هیچ هویتی نداره. ایجنتها اما در حین اجرا ابزارهاشون رو انتخاب میکنن و ممکنه دهها سرویس مختلف رو صدا بزنن. علاوه بر این، یه scope مثل mail.read هیچ فرقی بین «خلاصهسازی ایمیل» و «استخراج غیرمجاز اطلاعات» نمیذاره. پروتکل کور است.
MCP آنتروپیک که در سال ۲۰۲۴ منتشر شد، یه رابط استاندارد بین ایجنت و ابزارهاش تعریف کرد. نسخه مارس ۲۰۲۵ این پروتکل احراز هویت رو با OAuth 2.1 استاندارد کرد، PKCE رو اجباری کرد و مکانیزم discovery و ثبت پویای کلاینت رو اضافه کرد. برای اینکه ایجنت بفهمه سرور مجوزدهی کجاست، RFC 9728 یه آدرس استاندارد تعریف کرده:
GET /.well-known/oauth-protected-resource
این endpoint به ایجنت میگه کجا باید بره تا OAuth exchange رو شروع کنه. Cloudflare Access هم در آوریل ۲۰۲۶ این discovery flow رو به صورت native پشتیبانی کرد.
اما MCP یه مشکل حل نکرد: ارتباط بین ایجنتها. وقتی یه ایجنت orchestrator باید کاری رو به یه ایجنت پرداخت یا تحقیق واگذار کنه، MCP هیچ پروتکل استانداردی برای این handoff نداره. اینجاست که A2A گوگل وارد میدان شد. A2A در آوریل ۲۰۲۵ با پشتیبانی بیش از ۵۰ شرکت بزرگ از جمله Salesforce و SAP منتشر شد و روی استانداردهای وب موجود بنا شده. ایجنتها با «Agent Card» قابلیتهاشون رو معرفی میکنن و با OAuth 2.0 احراز هویت میکنن. گوگل این پروتکل رو در ژوئن ۲۰۲۵ به Linux Foundation اهدا کرد و تا آوریل ۲۰۲۶ بیش از ۱۵۰ سازمان بهش پیوستن.
ولی یه مشکل عمیقتر هنوز باقیه: bearer tokenها. اگه توکنی رو داشته باشی، میتونی ازش استفاده کنی. در زنجیرههای چندایجنتی، یه sub-agent میتونه توکن دریافتی رو با تمام سطح دسترسی اصلیاش دوباره استفاده کنه. هیچ مکانیزمی وجود نداره که مطمئن بشی هر گام زنجیره فقط میتونه دسترسی رو کاهش بده، نه افزایش.
AAuth پروژهای از خود دیک هارت — نویسنده OAuth 2.0 — است که داره از اول این مسئله رو حل میکنه. در AAuth هر ایجنت یه هویت مستقل با کلید رمزنگاری داره، هر HTTP request باید با private key ایجنت امضا بشه و زنجیره واگذاری دسترسی به جای اینکه از لاگها استنتاج بشه، صریح و قابل تأیید است. توکن بدون private key متناظر قابل replay نیست.
رویکرد دیگهای که Biscuits و Macaroons دارن اینه که ایجنت دریافتکننده میتونه توکن رو قبل از پاس دادن به پاییندست رمزنگارانه محدود کنه، و این محدودیت توسط هیچکسی قابل حذف نیست:
// مفهوم Biscuit: ایجنت میتونه scope رو فقط کاهش بده
token.attenuate("scope = read-only")
// هیچکس در پاییندست نمیتونه این محدودیت رو بردare
در سطح استانداردسازی بینالمللی، IETF زیر گروه WIMSE (Workload Identity in Multi-System Environments) داره روی این مسئله کار میکنه. در مارس ۲۰۲۶ پیشنویس AIMS منتشر شد که WIMSE، SPIFFE و OAuth 2.0 رو ترکیب میکنه. SPIFFE مسئول چرخش خودکار credential و اتصال هویت به محیط اجراست. Auth0 هم در نوامبر ۲۰۲۵ از Client-Initiated Backchannel Authentication (CIBA) برای ایجنتها رونمایی کرد که به ایجنت اجازه میده اجرا رو متوقف کنه، تأیید کاربر رو از طریق ایمیل یا اپ بگیره و بعد از تأیید به اجرا ادامه بده.
نکات کلیدی:
- OAuth 2.0 برای کاربران انسانی طراحی شده و با ایجنتهایی که در runtime تصمیم میگیرن سازگار نیست
- MCP آنتروپیک ارتباط ایجنت-ابزار رو با OAuth 2.1 و PKCE استاندارد کرده
- A2A گوگل ارتباط ایجنت-ایجنت رو با Agent Card و OAuth هندل میکنه و حالا زیر چتر Linux Foundation است
- bearer tokenها در زنجیرههای چندایجنتی خطرناکن چون نمیشه دسترسی رو رمزنگارانه محدود کرد
- AAuth از دیک هارت رویکرد جدیدی با امضای هر درخواست و هویت مستقل ایجنت پیشنهاد میده
- Biscuits و Macaroons scope attenuation رمزنگارانه بدون نیاز به roundtrip به authorization server رو ممکن میکنن
- WIMSE و SPIFFE در حال استاندارد کردن هویت workload در محیطهای چندسیستمی هستن
