‏OAuth و حفره‌ای که RFC 9207 بهش نرسید

تو این مقاله از تیم WorkOS اومده که بین باگ‌های اخیر OAuth، ایراد token exchange تو n8n از بقیه ساختاری‌تر و جالب‌تره، چون یه شکل کلاسیک و اسم‌دار داره: حملهٔ mix-up. نویسنده می‌گه استانداردی که قرار بود سال‌ها پیش این مشکل رو ببنده وجود داره و کار هم می‌کنه، ولی هیچ‌وقت به فلویی که n8n ازش استفاده می‌کرد گسترش پیدا نکرد.

حملهٔ mix-up کلاینت‌هایی رو هدف می‌گیره که با بیشتر از یک authorization server حرف می‌زنن — مثلاً اپی که چند تا IdP برای ورود داره، یا یه ایجنت که به چند سرور MCP وصله. مهاجم دو فلوی authorization رو هم‌زمان راه می‌ندازه، یکی روی سرور واقعی و یکی روی سروری که خودش کنترلش می‌کنه، و کلاینت قاطی می‌کنه که کدوم پاسخ مال کدوم سروره. ریشهٔ ماجرا اینه که پاسخ استاندارد اصلاً نمی‌گه از طرف کی اومده؛ کد و state از هر سروری بیان شکل‌شون یکیه.

RFC 9207 که سال ۲۰۲۲ منتشر شد یه پارامتر به پاسخ اضافه می‌کنه: iss که شناسهٔ صادرکننده رو حمل می‌کنه. کلاینت باید این مقدار رو با صادرکننده‌ای که برای همون فلو انتظار داشته مقایسهٔ رشته‌ای کنه و هر عدم تطابقی رو رد کنه. این پارامتر عمداً امضای رمزنگاری جدا نداره، چون به گفتهٔ نویسندگان RFC مهاجمی که بتونه پاسخ ریدایرکت رو دستکاری کنه از اول به authorization code دسترسی داره و اصلاً به mix-up نیازی نداره.

نصفهٔ دومِ این قرارداد همون چیزیه که معمولاً فراموش می‌شه. RFC فقط نمی‌گه «اگه iss بود چکش کن»؛ می‌گه اگه کلاینت بدونه سرور از iss پشتیبانی می‌کنه، باید پاسخِ بدونِ iss رو هم رد کنه. وگرنه مهاجم کافیه پارامتر رو حذف کنه تا کلاینت برگرده به همون ابهامی که این RFC برای رفعش نوشته شده. نویسنده می‌گه بعد از چهار سال هنوز خیلی از کتابخونه‌های OAuth این چک رو به‌صورت پیش‌فرض انجام نمی‌دن.

نکتهٔ اصلی مقاله اینه که RFC 9207 فقط پاسخ authorization رو وصله می‌کنه و این پاسخ فقط تو فلوهای ریدایرکتی وجود داره. توی token exchange یعنی RFC 8693 اصلاً مرورگر و ریدایرکتی در کار نیست؛ یه طرف مستقیماً subject_token رو به اندپوینت توکن می‌ده و توکن جدید می‌گیره. پس پیامی نیست که iss بهش بچسبه و مسئولیت می‌افته گردن منطق اعتبارسنجی خودِ اندپوینت، که هیچ چیزی تو اسپک مجبورش نمی‌کنه درست انجامش بده.

چیزی که تو عمل ساخته می‌شه معمولاً یه مدل اعتماد تخته: یه استخر از کلیدهای مورد اعتماد که توکن ورودی با همه‌شون سنجیده می‌شه، بدون اینکه اول بر اساس صادرکننده تفکیک شده باشه. بعدش از کلیم sub برای پیدا کردن حساب استفاده می‌شه، اونم تو یه فضای نام که به صادرکننده محدود نشده. تو CVE-2026-59208، n8n تأیید کرد امضای توکن با یه کلید مورد اعتماد جوره، ولی هیچ‌وقت چک نکرد اون کلید مال همون صادرکننده‌ای هست که sub قراره ازش اومده باشه.

نویسنده می‌گه RFC 8693 تنها موردش نیست؛ گرنت‌های JWT bearer یعنی RFC 7523 و SAML bearer یعنی RFC 7522 هم دقیقاً همین شکل رو دارن و هیچ‌کدوم گره‌خوردگی «کلید به صادرکننده» رو مجانی بهت نمی‌دن. به‌خصوص حالا که معماری‌های ایجنتی و MCP دارن همون کلاینت‌های چندسروری می‌شن که RFC 9207 براشون نوشته شده، این چک از یه حالت لبه‌ای تبدیل شده به یه بررسی درجه‌یک.

نکات کلیدی:

• حملهٔ mix-up وقتی معنا داره که کلاینت با بیش از یک authorization server کار کنه
• پاسخ استاندارد authorization نمی‌گه از کدوم سرور اومده؛ iss تو RFC 9207 دقیقاً همینو اضافه می‌کنه
• پاسخِ بدونِ iss هم باید رد شه، وقتی می‌دونی سرور پشتیبانیش می‌کنه
• توی token exchange و گرنت‌های bearer، کلیدهای مورد اعتماد رو به تفکیک صادرکننده نگه دار، نه تو یه استخر تخت
• جست‌وجوی حساب کاربری رو به فضای نام همون صادرکنندهٔ تأییدشده محدود کن؛ همین یه چک جلوی CVE-2026-59208 رو می‌گرفت