Yetenek

OIDC / OAuth 2.0 Federasyonu

Erişim kenarında tam bir OpenID Connect relying party — doğrulanmış kimlik token'ları, tekrar oynatmaya kapalı akışlar ve tenant başına IdP yönlendirme.

Modern kurumsal ve tüketici IdP'leri — Entra ID, Okta, Auth0, Google Workspace, GitHub, Keycloak — OAuth 2.0 üzerinde OpenID Connect konuşur. Yeni uygulamalar için doğru yaklaşım paralel bir kullanıcı veritabanı sürdürmek değil; doğrudan bu IdP'lere bağlanmaktır. TR7 AAM, uygulamanın önünde standartlara uygun bir OIDC relying party olarak davranır. Yetkilendirme kodu akışı PKCE, nonce ve oturuma bağlı state ile başlatılır; kullanıcı IdP'de o IdP'nin uyguladığı MFA ve politika ile oturum açar; IdP, AAM'e bir yetkilendirme kodu döndürür; AAM kodu token'larla değiştirir, IdP'nin JWKS'ini çeker ve kimliği çıkarmadan önce kimlik token'ının (ID token) imzasını, audience'ını, issuer'ını, geçerlilik penceresini ve nonce'unu doğrular. Doğrulanmış ID token talepleri, userinfo uç noktası yanıtıyla birleştirilir ve kanonik AAM oturum kimliğine eşlenir. 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. Sonuç: Erişim motorunun geri kalanı — koşullu erişim, cihaz güveni, kenar MFA, Backend SSO — OIDC oturumunun üzerine biner. Her adım denetlenir; ID token doğrulama sonuçları (imza, nonce, audience, issuer, geçerlilik) birinci sınıf denetim olaylarıdır; böylece güvenlik ekibi "kim hangi IdP üzerinden hangi sonuçla oturum açtı" sorusunu tek bir akıştan yanıtlayabilir.

OIDC + OAuth 2.0

Standartlara uygun relying party — yetkilendirme kodu, PKCE, JWKS ile doğrulanmış ID token'ları, nonce ve state savunmaları.

S256 PKCE

Varsayılan code-challenge yöntemi — ele geçirilmiş kodlar saldırgan tarafından bozdurulamaz.

Paylaşımlı JWKS önbelleği

Çalışan süreçler ve ağ geçidi örnekleri arasında 1 saatlik TTL; IdP anahtar rotasyonu için kayıpta-yenileme.

OIDC dışarıdan basit görünür — uygulama başına entegre edildiğinde tuzaklarla doludur

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.

Yaklaşımımız

Tek bir AAM ağ geçidi OIDC'yi kenarda doğru biçimde sonlandırır; erişim motorunun geri kalanı bunun üzerine biner.

Tam OpenID Connect relying party artı OAuth 2.0 istemcisi

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.

Uygulama ve tenant başına IdP yönlendirme

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.

Tekrar oynatma, CSRF ve mixup saldırıları varsayılan olarak alt edilir

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.

MFA, koşullu erişim, cihaz güveni ve Backend SSO ile koordineli

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.

Yetenekler

Standartlara uygun OIDC relying party artı federasyonu ölçekte güvenli ve yönetilebilir kılan operasyonel özellikler.

PKCE'li yetkilendirme kodu akışı (varsayılan S256)

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.

ID token imzasının IdP JWKS'ine karşı doğrulanması

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.

Audience, issuer, geçerlilik ve nonce — yalnız ayrıştırılmaz, uygulanır

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.

Anahtar rotasyonu için kayıpta-yenileme yapan paylaşılan JWKS önbelleği

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.

OIDC parametreleri: scope, display, max_age, ui_locales, acr_values

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 sağlayıcı profilleri artı tamamen özel IdP'ler

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.

ID token talepleri userinfo ile birleştirilir; imzalı talepler önceliklidir

İ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.

Operasyonel derinlik

Bir OIDC federasyonunu güvenli, güncel ve gözlemlenebilir tutan mekanikler.

10 dakikalık TTL ve oturum kontrolü ile state bağlama

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.

Her ID token doğrulama atlamasında denetim — kök neden bazında

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.

IdP başına sınırlı saat sapması toleransı

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.

Sertleştirilmiş ağ zaman aşımlarıyla token değişimi ve userinfo

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.

AAM oturumuna korelasyonlu olay başına denetim

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.

Hangi ekipler kullanır

Modern kurumsal IdP'ler (Entra ID, Okta, Auth0, Keycloak)

İş 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.

İş gücü sosyal IdP'leri (Google Workspace, GitHub)

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.

Tenant başına OIDC IdP'li çok-tenantlı SaaS

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.

Bir OIDC IdP'sinin üzerine kenar MFA ve koşullu erişim

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.

Sık sorulan sorular

AAM hangi IdP'lerle OIDC ve OAuth 2.0 üzerinden federe olur?

Standartlara uygun her OIDC veya OAuth 2.0 IdP'si. Pratikte buna Entra ID (Azure AD), Okta, Auth0, Keycloak, Google Workspace, GitHub ve standart uç noktaları sunan her özel IdP dahildir. Yerleşik profiller yaygın sağlayıcılar için makul varsayılanlarla gelir; uç noktaların, scope'ların ve eşlemelerin elle verildiği özel-IdP yolu, standartlara uygun her sağlayıcı için kullanılabilir kalır.

AAM, ID token tekrar oynatma, CSRF ve mixup saldırılarına karşı nasıl savunur?

Nonce, ID token'ı onu isteyen yetkilendirme isteğine bağlar — uyuşmazlık, kendi denetim olayıyla özel bir tekrar oynatma sinyalidir. State, callback'i kullanıcının oturumuna 10 dakikalık TTL ile bağlar — oturumlar arası tekrar oynatma reddedilir. PKCE (varsayılan S256), kod bozdurmasını orijinal istemciye bağlar — ele geçirilmiş bir yetkilendirme kodu saldırgan tarafından token'larla değiştirilemez. Mixup saldırıları, callback'i belirli bir IdP'ye bağlayıp issuer talebini buna göre doğrulayarak alt edilir.

IdP imzalama anahtarlarını döndürdüğünde ne olur?

JWKS, paylaşılan bir depoda 1 saatlik TTL ile önbelleğe alınır. Callback geldiğinde AAM, imzalama anahtarını ID token'ın kid başlığından önbellekten seçer. kid önbelleğe alınmış sette yoksa — bir IdP anahtar rotasyonundan hemen sonra olan budur — AAM, JWKS URI'sinden anında bir tazeleme tetikler ve seçimi yeniden dener. Rutin bir anahtar rotasyonu oturum açma kesintisi üretmez.

Bu sayfada OIDC ile düz OAuth 2.0 arasındaki fark nedir?

OIDC, OAuth 2.0'ın üzerine bir kimlik katmanı ekler: erişim token'ının yanında kimlik talepleri içeren imzalı bir ID token döndürülür. AAM her ikisini de konuşur. OIDC sağlayıcıları için, ID token JWKS'e karşı doğrulanır ve userinfo yanıtıyla birleştirilir; imzalı talepler önceliklidir. Düz OAuth 2.0 sağlayıcıları için (ID token yok), AAM kimlik için yalnızca userinfo yanıtına dayanır ve akışın etrafında aynı denetim, state ve PKCE savunmalarını uygular.

AAM token'ları tükettikten sonra kimliğe ne olur?

Doğrulanmış ID token talepleri ve userinfo yanıtı birleştirilir ve kanonik AAM oturum alanlarına (kullanıcı adı, e-posta, gruplar, görüntü adı, özel öznitelikler) eşlenir. Erişim motorunun geri kalanı bu oturum üzerinde akıl yürütür — MFA gating, koşullu erişim ifadeleri, sürekli güven değerlendirmesi, arka uca doğru Backend SSO enjeksiyonu. Uygulama kimliği Backend SSO ile beklediği biçimde alır; OIDC protokolü AAM kenarında durur.

OIDC doğru biçimde, kenarda

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.