فرض نشست می‌شکند
بیشتر سیستم‌های عامل بر پایه یک فرض ضمنی به‌ارث‌رسیده از اتوماسیون وب ساخته می‌شوند: اینکه عامل یک مرورگر سریع‌تر است. یک نشست کاربر را حمل می‌کند، همان کوکی‌ها را ارائه می‌دهد و به همان نقاط پایانی می‌رسد. این فرض تا زمانی که عامل فقط می‌خواند برقرار است. لحظه‌ای که عامل تلاش می‌کند تراکنش انجام دهد، شکست می‌خورد.
OAuth به آن سؤال پاسخ نمی‌دهد. یک access token توصیف‌کننده اعطایی از مالک منبع به یک اپلیکیشن کلاینت است. ثبت می‌کند که یک انسان به چه چیزی رضایت داده، نه اینکه کدام فرایند خودمختار در حال اعمال آن اعطا است. وقتی یک کاربر سه عامل دارد که علیه یک حساب اجرا می‌شوند، توکن در همه آن‌ها یکسان است. راهی برای ابطال یک عامل بدون ابطال بقیه وجود ندارد، و راهی برای نسبت‌دادن یک تراکنش خاص به یک کنشگر خاص پس از وقوع وجود ندارد.
شکاف، احراز هویت نیست. شکاف، هویت است.
آنچه یک هویت تفویض‌شده نیاز دارد
یک هویت ماشینی تفویض‌شده، اعتبارنامه‌ای است که توسط صفحه کنترل اصلی به یک عامل خاص صادر می‌شود و چرخه عمر خودش را حمل می‌کند. سه ویژگی دارد که یک نشست کاربر ندارد.
شناسه‌ای پایدار و جدا از اصل
عامل به مواد کلیدی خودش و برنامه چرخش خودش نیاز دارد. اصل — انسانی یا سازمانی که عامل به نمایندگی از او عمل می‌کند — ریشه اختیار باقی می‌ماند، اما عامل یک موضوع متمایز با یک کلید عمومی متمایز است. این جداسازی چیزی است که نسبت‌دادن را ممکن می‌کند: یک درخواست امضاشده عامل را نام می‌برد، و کلید عامل ادعا را بدون افشای اعتبارنامه‌های اصل اثبات می‌کند.
چرخش باید مستقل باشد. اگر کلید یک عامل به خطر بیفتد، چرخش آن نباید انسان را مجبور به احراز هویت مجدد در همه‌جا کند. برعکس، اگر اعتبارنامه‌های اصل بچرخند، اعطای تفویض‌شده عامل باید تحت یک مسیر صدور مجدد زنده بماند، نه با تغییر رمز عبور.
محدودسازی صریح دامنه
یک اعطای تفویض‌شده باید به‌طور همزمان در سه محور محدود باشد:
- به ازای هر طرف مقابل. عاملی که مجاز به خرید از یک فروشنده است، مجاز به خرید از فروشنده دیگری نیست. دامنه‌ها باید طرف متکی را نام ببرند، نه یک سطح API عمومی.
- به ازای هر کلاس تراکنش. خواندن، رزرو، تعهد و بازپرداخت اختیارات متفاوتی هستند. بیشتر عامل‌ها به دو مورد اول بسیار بیشتر از سومی نیاز دارند.
- به ازای هر پنجره زمانی. اعطایی که برای یک جریان پرداخت صادر می‌شود باید با پایان یافتن جریان منقضی شود، نه با انقضای کوکی نشست. اعطاهای کوتاه‌مدت با تمدید صریح، آسان‌تر از توکن‌های بلندمدت با دامنه‌های گسترده قابل استدلال هستند.
یک مکانیزم مشخص برای این کار، یک توکن قابلیت امضاشده است — یک اعتبارنامه ساختاریافته که عامل به طرف مقابل ارائه می‌دهد، شامل شناسه عامل، طرف مقابل مجاز، کلاس اقدام مجاز، پنجره اعتبار، و یک زنجیره امضا به اصل. طرف مقابل زنجیره را اعتبارسنجی و دامنه را به‌صورت محلی اعمال می‌کند. صفحه کنترل اصل هرگز لازم نیست برای پیشرفت تراکنش آنلاین باشد، اما تنها طرفی باقی می‌ماند که می‌تواند اعطای جدیدی ضرب کند.
مسیر ابطالی که به انسان دست نمی‌زند
ابطال، ویژگی‌ای است که بیشتر از همه غایب است. اگر تنها راه متوقف کردن یک عامل تغییر رمز عبور حساب باشد، آنگاه عامل واقعاً تفویض‌شده نیست — بلکه جعل هویت می‌کند. ابطال باید یک عملیات درجه‌یک باشد: شناسه عامل را در صفحه کنترل به‌عنوان ابطال‌شده علامت بزنید، آن وضعیت را منتشر کنید، و بگذارید طرف‌های مقابل ارائه اعتبارنامه ابطال‌شده را رد کنند. اعتبارنامه‌های انسان هرگز دخیل نمی‌شوند.
قاعده طراحی: هویت به‌عنوان یک منبع صفحه کنترل
پیامد عملی این است که هویت عامل به همان دسته‌ای تعلق دارد که یک اعتبارنامه پایگاه داده یا یک حساب سرویس. توسط زیرساخت صادر، محدود، نرخ‌محدود، ابطال و ثبت می‌شود، نه توسط یک فرم ورود.
این یعنی صفحه کنترل به یک رجیستری با چرخه عمر تعریف‌شده برای هر عامل نیاز دارد:
agent_id پایدار، مبهم، هرگز بازاستفاده نمی‌شود
principal_id ریشه اختیار
key_material کلید عمومی، برنامه چرخش
scopes [{counterparty, action_class, window}]
state active | suspended | revoked
rate_limits به ازای هر طرف مقابل، به ازای هر action_class
audit_log فقط-افزودنی، هر ارائه ثبت می‌شود
هر استفاده از هویت در گزارش حسابرسی نوشته می‌شود: کدام عامل، کدام طرف مقابل، کدام کلاس اقدام، کدام اعطا، و نتیجه. این همان سندی است که یک تراکنش مورد اختلاف را قابل حل می‌کند. بدون آن، عاملی که به نمایندگی از یک اصل عمل می‌کند از خود اصل که مستقیماً عمل می‌کند قابل تشخیص نیست، و پاسخگویی به انسان بازمی‌گردد.
طراحی برای رد
طرف‌های مقابل ترافیک خودمختار را اثرانگشت‌گذاری و نرخ‌محدود خواهند کرد. برخی آن را کاملاً رد خواهند کرد. این یک شرایط عملیاتی عادی است، نه یک مسیر خطا. معماری عاملی که رد را به‌عنوان یک استثنا برای تلاش مجدد تلقی کند، ترافیک فزاینده‌ای علیه طرف مقابلی تولید می‌کند که قبلاً تصمیم گرفته است. رفتار صحیح ثبت رد، نمایان کردن آن به اصل، و توقف است.
محدودسازی نرخ به سمت خود عامل نیز تعلق دارد. یک هویت تفویض‌شده با سقف به ازای هر طرف مقابل، مانع از آن می‌شود که یک عامل سهمیه‌ای را که اصل نیز به آن نیاز دارد تمام کند. همچنین یک سیگنال تولید می‌کند: فشار پایدار محدودیت نرخ روی یک طرف مقابل، شاهدی بر این است که دامنه اشتباه است، نه اینکه عامل به ظرفیت بیشتری نیاز دارد.
معاوضه
این طراحی گران‌تر از بازاستفاده از یک نشست است. به یک رجیستری، یک مکانیزم امضا، یک برنامه چرخش، یک کانال ابطال و یک خط لوله حسابرسی نیاز دارد. به هر تراکنش تأخیر اضافه می‌کند زیرا طرف مقابل باید یک زنجیره اعتبارنامه را اعتبارسنجی کند نه اینکه یک کوکی را بپذیرد. نیازمند هماهنگی با طرف‌های مقابلی است که ممکن است هنوز اصلاً اعتبارنامه‌های تفویض‌شده را نپذیرند — در این صورت عامل هیچ مسیر منطبقی ندارد و باید به تأیید انسان-در-حلقه بازگردد.
این هزینه همان نکته است. جایگزین، عاملی است که با اختیار کامل انسان عمل می‌کند، قابل نسبت‌دادن نیست، قابل محدودسازی نیست، و بدون شکستن دسترسی انسان قابل توقف نیست. زمانی که عامل‌ها با اشخاص ثالث تراکنش می‌کنند، واحد پاسخگویی قبلاً جابه‌جا شده است. زیرساخت باید دنبال کند.
این کجا فرود می‌آید
هویت عامل یک ویژگی احراز هویت پیچ‌شده به یک محصول موجود نیست. یک ابتدایی است که تعیین می‌کند یک عامل مجاز به چه چیزی است. تیم‌هایی که با آن به‌عنوان یک ورود برخورد می‌کنند، همچنان کشف خواهند کرد که طرف‌های مقابل با عامل‌هایشان به‌عنوان یک کلاس کلاینت ناشناخته برخورد می‌کنند، و همچنان وقتی پرسیده شود چه کسی عمل می‌کند و تحت چه اختیاری، پاسخی نخواهند داشت.
تیم‌هایی که با آن به‌عنوان زیرساخت برخورد می‌کنند — صادرشده، محدودشده، نرخ‌محدودشده، ابطال‌شده، ثبت‌شده — پاسخ خواهند داشت. همچنین ردپای حسابرسی برای اثبات آن را خواهند داشت.