چطور نگذاریم انقضای OAuth همهٔ AI Agentها را از کار بیندازد؟

اگر چند Agent به یک مجوز مشترک تکیه کنند، انقضای یک توکن می‌تواند کل خط کار را بی‌صدا متوقف کند. این راهنما حلقهٔ پایش، هشدار و بازیابی را مرحله‌به‌مرحله می‌سازد.

یک خرابی کوچک چگونه به توقف جمعی تبدیل می‌شود؟

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

در یکی از اجراهای داخلی TekeraLab همین الگو دیده شد: یک مجوز منقضی شد و چند Agent هم‌زمان از کار افتادند. جزئیات محرمانه کنار گذاشته شده، اما درس عملی روشن است: credential مشترک یک وابستگی زیرساختی است و باید مثل پایگاه داده یا صف پیام پایش شود.

چرا تکیه بر refresh خودکار کافی نیست؟

Refresh خودکار لازم است، اما تضمین نیست. سیاست رسمی Google می‌گوید refresh token ممکن است با لغو دسترسی کاربر، فرایندهای حفاظتی یا انقضا نامعتبر شود. بنابراین طراحی درست نباید بر فرض «این توکن همیشه برمی‌گردد» بنا شود.

تفاوت مهم بین خطای موقت و خطای نیازمند مداخله است. timeout شبکه می‌تواند retry محدود بگیرد؛ اما invalid_grant، لغو scope یا شکست مکرر refresh باید چرخهٔ retry را متوقف و یک هشدار قابل اقدام بسازد. retry بی‌نهایت فقط لاگ بیشتری تولید می‌کند و زمان بازیابی را عقب می‌اندازد.

حلقهٔ چهارمرحله‌ای کنترل مجوز

۱) Monitor: برای هر اتصال، زمان آخرین موفقیت، زمان آخرین refresh، scopeهای مورد نیاز و تعداد خطاهای احراز هویت ثبت شود. سلامت اتصال باید جدا از سلامت Agent دیده شود.

۲) Refresh: پیش از رسیدن به مرز انقضا، refresh انجام شود؛ اما خروجی آن با یک درخواست کم‌خطر واقعی آزمایش شود. دریافت یک token جدید بدون اثبات کارکرد API کافی نیست.

۳) Alert: هشدار باید بگوید کدام اتصال، چند Agent و کدام وظایف تحت تأثیرند و اقدام بعدی چیست. پیام «Something went wrong» برای عملیات مفید نیست.

۴) Recover: مسیر احراز هویت دوباره باید مشخص، محدود و قابل ممیزی باشد. انسان مجوز را بازسازی می‌کند، سیستم اتصال را تست می‌کند و سپس Agentها به‌ترتیب و نه هم‌زمان آزاد می‌شوند.

سه گیت که جلوی سرایت خرابی را می‌گیرند

گیت اول، پیش از شروع هر کار وابسته، اتصال را با یک health check کم‌هزینه می‌سنجد. گیت دوم، circuit breaker است: اگر خطای مشترک از آستانه گذشت، اجرای همهٔ Agentهای وابسته متوقف می‌شود تا صف بی‌هدف رشد نکند. گیت سوم، recovery verification است: بعد از احراز هویت دوباره، یک نمونهٔ واقعی و فقط‌خواندنی اجرا می‌شود و تنها در صورت موفقیت صف باز می‌شود.

این سه گیت زمان تشخیص، دامنهٔ خرابی و خطر بازگشت زودهنگام را کاهش می‌دهند. هدف حذف کامل خطا نیست؛ هدف این است که یک خطای قابل انتظار به خاموشی ناشناخته تبدیل نشود.

چک‌لیست اجرایی

برای هر credential یک مالک، سرویس‌های وابسته، روش تست، آستانهٔ هشدار و مسیر بازیابی ثبت کنید. secret را هرگز داخل prompt یا لاگ نگذارید. زمان refresh و نتیجهٔ health check را ثبت کنید، اما مقدار token را نه. یک تمرین بازیابی دوره‌ای انجام دهید تا معلوم شود راهنمای نوشته‌شده واقعاً کار می‌کند.

اگر امروز فقط یک کار انجام می‌دهید، فهرست وابستگی بسازید: هر مجوز به کدام Agentها وصل است؟ همین نقشه هنگام حادثه مشخص می‌کند یک خطای احراز هویت محلی است یا کل خط کار را تهدید می‌کند.

پاسخ‌های کوتاه

آیا refresh token همیشه تا زمان مشخصی معتبر می‌ماند؟

نه. سرویس‌دهنده می‌تواند آن را به‌دلیل لغو دسترسی، سیاست امنیتی یا انقضا نامعتبر کند؛ سیستم باید این حالت را یک وضعیت عادی و قابل بازیابی بداند.

چه زمانی باید به انسان هشدار بدهیم؟

وقتی refresh خودکار شکست می‌خورد، چند Agent هم‌زمان خطای احراز هویت می‌گیرند یا زمان باقی‌مانده تا انقضا از آستانهٔ تعیین‌شده کمتر می‌شود.

جمع‌بندی

مجوز OAuth یک تنظیم دائمی نیست؛ یک وابستگی زنده با چرخهٔ عمر و احتمال شکست است. پایش، refresh، هشدار و بازیابی را به یک حلقهٔ آزموده‌شده تبدیل کنید تا انقضای یک credential به توقف همهٔ Agentها تبدیل نشود.

منبع رسمی

• سیاست‌های OAuth 2.0 گوگل