SAML ve OIDC, tek oturum açmayı (SSO) mümkün kılan iki temel kimlik federasyonu protokolüdür. Temel SAML OIDC farkı şudur: SAML 2.0, kimlik bilgisini tarayıcı üzerinden imzalı XML belgeleriyle taşır ve kurumsal web uygulamalarına uygundur. OpenID Connect (OIDC) ise OAuth 2.0 üzerine kurulu, JSON/JWT tabanlı bir katmandır; mobil uygulama, tek sayfa uygulama ve API senaryolarına daha iyi oturur.
Bu yazı "SSO nedir" sorusunu değil, SSO kurmaya karar vermiş bir ekibin "hangi protokolle bağlanalım" sorusunu cevaplıyor. SSO'nun ne kazandırdığını merak ediyorsanız önce tek oturum açma (SSO) rehberimize bakın.
Karar anı: aynı ekranda iki seçenek
Tipik senaryo şöyle başlar: bir bulut uygulamasının yönetim panelinde "SSO ayarları" sekmesini açarsınız ve iki seçenek görürsünüz: SAML ve OpenID Connect. Kimlik sağlayıcınız ikisini de destekliyor, uygulama da ikisini destekliyor. Hangisini seçeceğinizi kimse söylemiyor.
Kendi yazılımınızı geliştiriyorsanız soru daha da ağırlaşır. Web paneli, sahadaki ekibin kullandığı mobil uygulama ve bayilerin bağlandığı API aynı kimliği kullanmalıdır. Yanlış protokol seçimi, mobil tarafta tarayıcı hilelerine, API tarafında ise ayrı bir parola düzenine yol açar; bu da tek kimlik hedefini ortadan kaldırır.
Üçüncü durum, eski ve yeni sistemlerin karışık olduğu kurumlardır. Muhasebe ya da İK tarafındaki eski bir kurumsal yazılım yalnızca SAML bilir, yeni geliştirilen uygulamalar ise OIDC ile yazılır. Burada soru "hangisi" değil, "ikisini tek kimlik sağlayıcıda nasıl tutarlı yönetiriz" olur.
Yanlış protokol ve dağınık kimliğin maliyeti
Protokol seçimi teknik bir ayrıntı gibi görünür ama kimlik katmanındaki her boşluk doğrudan saldırı yüzeyidir. Saldırganlar artık kapıyı kırmak yerine anahtarı çalıyor:
Verizon 2026 Veri İhlali Araştırmaları Raporu (DBIR) verisine göre çalıntı kimlik bilgilerinin kullanımı, ihlallerin %36'sında görülen bir eylem olarak yerini koruyor.
Aynı raporda üçüncü tarafların dahil olduğu ihlaller %60 artarak toplamın %48'ine ulaştı ve üçüncü taraf kurumların yalnızca %23'ü bulut hesaplarındaki eksik ya da zayıf çok faktörlü doğrulama sorununu tamamen giderdi. Her SaaS uygulamasının kendi parolasıyla yaşadığı bir düzen, tam da bu zayıf halkaları çoğaltır.
Sophos'un 2026 kimlik güvenliği araştırması 17 ülkede 5.000 BT ve güvenlik yöneticisiyle yapıldı. Kurumların %71'i son bir yılda en az bir kimlikle ilgili ihlal yaşamış, yalnızca %24'ü olağandışı giriş denemelerini sürekli izliyor. Merkezi bir kimlik sağlayıcıya doğru protokolle bağlanmayan uygulamalar bu izlemenin dışında kalır.
Microsoft Dijital Savunma Raporu 2025 ise kimlik saldırılarının %97'sinden fazlasının parola saldırısı olduğunu söylüyor. SSO'nun asıl değeri, parolayı ve çok faktörlü doğrulamayı tek yerde sertleştirmektir; ikinci faktör seçeneklerini iki adımlı doğrulama (MFA) yazısında karşılaştırdık.
SAML ve OIDC nasıl çalışır?
İki protokolde de roller aynıdır: kimliği doğrulayan kimlik sağlayıcı (IdP, OIDC'de "OpenID Provider") ve bu doğrulamaya güvenen uygulama (SAML'de "Service Provider", OIDC'de "Relying Party"). Fark, bilginin nasıl paketlendiği ve taşındığıdır.
SAML 2.0, OASIS tarafından 2005'te standartlaştırıldı. Kullanıcı uygulamaya geldiğinde tarayıcı kimlik sağlayıcıya yönlendirilir, oturum açılır ve kimlik sağlayıcı imzalı bir XML "assertion" üretir. Bu belge tarayıcı üzerinden (genellikle HTTP-POST ile) uygulamaya taşınır; taraflar önceden metadata dosyaları ve sertifikalar değiş tokuş etmiştir.
OpenID Connect, OpenID Foundation tarafından 2014'te yayımlandı ve OAuth 2.0'ın üzerine bir kimlik katmanı ekler. Önerilen akış, PKCE ile güçlendirilmiş yetkilendirme kodu akışıdır: uygulama kısa ömürlü bir kod alır, bu kodu arka kanaldan ID token (imzalı JWT) ve gerekirse access token ile değiştirir. Uygulama, kimlik sağlayıcının anahtarlarını ve adreslerini standart bir keşif (discovery) adresinden kendisi okur.
Sık yapılan bir karışıklığı da düzeltelim: OAuth 2.0 tek başına kimlik doğrulama protokolü değildir, yetkilendirme protokolüdür. "Bu uygulama benim adıma şu API'ye erişebilir" der, "bu kişi kim" demez. Kimlik bilgisini standart biçimde taşıyan katman OIDC'dir.
SAML OIDC farkı: karşılaştırma tablosu
| Ölçüt | SAML 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Temel | Bağımsız XML standardı | OAuth 2.0 üzerine kimlik katmanı |
| Veri biçimi | İmzalı XML assertion | JSON, imzalı JWT (ID token) |
| Taşıma | Tarayıcı yönlendirmesi, HTTP-POST | Yönlendirme + arka kanal token değişimi |
| Güçlü olduğu yer | Kurumsal web uygulamaları, eski sistemler | Mobil, tek sayfa uygulama, API, yeni geliştirme |
| API erişimi | Doğal karşılığı yok | Access token ile doğal |
| Kurulum | Metadata ve sertifika değişimi | Keşif adresi, istemci kimliği (sunucu tarafı uygulamada gizli anahtar) |
| Anahtar yenileme | Sertifika süresi takip edilmeli | Anahtarlar keşif adresinden otomatik okunur |
| Tipik hata | İmza doğrulamasının eksik yapılması | Yönlendirme adresinin gevşek tanımlanması |
İki protokol de güvenlidir; zayıflık çoğunlukla protokolde değil, uygulamadaki eksik doğrulamadadır. SAML'de imzanın ve hedef kitlenin (audience) her yanıt için doğrulanması, OIDC'de ise yönlendirme adresinin tam eşleşmesi, state ve nonce kontrolü şarttır. OAuth tarafında güncel güvenlik önerilerini derleyen IETF RFC 9700 belgesi, eski "implicit" akışın bırakılmasını öneriyor.
SAML mı OIDC mi: 6 adımlık seçim çerçevesi
- Uygulama envanterini protokole göre çıkarın. Her uygulamanın hangi protokolü desteklediğini, kimlerin kullandığını ve web mi, mobil mi, API mi olduğunu listeleyin.
- Hazır uygulamalarda üreticinin güçlü yolunu seçin. Bir SaaS ürünü iki protokolü de destekliyorsa, üreticinin belgelerinde öne çıkardığı seçeneği, özellikle kullanıcı hazırlama (provisioning) desteğiyle birlikte sunulanı tercih edin.
- Yeni geliştirilen yazılımda OIDC ile başlayın. Web, mobil ve API aynı kimliği paylaşacaksa OIDC tek modelde toplar; SAML'i yalnızca bir müşteri ya da iş ortağı açıkça istiyorsa ekleyin.
- Kimlik sağlayıcıyı iki protokolü de konuşacak şekilde seçin. Karma ortamlarda sorun protokol değil, iki ayrı kimlik kaynağının oluşmasıdır; tek kimlik sağlayıcı iki dili de konuşmalıdır.
- Kullanıcı yaşam döngüsünü ayrıca planlayın. SAML ve OIDC oturum açmayı çözer, hesabı açıp kapatmayı çözmez; bunun için SCIM gibi bir hazırlama (provisioning) standardı ya da entegrasyon gerekir. Çıkış sürecindeki boşlukları işten ayrılan çalışanın erişimi yazısında anlattık.
- Test edin ve kayıt altına alın. Sertifika ve anahtar yenileme tarihlerini takvime koyun, giriş kayıtlarını merkezde toplayın ve kurulumu bir sızma testi kapsamında doğrulatın.
Kısa kural: tarayıcıda açılan hazır kurumsal uygulamada SAML genellikle yeterli ve yaygındır. Mobil uygulama, API ya da sıfırdan yazılım söz konusuysa OIDC daha az sürtünme ve daha temiz bir mimari sunar. Protokolden bağımsız olarak merkezi kimliğin parola politikası kurumsal parola güvenliği ilkelerine uymalıdır.
Digital Bridge'de bu işi nasıl yapıyoruz?
Kimlik federasyonu projesine bir ayar ekranından değil, envanterden başlıyoruz. Hangi sistemin hangi protokolü konuştuğunu, kimlerin nereye eriştiğini ve eski çalışanlara ait açık hesap kalıp kalmadığını birlikte çıkarıyoruz.
- Keşif ve risk değerlendirmesi: Siber güvenlik danışmanlığı kapsamında uygulama envanterini, kimlik sağlayıcı yapısını ve imza/yönlendirme doğrulamalarını inceliyoruz. Bulguları genel KOBİ siber güvenlik kontrol listesi ile birlikte önceliklendiriyoruz.
- Pilot: Önce herkesin kullandığı bir ya da iki uygulamayı seçilen protokolle bağlayıp oturum açma, çıkış ve hesap kapatma senaryolarını gerçek kullanıcılarla deniyoruz.
- Entegrasyon: ERP, İK ya da sahaya özel sistemlerin merkezi kimlikle çalışması için sistem entegrasyonları ve API entegrasyonu hizmetlerimizle bağlantıyı kuruyoruz. Token tabanlı API erişiminin temellerini API entegrasyonu nedir yazısında anlattık.
- Yeni yazılımda baştan tasarım: Geliştirdiğimiz özel web yazılımlarında ve mobil uygulamalarda kimlik katmanını ihtiyaç analizinde planlıyoruz. Hazır paket ile özel yazılım arasındaki kararı özel yazılım mı hazır paket mi rehberinde ele aldık.
Giriş kayıtlarının tutulması ve erişim yetkilerinin belgelenmesi, KVKK'nın 12. maddesi uyarınca alınacak teknik ve idari tedbirler arasında Kişisel Verileri Koruma Kurumu'nun rehberinde de sayılır; hangi kayıtların ne kadar süre tutulacağı ise kurumunuzun kendi değerlendirmesine ve hukuki danışmanlığa göre belirlenmelidir. Bu tarafı KVKK uyum süreci yazımızla birlikte düşünmenizi öneririz. Kategorideki diğer yazılar için siber güvenlik ve KVKK rehberleri sayfasına göz atabilirsiniz.
Smart360 ile e-posta ve dosyada tek kimlik
Tek kimlik ihtiyacı en çok, herkesin her gün açtığı kurumsal e-posta ve dosya paylaşımında hissedilir. Smart360 ailesinde SmartMail (kurumsal e-posta) ve SmartFiles (kurumsal dosya yönetimi) tek kimlikle, yani SmartID ile yönetilir. Çalışan tek parolayla giriş yapar ve ürünler arasında parola sormadan geçer.
Somut bir senaryo düşünelim: bir mali müşavirlik bürosunda bir çalışan ayrılıyor. Yönetici tek işlemle SmartMail ve SmartFiles erişimini birlikte kapatır; departman değişikliğinde ise erişim tüm ürünlerde kendiliğinden güncellenir. Açık oturumlar cihaz bilgisiyle listelenir ve uzaktan kapatılabilir, parola değiştiğinde tüm oturumlar sonlanır.
Giriş ekranlarındaki insan doğrulaması, parola deneme saldırılarını sunucuya ulaşmadan durdurur. SmartID, Smart360 ürünleri arasındaki ortak kimliktir; Smart360'ın kurumunuzdaki diğer uygulamalarla birlikte nasıl konumlanacağını ve dış sistemler için hangi kimlik yapısının gerektiğini ihtiyaç analizinde birlikte netleştiriyoruz.
Sonraki adım
Elinizde SAML ve OIDC seçeneği sunan birkaç uygulama, yeni bir yazılım projesi ya da dağınık bir kimlik düzeni varsa, işe uygulama envanterini birlikte çıkarmakla başlayalım. İletişim sayfamızdan bize ulaşın; mevcut durumunuzu değerlendirip hangi uygulamanın hangi protokolle bağlanacağını ve pilot kapsamını içeren yazılı bir teklif hazırlayalım.