OAuth 2.0 Token Exchange'in Farklı Yüzleri

• Bir güvenlik tokenını başka bir tokena dönüştüren standart tabanlı bir mekanizma; RFC 8693'te tanımlanan OAuth 2.0 genişletme spesifikasyonu
• Yetkilendirme sunucusunu bir Security Token Service(STS) haline getirerek, istemcinin gönderdiği tokenı doğrular ve farklı bağlam, hedef kitle (audience) ve amaca uygun yeni bir token verir
• Çalışma biçimi genel olarak iki moda ayrılır: kimliğe bürünme (Impersonation) ve yetki devri (Delegation)
• Yönetici kimliğine bürünmesi, protokol geçişi, servis zincirleme, federasyon kimliği gibi farklı kullanım senaryolarının her birinin kendi ödünleşimleri ve güvenlik etkileri vardır
• Yapay zeka ajanlarının yaygınlaşmasıyla, birden çok servis ve sağlayıcı arasında gidip gelen işler özünde bir yetki devri zincirine dönüştüğünden token değişiminin önemi daha da artıyor

---

Token Exchange nedir?

• İstemci subject_tokenı (isteğin öznesi olan kullanıcıyı/varlığı temsil eden token) gönderir ve isteğe bağlı olarak actor_tokenı (değişimi gerçekleştiren taraf) da birlikte gönderirse, hedef bağlama uygun yeni bir token alır
• Mevcut tokenı olduğu gibi iletmek ya da yeni bir tokenı sıfırdan oluşturmak sezgisel görünebilir; ancak her iki yaklaşım da ciddi sorunlara yol açtığı için bu sorunları çözmek üzere bu spesifikasyon oluşturulmuştur

• İki temel çalışma modu

  • Impersonation: İsteği yapan taraf, orijinal özneyle ayırt edilemeyen bir token alır; aşağı akış servisleri bunun gerçek kullanıcı mı yoksa onun kimliğine bürünen taraf mı olduğunu ayıramaz
  • Delegation: Her iki öznenin kimliği de korunur; yeni token içindeki act (actor) claim'i sayesinde aşağı akış servisleri hem kullanıcıyı hem de onun adına hareket eden tarafı görebilir
  • Kimliğe bürünme güçlüdür ama opaktır; yetki devri ise kısıtlıdır ama denetlenebilir — bu seçim güvenlik duruşunu ve izlenebilirliği belirler

Yönetici kimliğine bürünmesi (Administrative Impersonation)

• Müşteri panosunda yanlış verilerin gösterilmesi sorununu teşhis etmek için, destek mühendisinin müşterinin sahip olduğu yetkiler ve veri erişimiyle ekranı birebir görmesi gereken durum
• Yönetici kendi tokenını müşterinin kimliğini temsil eden bir tokenla değiştirir; ortaya çıkan token müşterinin sub claim'ini, scope'larını ve audience'ını içerdiğinden uygulama açısından istek müşteriden gelmiş gibi görünür
• Bu durumda istek yalnızca subject_tokenı (kimliğine bürünülecek kullanıcı) kullanır ve actor_token sağlanmaz — çünkü amaç tam anlamıyla kimliğe bürünmedir

• Denetim izi kaybı sorunu

  • Bu gerçek bir kimliğe bürünme olduğu için, eylemi gerçekte kimin yaptığına dair denetim izi kaybolur
  • Bu nedenle kim, ne zaman, hangi nedenle değişimi başlattı bilgisini kaydeden harici bir loglama mekanizması mutlaka eşlik etmelidir; aksi halde sorun çözme bahanesiyle bir güvenlik boşluğu oluşur

Protokol geçişini yönetmek (Managing Protocol Transition)

• Legacy sistemlerin ve eski protokollerin kaldığı ortamlarda, SAML kimlik doğrulamadan OpenID Connect(OIDC)'e geçiş yapılırken iki sistemin bir süre birlikte çalıştırıldığı senaryo
• Kullanıcıyı SAML ile doğrulayan servis, SAML assertion'ını OAuth 2.0 access tokenına dönüştürür; yetkilendirme sunucusu gelen SAML artefact'ını doğrular ve aşağı akışın anlayacağı standart bir access token verir

• subject_token_type parametresi

  • Gelen tokenın biçimini tanımlar; RFC 8693 birden çok token türü tanımlayıcısı tanımlar
    • SAML 2.0 assertion: urn:ietf:params:oauth:token-type:saml2
    • JWT token: urn:ietf:params:oauth:token-type:jwt
  • Yetkilendirme sunucusu, farklı protokol ailelerine ait tokenları kabul edip bunları modern servisler için tutarlı bir biçime normalize edebilir
• Şirket birleşme ve satın almalarında, farklı kimlik yığınlarına sahip iki organizasyonun tam geçiş tamamlanmadan önce birlikte çalışması gerektiğinde görülen bir desen; kullanıcı mevcut yöntemiyle kimlik doğrular, sistem de kimlik bilgilerini tüketen servisin beklediği biçime dönüştürür

Servis çağrısı zincirleme (Chaining Service Calls)

• Mikroservis mimarisinde Service A bir kullanıcı isteğini işledikten sonra kullanıcı adına Service B'yi, ardından Service B'nin de Service C'yi çağırması gerektiğinde, her servisin bir sonraki çağrıda hangi kimlik bilgilerini kullanacağı temel sorudur

• Seçenek 1 — Servisin kendi kimlik bilgilerini kullanması

  • Service A, kullanıcı bağlamını yok sayıp kendi istemci kimlik bilgileriyle Service B'yi çağırır; batch işleme, sistem durum denetimi, veri senkronizasyonu gibi kullanıcı bağlamının gerekmediği servisler arası çağrılar için uygundur
  • Kullanıcı işin içindeyse Service B kullanıcı düzeyinde yetkilendirme uygulayamaz — isteği hangi kullanıcının yaptığı bilinmediğinden erişim yetkisi doğrulanamaz, güvenlik bağlamı kaybolur

• Seçenek 2 — Servisin kullanıcı kimliğine bürünmesi

  • Service A, kullanıcının orijinal tokenını doğrudan Service B'ye iletir ya da kullanıcıdan ayırt edilemeyen bir tokenla değiştirir; Service B bunu kullanıcıdan gelen bir istek olarak görür ve kullanıcı düzeyinde yetkilendirme uygular
  • Service B, kullanıcının doğrudan eylemiyle Service A'nın vekil olarak yaptığı eylemi ayıramaz; Service A ele geçirilirse kullanıcı yetkileri dahilindeki tüm çağrılar yapılabilir ve doğrudan/proxy istekler için farklı güven seviyeleri uygulanamaz — kullanıcı bağlamı korunur ama servis bağlamı kaybolur

• Seçenek 3 — Kullanıcı adına hareket etmek (Delegation)

  • Service A, kullanıcı tokenını hem kullanıcıyı (subject) hem de Service A'yı (actor) tanımlayan yeni bir tokenla değiştirir; sonuç tokenındaki act claim'i "User X ile ilgili istek, Service A tarafından yürütüldü" bilgisini taşır
  • RFC 8693'ün esas olarak desteklemek üzere tasarlandığı yetki devri modeli budur; Service B daha gelişmiş yetkilendirme kararları verebilir — Service A, kullanıcının izin vermediği bir işlemi denediğinde istek başarısız olur
  • act claim'i iç içe geçirilebilir (nestable); Service B, Service C'yi çağırdığında yetki devri zinciri genişler ve tam bir denetim izi sağlar
  • Ödünleşim karmaşıklıktır — her atlamada token değişimi gerekir, bu da gecikmeyi artırır ve her servisin yetkilendirme sunucusunda istemci olarak kayıtlı olmasını gerektirir; ancak güvenlik ve denetimin önemli olduğu mimarilerde ilkesel seçim budur

Token Exchange ve federasyon kimliği

• Servisler güvenlik alanları arasında geçtiğinde (ör. üçüncü taraf bir organizasyonun sağladığı servis) zincir senaryosu çok daha karmaşık hale gelir
  • Service A, MyCompany güvenlik alanındaki kullanıcı adına Service B'ye erişen bir tokena sahiptir
  • Service B'nin, External Provider alanında korunan Service C'yi çağırması gerekir ve bunun için bir access tokena ihtiyacı vardır
• MyCompany yetkilendirme sunucusunun verdiği token, External Provider alanında anlamsızdır — bir yetkilendirme sunucusunun verdiği token başka bir sunucu tarafından otomatik olarak kabul edilmez; güven sınırları, etki alanını (blast radius) sınırlamak için vardır

• Federasyon kurulumunun sınırları

  • External Provider yetkilendirme sunucusunun, MyCompany alanındaki tokenları geçerli bir subject token olarak kabul edecek şekilde yapılandırılması gerekir; metadata değişimi, sertifika doğrulaması ve doğrudan yapılandırma yoluyla önceden güven ilişkisi ile alanlar arası kimlik eşlemesi gerekir
  • Alan sayısı arttıkça (kurumsal entegrasyonlar, SaaS ekosistemi, çoklu bulut), ikili güven ilişkileri matrisi yönetilemez hale gelir

• Cross App Access ve Identity Chaining

  • Bu ölçeklenme sorununu çözmek için Cross App Access(XAA), Identity Assertion JWT Authorization Grant'i uygular ve alanlar arası değişimde kurumsal IdP'yi aracı olarak devreye sokar
  • Temel fikir, IdP'nin zaten her iki uygulamayı ve kullanıcı ilişkisini biliyor olmasıdır; böylece her alan çiftinin ayrı ayrı güven kurması yerine erişim kararları IdP üzerinde merkezileştirilir

  • XAA akışındaki 4 taraf

    • Requesting App: Başka bir alandaki kaynağa erişmesi gereken MyCompany alanındaki uygulama (veya yapay zeka ajanı)
    • Enterprise IdP: Çalışanların kimliğini doğrulayan ve uygulamalar arası politikaları yöneten MyCompany alanı kimlik sağlayıcısı
    • Resource App: External Provider alanında korunan API'nin sahibi olan uygulama
    • Resource Authorization Server: Resource App'in korunan API'si için access token veren yetkilendirme sunucusu

  • XAA'nin adım adım akışı

    • Çalışan, SSO ile Requesting App'e giriş yapar ve IdP'den bir ID token alır
    • Requesting App bu ID tokenı tekrar IdP'ye göndererek alanlar arası kimlik assertion'ı (ID-JAG, uygulamalar arası kullanım için scope'lanmış özel bir JWT) ister
    • IdP, XAA politikasını kontrol eder — bu kullanıcı adına Resource App'e erişime izin verilip verilmediğine karar verir; izin varsa ID-JAG döner
    • Requesting App, ID-JAG'i Resource App yetkilendirme sunucusuna sunar
    • Resource App yetkilendirme sunucusu, OIDC discovery ile IdP'nin açık anahtarını kullanarak ID-JAG'i doğrular ve ardından access token verir
    • Requesting App bu access token ile Resource App API'sini çağırır
  • Normal token değişiminden kritik fark, 3. adımda IdP'nin politika kararını zorunlu kılmasıdır — yöneticiler hangi uygulamanın hangi kaynağa erişebileceğini açıkça yapılandırır; bu da IT ekiplerine görünürlük ve kontrol sağlar, kullanıcılar ise tekrarlayan onay akışlarından kaçınır
  • Identity Chaining, kullanıcı kimliği assertion'ının ilk kimlik doğrulamadan tüm aşağı akış servislere kadar standart bir biçimde aktığı daha geniş bir desendir; XAA ise bunun OAuth primitive'leri üzerine kurulu bir uygulamasıdır
  • Tek bir kullanıcı isteğinin birden çok üçüncü taraf sağlayıcı servis çağrısını tetiklediği yapay zeka ajanı senaryolarında özellikle önemlidir

Token Exchange ve Auth0

• Auth0, yukarıda ele alınan spektrumun farklı noktalarını kapsayan mekanizmalarla token değişimini uygular

• Custom Token Exchange

  • Auth0'un /oauth/token endpoint'inde RFC 8693'ü uygular ve doğrulama mantığı üzerinde geliştiriciye tam kontrol sağlar
  • subject_token_type URI'sini özel bir Action'a eşleyen Token Exchange Profile tanımlanır; istek geldiğinde Auth0, token doğrulama, yetkilendirme kurallarını uygulama ve tenant içindeki kullanıcıyı eşleme için Action kodunu çalıştırır
  • Auth0 subject_tokenı opak bir string olarak ele aldığından, başka bir IdP'den gelen JWT, legacy SAML assertion'ı ya da partner API'nin özel tokenı gibi her biçimi kabul edebilir — bu da onu protokol geçişi ve özel federasyon için uygun bir mekanizma yapar

• Token Vault

  • Birden çok sağlayıcı genelinde kullanıcı adına üçüncü taraf API'leri çağıran yapay zeka ajanı senaryoları için, token değişimine güvenli saklama ve otomatik yaşam döngüsü yönetimi ekler
  • Kullanıcı kimlik doğrulamadan sonra hesaplarını (Google, GitHub, Slack, Microsoft vb.) bağlar; Token Vault tokenları güvenli biçimde saklar ve yenilemeyi otomatik yürütür; yapay zeka ajanı da token değişimi yoluyla geçerli bir access tokenı kasadan alır
  • Sonuç tokenı, yapay zeka ajanını tanımlayan bir act claim'i içerir — hangi ajanın hangi kullanıcı adına hangi servise eriştiğine dair denetim izi oluşturur; bu da otomasyonu neyin tetiklediğinin bilinmesini gerektiren kurumsal uyumluluk için kritiktir

• On-Behalf-Of (OBO) Token Exchange

  • Servis zinciri senaryoları için yetki devri desenini doğrudan uygular; ara katman servis, gelen kullanıcı tokenını aşağı akış API'ye scope'lanmış yeni bir tokenla değiştirir ve act claim'i ile kendini yetki devri zincirine ekler
  • En fazla 5 seviyeli iç içe yetki devri zinciri desteği sunar; her token sub (kullanıcı kimliğini korur), aud (hedef servis scope'u) ve iç içe act (zincirdeki servisleri kaydeder) claim'lerini taşır

• Cross App Access (XAA)

  • İstekte bulunan uygulamanın, başka bir yetkilendirme sunucusu tarafından korunan kaynak API'yi çağırması gereken federasyon kimliği senaryoları için, Identity Assertion Authorization Grant OAuth genişletmesini uygular
  • Auth0, Resource Authorization Server rolünü üstlenir — Requesting App kullanıcı ID tokenını Okta gibi bir IdP'ye gönderip ID-JAG alır; IdP yalnızca yönetici Admin Console üzerinden uygulamalar arası bağlantıyı yapılandırdıysa assertion verir
  • Requesting App ID-JAG'i Auth0'a sunduğunda, Auth0 bunu OIDC discovery ile doğrular ve scope'lanmış access token verir; böylece IT ekiplerine uygulamalar arası veri paylaşımında merkezi görünürlük sağlar

Doğru yaklaşımı seçmek

• Token Exchange tek bir çözüm değil, bir desenler kümesidir; hangi bağlamın korunacağına ve hangi güven sınırlarının aşılacağına göre seçim değişir
  • Yönetici kimliğine bürünmesi: Sorun giderirken kullanıcının gördüğü ekranı aynen görmek gerektiğinde
  • Protokol geçişi: Geçiş sürecinde legacy ve modern kimlik sistemleri arasında köprü gerektiğinde
  • Delegation: Servis zinciri, tam denetlenebilirlikle birlikte kullanıcı bağlamı gerektirdiğinde
  • Cross App Access / Identity Chaining: Yetki devri birden çok güvenlik alanına yayıldığında
  • Token Vault: Yapay zeka ajanı, kullanıcı adına üçüncü taraf API'lere yönetilen erişim gerektirdiğinde
• Birden çok servis ve sağlayıcı boyunca kullanıcı adına işleri orkestre eden yapay zeka ajanları özünde birer yetki devri zinciridir; token değişim mekanizmaları da bu zinciri denetlenebilir, yetkilendirilmiş ve kullanıcının niyetiyle scope'lanmış hale getiren güvenlik temelini sağlar