Açık kaynak theAuth, yapay zeka ajanlarına ve insanlara kapsamlı yetkiler, RBAC, SSO ve SCIM sunuyor

Paylaşılan anahtar sorunu

10 Ekim'de dev.to'da yayımlanan iki rehber, theAuth'yı inceliyor: yapay zeka ajanlarını ve insan kullanıcıları dar kapsamlı yetkilere sahip ayrı kimlikler olarak ele alan açık kaynak TypeScript kimlik doğrulama kütüphanesi (@glinr/theauth). Rehberlerden biri ajan başına kimlik ve yetkilendirmeyi, diğeri ise kütüphanenin çok kiracılı tarafını ele alıyor: organizasyonlar, rol tabanlı erişim kontrolü, çoklu oturum açma ve SCIM provisioning'i. Yazılar sekiz rehberlik bir dizinin parçası ve yazar, kütüphanenin bazı bölümlerini kendisinin yazdığını belirtiyor; bu yüzden içerik tarafsız bir incelemeden çok geliştirici dokümantasyonu gibi okunuyor.

Ajan rehberi tanıdık bir sorunla başlıyor: tek bir insan API anahtarının bir cron job'a, bir Slack botuna, bir kod inceleme ajanına ve unutulmuş bir notebook'a kopyalanması. dev.to yazısına göre bu düzen üç şekilde birbirini besleyerek başarısız oluyor: Yalnızca pull request okuması gereken bir kod inceleyicisi, insanın her yerdeki yazma erişimini devralıyor; anahtarın döndürülmesi tüm tüketicileri aynı anda kırarken açığa çıkan bir kimlik bilgisi aktif kalıyor; ve denetim kaydında her satırda insanın adı görünüyor, bu yüzden hangi sürecin gerçekte bir eylemi gerçekleştirdiğini söylemek imkânsız hale geliyor.

Ajanlar kendi kimliklerini alıyor

theAuth'nın cevabı her ajana kendi veritabanı satırını, sahibini ve izin listesini vermektir. Bir ajan açıkça bir kullanıcı değildir: e-postası, şifresi, oturumu veya OAuth hesabı yoktur; yalnızca bir bearer token ve bir izin kümesi vardır. Token'lar kv_ önekiyle başlar, 46 karakter uzunluğundadır ve 32 rastgele bayt kodlar; yalnızca SHA-256 hash'i saklanır, böylece tam bir veritabanı dump'ı bile canlı bir kimlik bilgisini ortaya çıkaramaz. Düz metin yalnızca bir kez, oluşturulurken görünür ve hemen bir secrets manager'a kaydedilmeli ya da döndürülmelidir.

Ajanlar üç türde gelir: cron görevleri gibi gözetimsiz işler için autonomous (varsayılan), bir delegation zinciriyle daha dar izinleri devralan kısa ömürlü worker'lar için delegated ve MCP server'lar gibi uzun ömürlü altyapı kimlikleri için service. Uygulama kodunun her hassas eylemin önüne koyması gereken authorize() çağrısıyla zorunlu kılınma sağlanır; allow veya deny döndürür, bir denetim kimliği taşır ve hız sınırları, argüman desenleri ve zaman pencereleri gibi kısıtlamaları destekler. HTTP middleware'i geçersiz token'ları ve eksik izinleri 401 ve 403 yanıtlarına eşler. Varsayılanlar muhafazakârdır: her karar kaydedilir, yeni ajanlar başka şekilde yapılandırılmadıkça 24 saat sonra sona erer ve her kullanıcı en fazla on aktif ajana sahiptir. Kütüphane Node 20 veya daha yeni sürümleri hedefler; rehberlerdeki örneklerde SQLite kullanılır ve üretim için Postgres desteklenir.

Organizasyonlar, RBAC, SSO ve SCIM

İkinci rehber, bir kurumsal alıcının Okta girişi ve otomatik deprovisioning istediği anı hedefler. Beş parçayı katmanlar: kiracılık için bir organizasyon modülü, RBAC için yerleşik ve özel roller, kaynak başına kararlar için ilişki tabanlı bir motor, e-posta alan adına göre yönlendirilen SAML 2.0 veya OIDC'yi işleyen bir SSO modülü ve kimlik sağlayıcıdan kullanıcıları provisioning eden ve devre dışı bırakan bir SCIM plugin'i.

Dört rol yerleşik olarak gelir — owner, admin, member ve viewer — ve organizasyonlar invoices:pay gibi rastgele izin dizgileriyle özel roller tanımlayabilir. Runtime kontrolü tek bir hasPermission çağrısıdır ve isteğe bağlı bir plugin, kimliği doğrulanmış bir kullanıcı gerektiren organizasyon route'larını kaydeder. Varsayılanlar arasında organizasyon başına 100 üye, kullanıcı başına beş organizasyon, yedi günlük davetiye geçerlilik süresi ve saatlik 50 davetiye sınırı bulunur. ReBAC motoru kaynakları bir ağaçta kaydeder ve RBAC'nin yanıtlayamadığı soruları yanıtlamak için ilişki tuple'ları ekler; örneğin belirli bir kullanıcının, bir workspace'i düzenlediği için belirli bir belgeyi açıp açamayacağı gibi.

Rehberlerin kabul ettiği kusurlar

Yazılar sınırlar konusunda açık sözlü. Kullanıcı başına ajan sınırının aşılması özel bir kod olmadan düz bir hata fırlatır ve REST endpoint bunu 500 olarak gösterir. Ayrı tenant modülü bir zorunlu kılma katmanı değil, bir veri modelidir: authorize() tenant'ları karşılaştırmaz ve bir tenant'ı askıya almak hiçbir şeyi engellemez, bu yüzden yazar tenantId'yi manuel olarak kontrol edilmesi gereken bir etiket olarak ele alıyor. Daha geniş bir handleRequest route tablosu hiçbir kimlik doğrulaması yapmaz ve özel kontrollerin arkasına yerleştirilmelidir. En temelde, theAuth bir karar noktasıdır, bir sandbox değil — bir ajan kendi kimlik bilgileriyle doğrudan bir veritabanına ulaşabiliyorsa, hiçbir izin listesi bunu durduramaz.

Neden önemli

Ajanik iş yükleri, çoğu ekibin yönetebileceğinden daha hızlı kimlik bilgisi çoğaltıyor ve ödünç alınan insan anahtarları hem denetimleri hem de iptali anlamsız kılıyor. Ajan kimliklerini, hash'lenmiş kısa ömürlü token'ları ve kurumsal insan kimlik doğrulamasını — SSO, SCIM, RBAC — tek bir açık kaynak kütüphanede birleştirmek, ekiplerin genellikle haftalarca elle yazdığı işi yapılandırmaya indirgiyor. Zorunlu kılma boşlukları gerçek ve kabul edilmiş durumda, ancak varsayılan geçerlilik süresiyle ajan başına kapsam belirleme, paylaşılan anahtarların en kötü iki özelliğine saldırıyor: sınırsız etki alanı ve hiç süresi dolmayan bayat kimlik bilgileri.