OAuth 2.0 üzerine kurulu OpenID Connect, modern yığınlar için baskın federe kimlik protokolüdür. Her büyük kurumsal IdP onu destekler; her bulut iş gücü IdP'si onu sunar; her modern uygulama çatısı bunun için bir kütüphane sağlar. Kolay sanılan kısım, uygulama başına birkaç satır SDK kodunun yeterli olacağını varsaymaktır.
Pratikte, gerçek üretim trafiğini taşıyan bir OIDC relying party'nin uzun bir doğru yapma listesi vardır. ID token'ının imzası, IdP'nin yayınladığı JWKS'e karşı doğru anahtar kid ile seçilerek doğrulanmalı ve IdP anahtar döndürdüğünde önbellek tazelenmelidir. Audience talebi yapılandırılmış istemci ID'siyle eşleşmek zorundadır. Issuer yapılandırılmış beklenen issuer ile eşleşmelidir. Geçerlilik süresi, sınırlı bir saat sapması toleransıyla kontrol edilmelidir. ID token içindeki nonce, AAM'in yetkilendirme isteğinde gönderdiği nonce ile eşleşmek zorundadır — eşleşmiyorsa bu bir ayrıştırma hatası değil, tekrar oynatma denemesidir.
Alttaki OAuth 2.0 katmanının kendi tuzakları vardır. State, kullanıcının oturumuna CSRF olarak bağlanmalı ve kısa TTL'ye sahip olmalıdır. PKCE kullanılmalıdır (tercihen S256), böylece ele geçirilmiş bir yetkilendirme kodu saldırgan tarafından bozdurulamaz. Mixup saldırıları — saldırganın relying party'yi yanlış IdP ile konuşmaya kandırdığı durumlar — callback'i belirli bir IdP'ye bağlayıp issuer'ı buna göre doğrulayarak alt edilir. Saf bir SDK entegrasyonunda bu savunmaların hiçbiri otomatik değildir.
Diğer başarısızlık biçimi, OIDC SDK'sını her uygulamaya doğrudan gömmektir. Her uygulama bu durumda kendi güven kararlarını, JWKS önbelleğini, denetim loglarını ve IdP yapılandırmasını ayrı ayrı taşır. Tek bir IdP değişikliği, koordineli bir çok-uygulamalı yayım haline gelir. MFA, koşullu erişim, cihaz güveni ve çıkış davranışı her uygulama için ayrı ayrı, çoğu zaman tutarsız biçimde yeniden çözülür.
Operasyonel taraf da aynı derecede önemlidir. IdP'nin discovery belgesinin güncellenmesi, imzalama anahtarı rotasyonunun ele alınması, tenant başına farklı IdP yönlendirmesi, farklı uygulamalar için farklı talep eşlemeleri ve çıkış akışları sonradan eklenen küçük detaylar değildir. Bunlar OIDC federasyonunun güvenli ve sürdürülebilir çalışması için temel parçalardır.
Doğru yer erişim kenarıdır. OIDC tek noktada doğrulanmalı; kimlik doğrulama, MFA, koşullu erişim, cihaz güveni ve Backend SSO ile aynı katmanda yönetilmelidir. Böylece uygulamalar federasyon protokolünün karmaşıklığını taşımaz; yalnızca doğrulanmış, temiz ve güvenilir bir kimlik alır.
OIDC'yi doğru yönetmek, sadece bir IdP'ye SDK ile bağlanmak değildir. ID token'ı tek noktada — MFA, koşullu erişim, cihaz güveni ve Backend SSO ile aynı motorda — standartlara uygun biçimde doğrulamak, denetlemek ve uygulamalara güvenli şekilde taşımaktır.
Tek bir AAM ağ geçidi OIDC'yi kenarda doğru biçimde sonlandırır; erişim motorunun geri kalanı bunun üzerine biner.
PKCE'li yetkilendirme kodu akışı, JWKS üzerinden ID token imza doğrulaması, nonce'a bağlı tekrar oynatma savunması, state'e bağlı CSRF savunması, audience/issuer/geçerlilik uygulaması. Aynı motor ID token sunmayan IdP'ler için düz OAuth 2.0 konuşur; böylece yalnızca token sağlayan sağlayıcılar ve tam OIDC sağlayıcıları tek bir kod tabanını paylaşır.
Tek bir AAM ağ geçidi farklı uygulamaları farklı IdP'lere ve aynı uygulamanın farklı tenant'larını farklı IdP'lere aynı anda yönlendirebilir. IdP seçimi, uygulama veya tenant bağlamından istek başına yapılır — IdP başına ayrı ağ geçidi yok, kullanıcı için manuel seçici yok.
Nonce, ID token'ı onu isteyen yetkilendirme isteğine bağlar; state, callback'i kullanıcının oturumuna bağlar; PKCE, kod bozdurmasını orijinal public istemciye bağlar. Bunların hiçbiri entegratörün unutabileceği opsiyonel bayraklar değildir — varsayılan akışın kendisidir.
Bir OIDC kimlik doğrulaması tek başına çalışmaz — kenardaki MFA (IdP step-up uygulamadıysa), koşullu erişim ifadeleri, sürekli güven değerlendirmesi ve arka uca doğru Backend SSO enjeksiyonu ile birlikte bestelenir. ID token AAM oturumuna bir girdi olur; tüm oturum olmaz.
Standartlara uygun OIDC relying party artı federasyonu ölçekte güvenli ve yönetilebilir kılan operasyonel özellikler.
AAM, OAuth 2.0 yetkilendirme kodu akışını PKCE varsayılan olarak etkin biçimde başlatır — code_challenge_method=S256, her istek için taze bir code_verifier, asla yeniden kullanılmaz. Doğrulayıcıyı üretmeyen bir saldırgan, ele geçirdiği yetkilendirme kodunu token'larla değiştiremez. Düz PKCE, bunu zorunlu kılan IdP'ler için kullanılabilir kalır; S256 yapılandırılmış varsayılandır.
Callback geldiğinde AAM, IdP'nin JWKS'ini çeker, imzalama anahtarını ID token'ın kid başlığından seçer ve ID token'ın imzasını başlıkta belirtilen algoritma ile (RS256 ve standart ailenin geri kalanı) doğrular. kid üzerinde bir önbellek kaybı, JWKS'i hemen tazeler; böylece bir IdP anahtar rotasyonu geçerli oturum açmaları takılı bırakmaz.
ID token'ın audience talebi yapılandırılmış istemci ID'sini içermek zorundadır; issuer, yapılandırılmış beklenen issuer ile eşleşmelidir; geçerlilik penceresi (exp/nbf) sınırlı bir saat sapması toleransıyla uygulanır; nonce, AAM'in yetkilendirme isteğinde gönderdiği nonce ile eşleşmek zorundadır. Nonce uyuşmazlığı bir ayrıştırma hatası olarak değil, kendi denetim olayıyla bir tekrar oynatma sinyali olarak ele alınır.
JWKS yanıtları, çalışan süreçler ve ağ geçidi örnekleri arasında paylaşılan bir depoda 1 saatlik TTL ile önbelleğe alınır. Önbellek isabeti, her oturum açmada ağ gidiş-dönüşünü ortadan kaldırır; istenen kid üzerinde önbellek kaybı, JWKS URI'sinden anında bir tazeleme tetikler; böylece rutin IdP anahtar rotasyonu oturum açma kesintisi üretmez.
Standart OIDC yetkilendirme parametreleri birinci sınıf yapılandırmadır: scope (openid otomatik eklenir), IdP oturum açma deneyimi için display, zorunlu yeniden kimlik doğrulama için max_age, yerelleştirilmiş IdP sayfaları için ui_locales ve belirli bir kimlik doğrulama bağlam sınıfını istemek için acr_values — IdP'den step-up MFA uygulamasını istemek için kullanışlıdır.
Yerleşik profiller yaygın sağlayıcılar için makul varsayılanlarla gelir (well-known uç noktaları, JWKS URI'leri, scope alışkanlıkları). Standartlara uygun her OIDC veya OAuth 2.0 sağlayıcısı için uç noktaların, scope'ların ve eşlemelerin elle verildiği özel-IdP yolu da kullanılabilir kalır.
İmza doğrulamasından sonra, ID token'ın talepleri IdP'nin userinfo uç noktasından gelen yanıtla birleştirilir. Çakışma olduğunda, imzalı ID token talepleri imzasız userinfo alanlarına göre öncelikli kabul edilir; böylece userinfo yanıtını kurcalayan bir saldırgan, imzalı bir kimlik talebini sessizce değiştiremez.
RP-Initiated Logout (OIDC spec'inin imzalı ön kanal çıkışı) ve IdP'den oturum sonlandırma bildirimleri için arka kanal çıkış yol haritasındadır. OIDC dinamik istemci kaydı — yeni bir uygulamayı IdP'ye otomatik kayıt ederek devreye almak — da planlanmıştır. Oturum ve denetim altyapısı bu akışları zaten karşılayacak biçimdedir.
Bir OIDC federasyonunu güvenli, güncel ve gözlemlenebilir tutan mekanikler.
OAuth state parametresi, kullanıcının oturumuna karşı 10 dakikalık TTL ile saklanır. Callback geldiğinde AAM, state'in akışı başlatan aynı oturuma ait olduğunu doğrular — bir state değerini başka bir kullanıcının tarayıcısına yeniden oynatan saldırgan, OAUTH_STATE_MISMATCH denetim olayıyla reddedilir.
ID token imza doğrulaması operasyonel bir nedenle atlandığında — JWKS erişilebilir değil, eşleşen kid yok, bozuk JWK, eksik JWKS URI — özel bir denetim olayı belirli kök nedeni kaydeder. Operatörler, geçici bir JWKS kesintisini bir yanlış yapılandırmadan veya desteklenmeyen bir anahtar türünden çalışma zamanı loglarını yeniden okumadan ayırt edebilir.
ID token'ları iat, nbf ve exp zaman damgaları taşır. Gerçek saatler kayar; AAM sınırlı bir saat sapması toleransı uygular (alttaki JWT doğrulayıcı için varsayılan 60 saniye); böylece küçük sapma geçerli oturum açmaları reddetmez, büyük sapmalar — yanlış yapılandırma veya tekrar oynatma göstergesi — yine reddedilir.
IdP'ye karşı token değişimi ve userinfo istekleri, sınırlı bağlantı, DNS ve toplam zaman aşımları kullanır; böylece yavaş veya yanıtsız bir IdP ağ geçidi çalışanlarını meşgul edemez. Token değişimi 30 saniyelik toplam bütçeyle çalışır; userinfo 15 saniyelik bütçeyle çalışır; ikisinin de bağlantı ve DNS bütçeleri daha kısadır; böylece başarısızlıklar hızlı başarısız olur.
OIDC akışının her adımı — akış başlangıcı, callback başarısı, token değişimi (hangi token'lar döndü), ID token imza doğrulama sonucu, JWKS çekim sonucu — AAM oturumuna ve ardındaki arka uç(lar)a geri bağlanan bir korelasyon ID'siyle kaydedilir. "Kim hangi IdP üzerinden ne zaman oturum açtı" sorusu tek bir sorguyla yanıtlanır.
.well-known/openid-configuration uç noktası üzerinden otomatik OIDC sağlayıcı keşfi ve keşfedilen uç noktalar veya imzalama anahtarı setleri değiştiğinde operatöre uyarı yol haritasındadır. JWKS rotasyon telemetrisi — imzalama anahtarı değişim metrikleri, mevcut-anahtarın-süre-bitimine-kalan-gün ipuçları, otomatik rotasyon koşu kitapları — da planlanmıştır.
İş gücünü zaten OIDC üzerinden doğrulayan mevcut kurumsal IdP'ler. AAM, IdP ekibinden bir şey değiştirmesini istemeden bir relying party olarak takılır. Yeni uygulamalar her kod tabanına yeni bir OIDC SDK'sı ekleyerek değil; AAM'e bir kayıt ekleyerek federasyona katılır.
Kurumun Google Workspace tenant'ına karşı kimlik doğrulayan iç araçlar ya da GitHub'ı IdP olarak kullanan geliştirici araçları. AAM, Google'a OIDC ve GitHub'a OAuth 2.0 konuşur — aynı motordan — ve her birini kanonik AAM oturum biçimine eşler.
Her müşterinin kendi OIDC IdP'sini getirdiği SaaS uygulamaları. Tek bir AAM ağ geçidi tüm tenant'ları önde tutar; her tenant'ın trafiği o tenant'ın IdP'sine yönlenir. Tenant eklemek, bir dağıtım değil; IdP kayıt deposuna bir yapılandırma değişikliği eklemek demektir.
Bazı IdP'ler kimlik doğrular ama her uygulama için step-up MFA ya da koşullu erişimi eşit biçimde uygulamaz. AAM IdP'nin kimlik doğrulamasını kabul eder, sonra uygulamaya erişim vermeden önce kendi MFA'sını, koşullu erişim ifadelerini ve sürekli güven değerlendirmesini bunun üzerine biner.
AAM'i OIDC IdP'nize bağlayalım — kurumsal, bulut veya self-hosted — ve erişim motorunun geri kalanını MFA, koşullu erişim, cihaz güveni ve Backend SSO ile doğrulanmış ID token'ın üzerine bindirelim.