Trigger.dev پشتیبانی از OIDC workload identity را اضافه کرده است؛ روشی که در آن پلتفرم اجرای کد، هویت آن را با یک token امضاشده و کوتاه‌عمر تأیید می‌کند. OIDC استانداردی برای هویت بر پایه OAuth 2.0 است و workload identity از سازوکار امضا و انتشار کلیدهای آن برای کد در حال اجرا استفاده می‌کند.
API keyها معمولاً عمر طولانی دارند و گاهی دسترسی‌شان از نیاز کار گسترده‌تر است. اگر یک کلید میان چند سرویس مشترک باشد، لغو آن هم دشوار می‌شود. AI agent دارای دسترسی اجرای فرمان نیز می‌تواند فایل یا متغیر محیطی حاوی کلید را بخواند؛ در این حالت کلید ممکن است وارد context، سرویس ارائه‌دهنده مدل و log جلسه شود. token کوتاه‌عمر که برای یک سرویس مشخص صادر شده، ارزش کمتری نسبت به کلید چندماهه دارد.
در این سازوکار سه نقش وجود دارد: پلتفرم اجرا token را صادر و امضا می‌کند، کد آن را درخواست می‌کند و سرویس مقصد اعتبارش را می‌سنجد. اعتماد از قبل در سمت مقصد تنظیم می‌شود. صادرکننده کلید خصوصی را نزد خود نگه می‌دارد و کلید عمومی را منتشر می‌کند؛ بنابراین دو سرویس نیازی به اشتراک یک secret ندارند.
token از نوع JWT است و اطلاعاتی مانند صادرکننده در iss، هویت کد در sub و مقصد در aud دارد. سرویس مقصد علاوه بر امضا و الگوریتم مورد انتظار، صادرکننده، مقصد، زمان انقضا و تطابق اطلاعات با trust policy را بررسی می‌کند. بررسی aud به‌تنهایی کافی نیست: اگر sub بررسی نشود، ممکن است هر repository متعلق به یک صادرکننده مشترک مانند GitHub پذیرفته شود.
پشتیبانی از OIDC دو معنای متفاوت دارد: صدور token برای دسترسی کد به بیرون، یا پذیرش token از کدی که جای دیگری اجرا می‌شود. Trigger.dev نقش صادرکننده را دارد و سرویسی مانند AWS آن را می‌پذیرد و اطلاعات دسترسی موقت برمی‌گرداند.
در Trigger.dev هر سازمان صادرکننده مخصوص خود را دارد. آدرس صادرکننده و subject محیط از dashboard برداشته می‌شود و در تنظیمات مقصد قرار می‌گیرد. هر نوبت اجرا، از جمله retry، run token مخصوص خود را دارد و فقط نوبت فعال می‌تواند OIDC token بگیرد. این token پنج دقیقه اعتبار دارد؛ کار طولانی می‌تواند دوباره درخواست بدهد. در AWS باید subject دقیق محیط در trust policy ثبت شود تا فقط کارهای همان محیط بتوانند نقش تعیین‌شده را بگیرند.
