Kurumsal müşteri kendi hesabıyla giriş istiyor: SAML, OIDC ve SCIM gerçekte ne kadar iş?

Kurumsal bir müşteri "çalışanlarımız kendi hesabıyla girsin" dediğinde aslında üç ayrı iş ister: kimlik doğrulamanın onların sağlayıcısına devri (SAML ya da OIDC ile federasyon), hesapların otomatik açılıp kapanması (SCIM ile kullanıcı sağlama) ve yönetim tarafı (hangi e-posta alan adı kime ait, kim yönetici, kayıt nerede tutuluyor). Giriş ekranını değiştirmek bu işin en kolay parçası ve bir iki haftada biter. Zor olan, her müşteri için ayrı bir federasyon yapılandırmasını yıllarca ayakta tutmak. Sertifikalar doluyor, alan adları el değiştiriyor, kullanıcı kurumsal dizinde kapatılıyor ama sizdeki oturumu açık kalmaya devam ediyor.

Talep giriş butonu gibi görünür, aslında kontrol devridir

Müşterinin güvenlik ekibinin istediği şey kolaylık değil. Çalışan işten ayrıldığında erişimin tek bir yerden kesilmesini istiyorlar. Kendi çok faktörlü kimlik doğrulama politikalarının sizin uygulamanızda da geçerli olmasını, oturum sürelerini kendilerinin belirlemesini, kimin ne zaman girdiğini kendi kayıtlarında görmeyi istiyorlar. Yani sizden bir özellik değil, kontrolün bir kısmını devralmayı talep ediyorlar.

Bu devrin sınırı önemli: kimlik doğrulama onlara geçer, yetkilendirme sizde kalır. Kullanıcının kim olduğunu müşterinin sağlayıcısı söyler, o kullanıcının sizin ürününüzde neyi görebileceğine siz karar verirsiniz. Yetkilendirme modelinizi SSO'dan önce oturtmadıysanız, dizinden gelen grup adlarını rollere eşlemeye çalışırken iki sistemi birden tasarlamak zorunda kalırsınız.

SAML mı, OIDC mi?

İkisini de destekleyecek kaynağınız yoksa, kurumsal satın alma süreçlerinden geçiren hâlâ SAML. OASIS'in 2005'te yayımladığı SAML 2.0, kurumsal uygulama kataloglarında yirmi yıldır standart. OIDC daha yeni, JSON ve JWT üzerine kurulu, geliştirici tarafında belirgin biçimde rahat. Aradaki fark iki yerde pratik sonuç doğuruyor.

Birincisi anahtar yönetimi. OIDC'de sağlayıcı imzalama anahtarlarını JWKS uç noktasında yayımlar, istemci güncel anahtarı kendisi çeker, kimse takvime hatırlatma koymaz. SAML'da imzalama sertifikası elle takas edilen bir dosyadır ve ömrü dolduğunda kendiliğinden yenilenmez.

İkincisi IdP tarafından başlatılan giriş. Kurumsal kullanıcı, sağlayıcısının panelindeki uygulama kutucuğuna tıklayıp doğrudan içeri girmeyi bekler. SAML bunu doğal olarak destekler, çünkü sağlayıcı istenmeden de ACS adresinize bir yanıt gönderebilir. OIDC ise istek bağımlıdır: akış sizin gönderdiğiniz yetkilendirme isteğiyle başlar, state ve nonce o isteğe bağlanır. Üçüncü taraf tarafından başlatılan giriş için OIDC'de ayrı bir mekanizma var, ama uygulamayı sizin kurgulamanız gerekir. Bu yüzden 2026'da hâlâ birçok SaaS satıcısı kurumsal bağlantıyı SAML ile veriyor.

Tavsiye: protokolü bir ayrıntı haline getirin. Ürün içinde "kurumsal bağlantı" diye tek bir kavram tutun, altına SAML ve OIDC sağlayıcılarını takın. Kiracı eşlemesi, rol eşlemesi ve hesap yaşam döngüsü protokolden bağımsız kalsın.

En kritik adım alan adı doğrulaması

Çok kiracılı bir üründe tek bir giriş kutusu var ve kullanıcı e-postasını yazıyor. Siz alan adına bakıp "bu ornek.com.tr, demek ki şu müşterinin sağlayıcısına yönlendireceğim" diyorsunuz. Bu eşlemeyi kontrol eden kişi, o şirketin çalışanları olarak kimin giriş yapabileceğini de kontrol eder. Doğrulamayı atlarsanız yazdığınız şey bir SSO özelliği değil, bir hesap devralma mekanizmasıdır.

Doğru yol standart: kiracıya ve alan adına bağlı, yüksek entropili rastgele bir değer üretin, müşteri bunu alan adının DNS TXT kaydına koysun, siz çözümleyip karşılaştırın. Üç ayrıntıyı atlamayın. Doğrulamayı belirli aralıklarla tekrarlayın, çünkü alan adları el değiştirir ve eski bir doğrulama yalnızca geçmişteki sahipliği kanıtlar. Ortak kullanılan posta sağlayıcılarını (gmail.com, outlook.com ve benzerleri) reddeden bir engelleme listesi tutun. Bir alan adının aynı anda yalnızca tek bir kiracıya bağlanabildiğinden emin olun, ikinci bir talep geldiğinde süreç otomatik değil elle ilerlesin.

Assertion doğrulama: kütüphane kullanın, ama bağımlılığı izleyin

SAML yanıtını kendiniz ayrıştırmayın. XML imza doğrulaması, kriptografiyi bilen ekiplerin bile yanlış yaptığı bir alan. Olgun bir kütüphane kullanın ve şu kontrollerin açık olduğunu doğrulayın: imza güvenilen sertifikayla doğrulanıyor mu ve imzanın yanıtta mı assertion'da mı olduğu belirlenmiş mi, Audience sizin entity ID'nize eşit mi, NotBefore ve NotOnOrAfter dar bir saat kayması toleransıyla kontrol ediliyor mu, SP tarafından başlatılan akışta InResponseTo gerçekten gönderdiğiniz bir isteğin kimliğiyle eşleşiyor mu, Destination ve Recipient sizin adresiniz mi. Bir de tekrar koruması: kullanılmış assertion kimliklerini saklayın ve süresi dolana kadar ikinci kullanımı reddedin. Bu önbellek bütün uygulama örnekleri arasında paylaşılmalı, tek işlemdeki bir sözlük yük dengeleyicinin arkasında hiçbir işe yaramaz.

Kütüphane kullanmak sorumluluğu bitirmiyor. Mart 2025'te ruby-saml'da iki ayrı kimlik doğrulama atlatma açığı yayımlandı (CVE-2025-25291 ve CVE-2025-25292). Kök neden ilginç: kütüphane imza doğrulama sürecinde iki farklı XML ayrıştırıcı (REXML ve Nokogiri) kullanıyordu ve bu ikisi aynı belgeyi farklı yorumlayabildiği için saldırgan imza sarmalama (signature wrapping) yapabiliyordu. GitHub Security Lab'a 14 Kasım 2024'te bildirildi, düzeltmeler 12 Mart 2025'te 1.12.4 ve 1.18.0 sürümleriyle çıktı. Aynı açık omniauth-saml gibi dolaylı bağımlılıkları da etkiledi. Kurumsal girişi taşıyan kütüphaneler tedarik zinciri izlemenizde en üst sırada olmalı.

Sertifikanın dolduğu gün herkes kapıda kalır

SAML imzalama sertifikalarının ömrü genelde bir ila üç yıl. Microsoft Entra ID, SAML yapılandırması sırasında otomatik ürettiği sertifikayı varsayılan olarak üç yıl geçerli yapar ve süre dolmadan 60, 30 ve 7 gün önce müşterinin yöneticisine e-posta gönderir. O e-postanın size ulaşma ihtimali düşüktür. Sertifika değiştiğinde sizin tarafınızda elle güncelleme gerekiyorsa, bir sabah o müşterinin bütün çalışanları giriş yapamaz.

Üç önlem bu riski büyük ölçüde kapatıyor. Sağlayıcı federasyon meta verisini bir URL'de yayımlıyorsa sertifikayı dosya olarak değil o adresten periyodik çekin. Veri modelinizde kiracı başına birden fazla güvenilen imzalama sertifikası tutun ki geçiş sırasında eski ve yeni sertifika bir süre birlikte geçerli olsun. Son kullanma tarihini sorgulanabilir bir alan olarak saklayın ve 30 gün kala hem kendinize hem müşteriye uyarı çıkarın. Bu üçü, kurumsal SSO desteğine düşen biletlerin büyük bölümünü ortadan kaldırır.

SCIM, "çalışan ayrıldı" sorununun standart cevabı

Giriş çalışır hale geldikten sonra gelen ikinci talep hep aynı: kullanıcı dizinden silindiğinde sizin uygulamanızdaki hesabı da kapansın. Bunun standardı SCIM 2.0, iki RFC ile tanımlı: RFC 7643 şemayı (User ve Group kaynakları), RFC 7644 protokolü tarif eder. Pratikte sizden istenen, müşterinin sağlayıcısının konuşabileceği bir REST uç noktası sunmak.

Microsoft'un SCIM uç noktası geliştirme rehberi beklentileri net listeliyor: /Users ve tercihen /Groups üzerinde oluşturma, PATCH ile güncelleme, filter=userName eq "..." biçiminde sorgulama, sayfalama, /Schemas ile şema keşfi, /ServiceProviderConfig ve kimlik doğrulama için tek bir bearer token. Silme işi çoğunlukla gerçek silme değil: Entra ve Okta kullanıcıyı kapatırken active alanını false yapan bir PATCH gönderir, dolayısıyla çıkış mantığınız DELETE'i değil bu sinyali dinlemeli.

Zamanlamayı da baştan bilin. Entra'nın sağlama servisi ilk tam döngüden sonra yaklaşık 40 dakikada bir artımlı döngü çalıştırır, yani değişiklik anında gelmez; tek kullanıcıyı talep üzerine sağlayarak beklemeden test edebilirsiniz. Okta tarafında model itmeli çalışır, değişiklik olduğunda istek gelir. Entra'da kullanıcı dizinden silindiğinde 30 gün geçici silinmiş kalır ve kalıcı silme gerçekleştiğinde size DELETE düşer. Entra sağlama servisi iç içe grupların üyelerini okumaz, yalnızca doğrudan atanmış grupları görür. Hata oranı sürekli yüksek kalırsa iş karantinaya girer, döngü günde bire düşer ve karantina dört haftayı aşarsa sağlama tamamen devre dışı bırakılır. Bu davranışları bilmeyen ekip, müşterinin "senkron çalışmıyor" biletine günlerce yanlış yerde bakar.

SCIM'in zor kısmı protokol değil, iki kimlik kaynağı

Uç noktayı yazmak birkaç gün sürer. Asıl iş, aynı kullanıcının iki farklı yoldan gelebilmesinden çıkar: biri sizin davet ekranınızdan, diğeri müşterinin dizininden. Eşleştirme anahtarını baştan seçin ve belgeleyin. E-posta pratik görünür ama değişir; externalId değişmez ama ilk eşleşmeyi yine bir yerden kurmanız gerekir. İki kaydın birleşmesi gereken durumu bugün düşünmezseniz, ileride iki hesapla aynı kişiyi taşıyan müşteri verisini elle temizlersiniz.

İkinci tuzak, kapatmanın yüzeysel kalması. active: false geldiğinde kullanıcıyı pasif işaretlemek yetmez; açık oturumları ve yenileme token'larını da iptal etmeniz gerekir. Aksi halde işten ayrılan çalışan, dizinden silindikten sonra tarayıcısında açık kalan sekmeyle çalışmaya devam eder ve müşteri bunu er geç bir denetimde fark eder. Kullanıcıyı veritabanından gerçekten silmek de çoğu üründe yanlış karar: oluşturduğu kayıtlara, onaylara ve denetim izine yapılan atıfların ayakta kalması gerekir.

SSO açıldıktan sonra kalan kenar durumlar

Dört tanesi neredeyse her üründe karşınıza çıkar. Bir: SSO'yu kiracı bazında zorunlu kılma anahtarı. Müşteri "artık yalnızca kurumsal girişle gelinsin" dediğinde parolayla girişi o kiracı için kapatabilmelisiniz. İki: kilitlenme senaryosu. Sağlayıcı tarafında bir yapılandırma bozulduğunda içeri girebilecek, SSO zorunluluğundan muaf en az bir kırılgan cam yönetici hesabı kalsın ve bu hesabın kullanımı kayda geçsin. Üç: dizinde olmayan kullanıcılar. Dış denetçiler, danışmanlar ve ajanslar müşterinin dizininde yoktur, onlar için davet yolunu kapatmayın. Dört: oturum ömrü. SAML Single Logout pratikte kırılgandır, bu yüzden müşterinin "kullanıcıyı kapattım" beklentisini tek çıkış mekanizmasına değil, kısa oturum ömrüne ve token yenilenirken hesabın hâlâ etkin olduğunu kontrol etmeye dayandırın.

Fiyatlandırma kararı: SSO hangi pakete girecek?

Çoğu satıcı kurumsal SSO'yu en üst kademeye koyuyor. Bunun bir adı bile var, SSO tax. CISA'nın Mayıs 2024 tarihli SSO benimsenmesinin önündeki engeller raporu bu uygulamayı doğrudan eleştiriyor ve SSO'nun temel pakette varsayılan olarak sunulmasını öneriyor; rapora göre küçük işletmeler için SSO'nun önündeki engeller maliyet, teknik zorluk ve eksik dokümantasyon.

Pratik bir orta yol var. Girişin kendisini (SAML/OIDC bağlantısı) makul bir kademede verin, kurumsal yönetim özelliklerini ayrı paketleyin: SCIM ile otomatik sağlama, denetim kayıtlarının dışa aktarımı, kiracı bazlı oturum politikası, birden fazla sağlayıcı bağlama. Bu ayrım hem maliyetinizle orantılı, hem de güvenlik özelliğini para duvarının arkasına koymuş gibi görünmüyor. Satın alma incelemesinde ikinci nokta sandığınızdan daha sık soruluyor.

Kendi mi yazmalı, hazır bağlantı mı kullanmalı?

İlk SAML entegrasyonunu yazmak birkaç hafta sürer. Maliyet orada değil, onuncu müşterinin yapılandırmasında, sertifika yenilemelerinde ve "giriş çalışmıyor" biletlerini ayıklamakta. Üründe kimlik bir farklılaştırıcı değilse, kullandığınız kimlik servisinin kurumsal bağlantı özelliğini (Entra External ID, Auth0, Okta Customer Identity) ya da kendi sunucunuzdaki bir kimlik aracısını (Keycloak ve benzerleri) değerlendirin. Kimlik doğrulamada hazır servis mi kendi çözümümüz mü sorusunun cevabı kurumsal SSO geldiğinde belirginleşir, çünkü federasyon bu kararın en pahalı kalemidir.

Hangi yolu seçerseniz seçin sizde kalan üç şey var: alan adı doğrulaması, dizinden gelen grupların rollerinize eşlenmesi ve hesap kapatıldığında oturumun gerçekten sonlanması. Dış servis bunları sizin yerinize karar veremez.

Bu hafta yapabileceğiniz beş kontrol

Bir: test ortamınızda imzasız bir SAML yanıtı, başka bir audience'a kesilmiş bir assertion ve süresi geçmiş bir assertion gönderin; üçü de reddedilmeli. İki: aynı geçerli assertion'ı iki kez gönderin, ikincisi reddedilmiyorsa tekrar korumanız yok demektir. Üç: kurumsal müşterilerinizin imzalama sertifikalarının son kullanma tarihlerini tek bir sorguyla listeleyin, listeleyemiyorsanız bu alanı veri modelinize ekleyin. Dört: bir test kullanıcısını dizinde kapatın ve açık oturumunun kaç dakika içinde gerçekten sonlandığını ölçün. Beş: alan adı eşlemelerinizi gözden geçirin, DNS doğrulaması olmadan bağlanmış bir alan adı varsa bugün elle doğrulayın.

Kurumsal SSO talebi genelde satışın sıkıştığı bir anda gelir ve iki haftalık iş gibi tahmin edilir. Doğru tahmin, federasyonun kendisi için birkaç hafta, SCIM ve yönetim tarafı için benzer bir süre, üstüne her yeni müşteri için yarım günlük yapılandırma ve kalıcı bir destek yükü. Bu rakamı baştan koyarsanız, hem teklifiniz gerçekçi olur hem de özelliği hangi pakete koyacağınızı soğukkanlı kararlaştırırsınız.