İş uygulamaları için SSO vs sosyal giriş: hangisini ne zaman kullanmalı

SSO ve sosyal giriş basitçe anlatımı

SSO ile sosyal giriş arasındaki fark, kimliğin kime ait olduğu ve erişimi kimin kontrol ettiğiyle ilgilidir.

Kurumsal SSO, uygulamanızın bir şirketin kimlik sağlayıcısına (IdP) güvenmesi demektir. İşveren o IdP'yi yönetir (ör. Okta veya Azure AD / Microsoft Entra ID). Birisi rol değiştirirse, MFA gerektirilirse veya şirketten ayrılırsa IT bunu IdP'de günceller ve uygulamanız buna uyar.

Sosyal giriş (ör. “Google ile giriş”) kullanıcının tercih ettiği kişisel veya genel bir hesapla giriş yapması demektir. Tanıdık ve hızlıdır, ancak genellikle işverenin erişim üzerinde güçlü bir kontrol sahibi olmasını sağlamaz.

Basit bir özet:

• Kurumsal SSO: “Şirketim erişimimi onaylar ve yönetir.”
• Sosyal giriş: “Zaten sahip olduğum bir hesapla hızlıca giriş yapabilirim.”

Kimin oturum açtığı önemlidir. İş gücü kullanıcıları dahili araçları kullanan çalışanlar ve yüklenicilerdir. Müşteri kullanıcıları ise sizden sağlanan bir portalı kullanan müşteriler veya ortaklardır. Birçok iş uygulaması her iki kullanıcı tipine de sahip olabilir ve genellikle aynı giriş kurallarına ihtiyaç duymazlar.

Örnek: Bir satış ekibinin dahili CRM'si genellikle IT'nin MFA uygulayabilmesi ve erişimi iptal edebilmesi için Okta veya Azure AD gerektirebilir. Küçük bir müşteri odaklı rezervasyon uygulaması ise Google ile girişle başlanabilir.

Bu rehber, erişim kontrolü, denetlenebilirlik ve offboarding'in önemli olduğu iş uygulamalarına odaklanır.

Kimin giriş yaptığı: çalışanlar, müşteriler veya her ikisi

SSO ile sosyal giriş arasında seçim yapmadan önce uygulamayı kimin kullanacağını açıkça belirleyin. Aynı ürün, dahili araç, müşteri portalı veya her ikisi olup olmadığına göre çok farklı giriş ihtiyaçlarına sahip olabilir.

İş gücü uygulamaları (dahili araçlar) için kullanıcılar genellikle çalışanlar, yükleniciler ve bazen ortaklardır. Zaten bir şirket girişi ve güvenlik kuralları vardır. Pratikte IT şunları bekler:

• erişimi merkezi olarak kontrol etmek
• birisi ayrıldığında erişimi hızla kaldırmak
• MFA ve cihaz/konum kurallarını uygulamak

B2B SaaS için her müşteri şirketin kendi IdP'si olabilir. Birinde Okta var, diğerinde Azure AD, küçük birinde hiç kurumsal SSO yok. Giriş akışınız, insanları veya verileri karıştırmadan şirketler arasında çalışmak zorunda.

B2C uygulamalarda ve basit müşteri portallarında çoğu kullanıcının bir iş IdP'si yoktur. Hız ve tanıdıklık isterler; bu nedenle sosyal giriş veya e-posta ile giriş genellikle varsayılan olur.

Yaygın bir karışık düzen:

• Yönetici ve dahili personel iş gücü SSO kullanır
• Müşteri son kullanıcıları sosyal giriş veya e-posta kullanır
• Müşteri IT yöneticileri hesap büyüdükçe SSO ekler

Kurumsal SSO'nun zorunlu olduğu durumlar

Bazı ekipler sosyal giriş ile başlayıp sonra SSO ekleyebilir. Diğerleri ise IT ve uyumluluk gereksinimleri nedeniyle baştan kurumsal kimliği desteklemeden ilerleyemez.

Kurumsal SSO, girişlerin kişisel tercihler yerine şirket politikalarına uymasının gerektiği durumlarda zorunludur.

Kurumsal SSO gerektiğini gösteren işaretler

Bu gereksinimler genelde güvenlik anketlerinde, dahili IT standartlarında ve kurumsal satış görüşmelerinde çıkar:

• Denetim ve uyumluluk kanıtı: oturum açma günlükleri, erişim gözden geçirmeleri ve net kontroller (SOC 2 veya ISO 27001 gibi programlar için yaygın).
• Merkezi offboarding: IdP'de bir kullanıcı devre dışı bırakıldığında her yerden erişim hızla kesilmelidir.
• Şirket tarafından yönetilen MFA ve koşullu erişim: “güvenilen ağların dışındaysa MFA gerektir” veya “riskli oturumları engelle” gibi kurallar.
• Grup tabanlı erişim: izinlerin tek tek kullanıcıya atanmaması, dizin gruplarına (Finans, Destek, Yönetici) bağlı olması.

Klasik bir senaryo: Bir müşteri uygulamanızı 800 çalışanla kullanıma açmak ister. 800 ayrı hesap oluşturmayacaklar ve “her kullanıcının MFA'yı kendisinin kurması”nı kabul etmeyecekler. Erişimi tek yerde kontrol etmeyi ve kimin, ne zaman erişimi olduğunu cevaplayabilmeyi beklerler.

Bir dahili araç veya B2B portalı inşa ediyorsanız, güvenlik incelemeleri ve onboarding son dakikada sorun olmasın diye kurumsal SSO'yu erken planlayın.

“Google ile giriş” ne zaman yeterlidir

Birçok iş uygulaması için sosyal giriş doğru başlangıçtır. Kullanıcılar bir IT departmanına sahip olmayan bireyler veya küçük takımlarsa, Okta veya Azure AD gerektirmek ürünü denemelerini engelleyebilir.

“Google ile giriş” genellikle risk düşük ve uygulama kritik sistemleri kontrol etmiyorsa yeterlidir. Düşünün: temel bir müşteri portalı, hafif bir işbirliği alanı veya erişimin gayri resmi olarak yönetildiği küçük bir işletmenin dahili aracı.

Büyük avantajı onboarding hızıdır. Kullanıcılar saniyeler içinde hesap oluşturur, daha az parola unutma yaşanır ve daha az destek talebi gelir.

Sosyal giriş olsa bile uygulama içinde güvenliği artırabilirsiniz:

• hassas işlemler (faturalama, dışa aktarma) için yeniden kimlik doğrulama isteyin
• yeni bir cihazda doğrulamayı artırın
• yönetici ekranları için oturum zaman aşımı zorunlu kılın

Pratik bir kural: müşteriler çoğunlukla küçük takımlarsa ve veriler çok hassas değilse, şimdi sosyal girişle başlayın ve ileride kurumsal SSO eklemeye alan bırakın.

Bilmeniz gereken Okta ve Azure AD temelleri

Okta ve Azure AD (Microsoft Entra ID), kurumsal girişte en çok duyacağınız iki isimdir. Bunlar yalnızca kaydolmayı kolaylaştırmak değil; çalışanlar, politikalar ve IT kontrolü ile ilgilidir.

Okta, işe alım/çıkarma, grup kuralları ve erişim gözden geçirmeleri gibi güçlü yaşam döngüsü yönetimi isteyen orta- ve büyük ölçekli takımlarda yaygındır.

Azure AD (Entra ID), Microsoft 365 standartsa hemen her yerde görünür. Birçok şirket zaten kullanıcıları, grupları ve güvenlik politikalarını burada tuttuğu için uygulamanızı eklemek çoğunlukla admin konsolunda başka bir “kurumsal uygulama” olarak ele alınır.

SAML vs OIDC (pratik fark)

SAML daha eski ve kurumsal SSO için yaygın. XML ve sertifikalara dayanır, idari hissettirir.

OIDC (OAuth 2.0 üzerine kurulu) modern web ve mobil uygulamalar için genelde daha kolaydır çünkü JSON tabanlıdır ve API'ler ve tokenlarla temiz çalışır.

Müşterilerin sizden isteyeceği bilgiler

Bir IT ekibi SSO kurarken genellikle birkaç kesin detayı ister:

• SAML: ACS URL, Entity ID, sertifika veya imzalama detayları
• OIDC: redirect URI'ler, client ID ve bazen logout redirect detayları
• Claims (öznitelikler): e-posta, isim, grup veya rol bilgisi ve sabit bir kullanıcı kimliği
• Tenant yönlendirmesi: doğru şirketin doğru bağlantıyı kullanması için izin verilen domainler veya tenant tanımlayıcıları

Grup-rol eşleme sözü vermeden önce müşterilerinizin göndereceği claim'leri güvenilir şekilde eşleyebildiğinizden emin olun.

Bir kimlik modeli seçmek: tek şirket mi yoksa çoklu tenant mı

Özellikleri seçmeden önce uygulamanızın şeklini seçin. Kilit soru, tek bir organizasyon mu bir IdP ile yoksa her müşterinin kendi IdP'sine sahip olduğu çoklu organizasyon mu olduğudur.

Tek tenantlı iç uygulama (sadece sizin şirketiniz kullanıyorsa) basit tutun: bir IdP bağlantısı, bir dizi erişim kuralı ve net bir işe-alma/ayrılma süreci.

Çok tenantlı B2B uygulama inşa ediyorsanız her müşterinin farklı ayar isteyeceğini varsayın. Bu genelde şunları gerektirir:

• her tenantın kendi SSO bağlantısı ve rol eşlemesi
• kullanıcıların e-posta domainine veya şirket seçimlerine göre yönlendirilmesi
• kişisel e-postaların tenant bazında izin verilip engellenmesi
• denetim günlükleri ve yönetici kontrollerinin tenant bazında ayrılması

Ayrıca bir tenant SSO'yu kullanımdayken açtığında ne olacağına dair bir planınız olsun. Yaygın yaklaşımlar: SSO'yu zorunlu kılma, kısa bir geçiş penceresi bırakma veya yükleniciler ve acil erişim için az sayıda non-SSO hesabı tutma.

IdP kesintisini de planlayın. Tenant yöneticilerinin erişimi güvenli şekilde geri alabileceği yollar (break-glass yönetici hesabı veya güçlü doğrulamaya sahip zaman sınırlı kurtarma kodları) olmalı.

Hem SSO hem sosyal girişi çakışma olmadan destekleme

Kurumsal SSO ve sosyal girişi birlikte desteklemek yaygındır. E-posta "tek gerçek kimlik" olarak ele alındığında işler karışır. Daha temiz yaklaşım: bir kullanıcı kaydı, birçok giriş kimliği.

Çoğalmayı önleyen veri modeli

Kullanıcıları giriş yöntemlerinden ayrı saklayın. Basit bir desen: bir User kaydı artı her sağlayıcı için bir Identity kaydı.

Her Identity şu iki alanla benzersiz olmalı:

• sağlayıcı adı (Google, Okta, Azure AD)
• sağlayıcının konu tanımlayıcısı (çoğunlukla sub)

Bu subject (konu) tanımlayıcı sabittir. E-posta sabit değildir. E-postalar değişir, yeniden kullanılabilir ve paylaşılıyor olabilir (örn. support@). E-postayı birincil anahtar değil, bir öznitelik olarak ele alın.

Güvenli bir bağlama akışı

Bağlama yalnızca net onay ile gerçekleşmeli:

1. Kullanıcı yöntem B ile (ör. Okta) oturum açar ve sağlayıcı + sub alırsınız.
2. O Identity varsa, oturum açtırın.
3. Yoksa, doğrulanmış e-posta ile eşleşen bir kullanıcı arayın ama otomatik birleştirme yapmayın.
4. Kullanıcıdan bağlamayı onaylamasını isteyin ve kanıt (zaten A yöntemiyle oturum açmış olmak, taze yeniden kimlik doğrulama veya tek kullanımlık kod) talep edin.
5. Aynı User'a işaret eden yeni Identity kaydını oluşturun.

E-posta çakışmaları çift hesapların doğduğu yerdir. E-posta yalnızca doğrulanmış ve kullanıcı açıkça onaylarsa bağlayın.

Kimlikleri bağlarken güvenlik tuzakları

E-postaya göre otomatik bağlama yapmak, bir saldırganın bir başkasının hesabını ele geçirmesinin en hızlı yoludur.

Yaygın bir hata: saldırgan, kurbanın iş e-postasını kullanarak bir sosyal hesap oluşturur, sosyal girişle oturum açar ve uygulamanız e-postayı sahiplik kanıtı saydığı için kurbanın mevcut hesabına birleştirir.

Bağlama için daha güvenli kurallar

Bağlamayı hassas bir hesap değişikliği gibi ele alın:

• sağlayıcı tarafından e-posta doğrulanmış ve uygulamanızda teyit edilmişse bağlayın
• bağlama için ek bir meydan okuma gerektirin (tek kullanımlık kod, yönetici onayı veya zaten oturum açılmış bir oturumdan başlatma)
• domain kurallarını dikkatli kullanın (otomatik bağlama yalnızca onaylı kurumsal domainler için, ücretsiz e-posta domainleri için değil)
• e-posta değişikliklerinin taze doğrulama olmadan bağlamayı tetiklemesine izin vermeyin

Denetim izlerini atlamayın

Kimlik değişiklikleri kolayca gözden kaçabilir ve sonradan soruşturması zor olabilir. Bağlama ve bağlantı kaldırma olaylarını, yeni SSO bağlantılarını, başarısız denemeleri ve olağan dışı desenleri (ör. yüksek ayrıcalıklı rol için ilk SSO oturumu) kaydedin.

Kimin neyi ne zaman ve neden bağladığını açıklayamıyorsanız, bağlama akışınız hazır değildir.

Adım adım: iş uygulamasına SSO + sosyal giriş uygulamak

Hem kurumsal SSO hem sosyal girişi desteklemek çoğunlukla veri modeli ve akış tasarımı meselesidir.

1) Temel kullanıcı kaydınızı tasarlayın

Bir kullanıcıyı uygulamanız içinde “aynı kişi” yapan şeyin ne olduğunu belirleyin. Çoğu iş uygulamasında bir kullanıcı bir tenant (şirket/workspace) ait olur ve orada roller veya izinlere sahiptir.

Bu alanları sabit tutun: tenant/workspace ID, iç kullanıcı ID'si, durum (aktif/devre dışı) ve rol(ler). E-postayı iletişim bilgisi olarak ele alın.

2) Harici kimlik haritası ekleyin

Sağlayıcılardan gelen girişleri saklamak için ayrı bir yer oluşturun. Her kayıt sağlayıcı (Okta, Azure AD, Google), sağlayıcının benzersiz kullanıcı ID'si (subject), girişte gözlemlenen e-posta ve zaman damgalarını içermeli.

3) Temel akışları kurun: giriş, bağlama, bağlantıyı kaldırma, kurtarma

Bunların uçtan uca tasarlandığından emin olun:

• Giriş: sağlayıcı + subject ile dış kimliği bulun, sonra iç kullanıcıyı yükleyin
• İlk giriş: bir kullanıcı oluşturun (veya davet gerektir) ve yeni dış kimliği iliştirin
• Bağlama: başka bir sağlayıcıyı yalnızca yeniden kontrol sonrası bağlayın
• Bağlantıyı kaldırma: başka bir oturum açma yöntemi kaldığında sağlayıcıyı kaldırmaya izin verin
• Kurtarma: “SSO erişimi kayboldu” durumunu kontrollü bir geri dönüşle ele alın

4) Yayına almadan önce tenantlar arası test edin

Bir Okta tenantı, bir Azure AD tenantı ve Google ile test edin. Doğrulayın ki:

• aynı e-posta iki farklı şirkette çakışma yaratmıyor
• upstream'de e-posta değişikliği ikinci bir hesap oluşturmuyor

5) Güvenli şekilde dağıtın

Bir enterprise tenant ile pilot yapın. Ardından SSO zorunlu politikalarını tenant bazlı, global değil, olarak uygulayın.

Takımın sık yaptığı hatalar

Sorunların çoğu giriş ekranındaki butonlardan değil; arkadaki kimlik kurallarından kaynaklanır.

E-postayı kullanıcı ID'si saymak sık yapılan bir hatadır. E-postalar değişir, aliaslar yeniden kullanılabilir ve bazı sağlayıcılar sabit bir e-posta claim'i garanti etmez. Sabit bir iç kullanıcı ID'si kullanın ve sağlayıcı tanımlayıcılarını ayrı, benzersiz anahtarlar olarak saklayın.

Offboarding de takımların zorlandığı bir alandır. Birisi Okta veya Azure AD'den kaldırıldıysa uygulamanızda sonsuza dek aktif kalmamalıdır. Girişte erişimi yeniden kontrol edin ve IdP kullanıcıyı kaldırdığında kullanıcıyı askıya alma yolu sağlayın.

Tekrarlanan diğer hatalar:

• E-postalar eşleşti diye şirketleri karıştıracak şekilde hesapları bağlamak
• IdP kesintisi veya yanlış yapılandırma planı olmaması, kullanıcıların erişimi kaybetmesi
• SSO'yu açıp diğer tüm giriş yollarını güvenli admin kurtarma olmadan kaldırmak
• Kullanıcıların giriş yöntemini yanlış workspace'e bağlamasına izin vermek ve sonra ayırmakta zorlanmak
• Girişler ve kimlik değişiklikleri için denetim günlüklerini atlamak, olayların açıklanmasını zorlaştırmak

Örnek: Bir yüklenici Google ile Client A workspace'ine girer. Sonra Client B'ye katılır ve Azure AD gerekir. Eğer otomatik e-posta birleştirme yaparsanız, yüklenici yanlış tenantta erişime sahip olabilir. Bağlamayı açıkça oturum açılmışken gerektirin ve kimlikleri tenant kapsamına göre tutun.

Yayına almadan önce hızlı kontrol listesi

Çoğu kimlik sorunu ilk günden sonra çıkar: yeni bir IT politikası, bir çalışan ayrılması veya farklı bir sağlayıcıyla giriş denemesi.

Yayın öncesi doğrulayın:

• Tenant kontrolleri: bir admin kendi şirketi için SSO'yu zorunlu kılıp diğer yöntemleri kapatabiliyor mu?
• Provisioning ve roller: ilk girişte kullanıcı oluşturma ve grup tabanlı rol eşleme (özellikle gruplardan) destekleniyor mu?
• Kimlik değişiklikleri ve offboarding: bir kullanıcının e-postası değiştiğinde veya IdP'de devre dışı bırakıldığında uygulamanızda ne oluyor?
• Denetim kanıtı: kim oturum açtı, başarısız denemeler ve link/unlink olayları kim tarafından başlatıldı kaydediliyor mu?
• Kurtarma: SSO yanlış yapılandırıldığında veya geçici olarak çalışmadığında güvenli bir break-glass yolu var mı?

Bunları küçük auth ayrıntıları değil, ürün gereksinimleri olarak ele alın.

Gerçekçi bir örnek: yayına aldıktan sonra SSO eklemek

Sosyal girişle hızlı başladınız çünkü çabuk ve tanıdıktı. Altı ay sonra daha büyük bir müşteri Azure AD üzerinden erişim isteyebilir.

En güvenli yükseltme, mevcut girişleri bozmadan kurumsal SSO eklemektir. “Kullanıcının kim olduğu” ile “nasıl giriş yaptığı”nı ayrı tutun. Bir kullanıcı hesabı birden fazla bağlı kimliğe (Google, Azure AD, e-posta-parola) sahip olabilir. Bu, çift hesaptan kaçınmanın yoludur.

Basit bir geçiş adımı:

• SSO'yu yeni bir giriş seçeneği olarak ekleyin, geçiş boyunca Google'ı açık tutun.
• İlk Azure AD oturum açışında doğrulanmış e-posta ile mevcut hesabı arayın.
• Eşleşirse Azure AD kimliğini o kullanıcıya bağlayın.
• Eşleşmezse yönetici onaylı bir davet isteyin.

Bağlama sonrası müşteri tenant bazlı “yalnızca SSO” politikası koyabilir. Kullanıcıların verileri ve izinleri aynı kalır; sadece giriş yöntemi değişir.

Uygulamanız için sonraki adımlar

Gün birinde kullanıcılarınızın neye ihtiyacı olduğuna göre başlayın. Yalnızca bireysel müşterileriniz varsa sosyal giriş yeterli olabilir. Şirketlere satıyorsanız, her tenant için kurumsal SSO'yu planlayın; her müşteride hemen açmasanız bile hazırlıklı olun.

Arayüz ve roller inşa etmeden önce kimlik kurallarınızı yazın. Detaylar kusursuz olmak zorunda değil ama tutarlı olmalı.

Çoğu iş uygulaması için işe yarayan basit plan:

• kullanıcı tiplerini eşle (çalışanlar, müşteri kullanıcıları, yöneticiler, destek, ortaklar)
• tenant bazında ne sunulacağına karar ver (şifre, sosyal, kurumsal SSO veya karışım)
• bağlama kurallarını tanımla (ne zaman birleştir, ne zaman engelle, ne zaman onay iste)
• offboarding davranışını tanımla (SSO kullanıcısı devre dışı kaldığında ne olur)
• kurtarmayı tanımla (IdP değişirse veya başarısız olursa erişim nasıl geri alınır)

AppMaster gibi no-code bir platformda (appmaster.io) inşa ediyorsanız, kullanıcıları, tenantları, rolleri ve ayrı bir kimlik tablosunu erken modellemek faydalıdır. Bu yapı ile Okta veya Azure AD eklemek genelde yeniden tasarımdan çok eşleme ve yapılandırma işidir.

Son kontrol: Bir kişi bugün Google ile oturum açıp sonra bir şirket tenantına katıldığında kurumsal SSO kullanabiliyor mu, ikinci bir hesap oluşturmadan? Cevap hayırsa, gönderimden önce bağlama akışlarını düzeltin.