Kurumsal müşteriler neden SSO ister?\n\nBir anlaşma "takım denemesi" aşamasından şirket genelinde bir dağıtıma geldikten sonra SSO acil hale gelir. Alıcı ürününüzü sevebilir ama güvenlik ve BT, çalışanların yeni parolalar oluşturması, başka bir yerde MFA yönetmesi veya kişiler roller değiştiğinde hesapları arkada bırakması gerekiyorsa tedariki durdurur.\n\nBirçok kurumsal için SSO konfor meselesinden çok kontrol meselesidir. Giriş kurallarını tek bir yerde uygulamak, erişimi hızlıca iptal etmek ve denetçilere kimliğin merkezi olarak yönetildiğini göstermek isterler. Bu yüzden "OAuth vs SAML for SSO" sorusu satış sürecinin geç döneminde çıkar: kimlik kurulumlarına uyup uymadığınızı çabucak kontrol etmenin bir yoludur.\n\nSSO'yu sonradan eklemek halihazırda dayandığınız varsayımları bozabilir. Mevcut modeliniz "bir e‑posta = bir kullanıcı" ise, SSO paylaşılan takma adlar, birden fazla kimlik sağlayıcı veya geçiş sırasında hem parola hem de SSO'yu korumak zorunda olan kullanıcılar gibi uç durumlar getirir. Hesap bağlama yanlışsa, insanlar erişimini kaybeder veya daha kötüsü yanlış tenant'a erişim kazanır.\n\nSSO ayrıca onboarding ve desteği değiştirir. Doğru yapıldığında parola sıfırlamaları ve "bu hesabın sahibi kim?" ticket'ları azalır. Kötü yapıldığında ise dağıtımlar takılır, yöneticiler sinirlenir ve ürün "denemede çalıştı" ama kurumsal dağıtımın ilk gününde başarısız olduğu için yenilemeler riskli hale gelir.\n\nKarar nadiren tek kişiye aittir. Alıcı ivme ister, güvenlik denetimleri risk ve denetim ihtiyaçlarını kontrol eder, BT yöneticileri net kurulum adımlarına ihtiyaç duyar, son kullanıcılar sorunsuz bir giriş ister ve destek kilitlenmeler, geçişler ve istisnalarla ilgilenir.\n\nKoder.ai gibi platformlarda uygulama inşa ediyorsanız, müşteriler zaten aktifken kimlik sistemini yeniden tasarlamanız gerekmesin diye SSO'yu erken planlamak yardımcı olur.\n\n## Ana terimler, jargondan uzak\n\nSSO (single sign-on), müşterinizin uygulamanıza sizin sakladığınız ayrı bir parola ile değil, şirket oturumu ile giriş yapması demektir. İş hesabıyla oturum açarlar ve erişim şirket politikasıyla kontrol edilir.\n\nKurumsal görüşmelerde duyacağınız terimler:\n\n- IdP (Identity Provider): kullanıcıyı doğrulayan şirket sistemi (örneğin Okta veya Microsoft Entra ID).\n- SP (Service Provider): sizin uygulamanız. IdP'nin kullanıcıyı doğruladığına güvenirsiniz.\n- Directory: şirket IdP içindeki kullanıcı ve grup listesi.\n- Tenant: uygulamanızdaki bir müşteri alanı (bir şirket). SSO genellikle tenant bazında yapılandırılır.\n- Domain: şirket e‑posta domaini (ör. @acme.com). Birçok ürün kullanıcıları doğru tenant ve giriş yöntemine yönlendirmek için bunu kullanır.\n\nİnsanlar "OAuth login" dediğinde genellikle OpenID Connect (OIDC)'i kastediyorlar. OAuth esasen yetkilendirme (bir şeye erişim izni) ile ilgilidir. OIDC kimlik doğrulamayı (kullanıcının kim olduğu) ekler, bu yüzden oturum açma için kullanılabilir.\n\nSAML daha eski, XML tabanlı bir SSO standardıdır. Kurumsallar hâlâ yoğun şekilde kullanır çünkü kanıtlanmış, IdP'ler tarafından geniş desteklenir ve birçok uyumluluk kontrol listesine dahil edilmiştir.\n\nSCIM SSO değildir. SCIM, kullanıcıları (ve bazen grupları) otomatik oluşturmaya, güncellemeye ve devre dışı bırakmaya yarar. Yaygın bir kurulum, giriş için SAML veya OIDC ve erişimin manuel yönetim gerektirmeden eklenip kaldırılmasını sağlamak için SCIM'dir.\n\n## Kurumsallar gerçekte ne ister?\n\nKurumsal alıcılar genellikle protokol detaylarıyla başlamaz. Risk ve kontrol ile başlarlar: "Erişimi bizim IdP'mizden yönetebilir miyiz ve kim ne yaptı bunu ispatlayabilir miyiz?"\n\n### İlk aşamada beklentileri\n\nÇoğu kurumsal ekip en az bir kurumsala uygun seçenek ister ve birçoğu her ikisini de ister:\n\n- IdP'lerinin kaynak olarak kullanılabilmesi için SAML 2.0 ve/veya OIDC giriş desteği\n- MFA'nın IdP tarafında yönetilmesi (ayrı bir MFA hikayesi istemezler)\n- E‑posta, değişmeyen bir kullanıcı kimliği ve isteğe bağlı grup/rol beyanları gibi net bir kimlik eşleme planı\n- Çoklu organizasyonlar ve birden fazla IdP bağlantısı için plan (büyük şirketlerde yaygın)\n\nAyrıca kurulumun nasıl çalıştığını soracaklar: metadata veya keşif URL'si, sertifika rotasyonu ve BT'nin mühendislerinize bağlı kalmadan self‑serve yapıp yapamayacağı.\n\n### Kullanıcı yaşam döngüsü, denetim ve risk kontrolleri\n\nBir kurumsal anlaşmasını kaybetmenin en hızlı yolu offboarding konusunda belirsiz olmaktır. Bir çalışan ayrıldığında, departman değiştirdiğinde veya laptopunu kaybettiğinde ne olduğuna dair net bir plan isteyecekler.\n\nBeklemeniz gereken sorular:\n\n- Bir kullanıcı IdP'de devre dışı bırakılırsa erişim hızlıca kesiliyor mu ve mevcut oturumlara ne oluyor?\n- SCIM desteğiniz var mı? Yoksa geri plan ne (davet akışları, JIT provisioning, yönetici tarafından yönetilen kullanıcılar)?\n- Hangi denetim verileri mevcut: oturum geçmişi, SSO olayları, yönetici eylemleri ve dışa aktarılabilir loglar\n- Hangi oturum ve erişim kuralları var: zaman aşımı, yeniden kimlik doğrulama sıklığı, IP izin listeleri ve bazen IdP üzerinden cihaz güveni\n\nOnların önem verdiği basit bir senaryo: bir yönetici bir kullanıcıyı 09:02'de devre dışı bırakıyor ve 09:03'te o kullanıcının uygulamayı açamaması gerekiyor, tarayıcı sekmesi açık olsa bile. Bu akışı net olarak açıklayamıyorsanız, ekstra inceleme turu bekleyin.\n\n## B2B oturum açma için OAuth ve OIDC nasıl çalışır\n\nOAuth başlangıçta temsilci erişimi için inşa edildi: bir sistemin parola paylaşmadan başka bir sistemin API'sini çağırmasına izin vermek. Birçok ekip bunu hâlâ entegrasyonlar için kullanıyor (ör. takvim okuma). Çalışan oturumu için çoğu ürün OpenID Connect (OIDC) kullanır; OIDC OAuth'un üstüne standart bir kullanıcı doğrulama yöntemi ekler.\n\nOIDC ile yaygın kurulum authorization code flow'dur. Uygulamanız kullanıcıyı şirketin IdP'sine yönlendirir. Başarılı girişten sonra IdP uygulamanıza kısa ömürlü bir authorization code gönderir. Sunucunuz bu kodu tokenlar için değiş tokuş eder.\n\nÖnemli token ayrımı:\n\n- ID token: kullanıcının kim olduğu (oturum oluşturmak için kullanılır)\n- Access token: uygulamanızın hangi API'leri çağırabileceği (API çağrıları için kullanılır)\n\nOAuth vs SAML arasındaki pratik düşünce: OIDC, web, mobil ve API desenleriyle uyumlu modern bir giriş istediğinizde harikadır. SAML, kurumsal taraf klasik "uygulamaya giriş" el sıkışmasını istediğinde ve API erişimi konusunda daha az endişeliyse daha yaygındır.\n\nSaklamanız gerekenler basit olmalı: kullanıcının sabit tanımlayıcısı (subject), e‑postası (verildiyse) ve kullandığı tenant bağlantısı. Kullanıcının parolasını saklamayın. Ayrıca offline API erişimi gerçekten gerekli değilse uzun ömürlü refresh tokenları saklamaktan kaçının.\n\nHer müşteri tenant'ı için ihtiyacınız olacaklar:\n\n- Redirect URI'ler (tam eşleşmeler)\n- Client ID ve client secret (veya bir özel anahtar)\n- Minimal scope'lar (genellikle: openid, email, profile)\n- IdP kimliğinden iç kullanıcıya eşleme kuralı\n- "Bu oturum hangi tenant içindir?" adımı (domain yönlendirme, davet veya tenant seçme adımı)\n\nDoğru yapıldığında, kullanıcı uygulamaya geri gelir, tokenları doğrularsınız ve tüm kimlik modelinizi baştan yazmadan normal oturumu oluşturursunuz.\n\n## Gerçek ürünlerde SAML SSO nasıl çalışır\n\nSAML, kurumsal IdP'nin uygulamanıza "bu kişi zaten giriş yaptı, işte bilgileri" demesini sağlar. IdP bir SAML assertion gönderir; bu, kullanıcının kim olduğunu (ve bazen grup veya rol bilgisini) ve kısa bir geçerlilik süresini içeren imzalı bir nottur.\n\nBu notu güvenilir kılmak için SAML metadata ve sertifikalara dayanır. Metadata, uç noktaları ve anahtarları tanımlayan küçük bir yapılandırma paketidir. Sertifikalar çoğunlukla imzalama içindir; uygulamanız assertion'ın gerçekten müşterinin IdP'sinden geldiğini ve değiştirilmediğini doğrulayabilsin.\n\nNeredeyse her kurulumda iki tanımlayıcı çıkar:\n\n- ACS URL: IdP'nin assertion'ı post ettiği yer (SAML inbox'ınız)\n- Entity ID: uygulamanızın IdP'ye nasıl kendisini tanıttığı (SAML adı)\n\nBunlardan herhangi biri yanlışsa, her şey doğru görünse bile giriş başarısız olur.\n\nGerçek dünya SAML'ı koddan çok operasyon işi yapar. Tenant düzeyinde SAML ayarlarına, kesintisiz sertifika rotasyonuna, saat farkına (birkaç dakika bile assertion'ları bozabilir) ve yöneticiler için net hatalara (sadece "invalid response" değil) hazırlanın.\n\nYaygın bir desen: müşteri yöneticisi tenant başına SAML'i etkinleştirir, uygulamanız imzayı doğrular, assertion'ın süresinin dolmadığını kontrol eder ve e‑postayı (veya NameID'yi) mevcut bir kullanıcıya veya güvenli otomatik oluşturma kuralına eşler. Pratikte, bu OAuth vs SAML kararının kalbidir: SAML genellikle sizi daha güçlü yönetici iş akışları inşa etmeye zorlar.\n\n## OAuth vs SAML: tahmin etmeden nasıl seçilir\n\nOIDC ile SAML arasındaki seçim çoğunlukla alıcının zaten ne kullandığıyla ilgilidir. Birçok B2B uygulama zamanla her ikisini de desteklemeye başlar, ama yine de her müşteri için temiz bir karar verip kimlik sisteminizi öngörülebilir tutabilirsiniz.\n\nOIDC modern uygulamalar için genelde daha sorunsuzdur. Tarayıcı ve mobil uygulamalarla, API'lerle güzel çalışır ve genellikle hata ayıklaması ve genişletmesi (scope'lar, token süreleri vb.) daha kolaydır. Müşterinin IdP'si modern OIDC kurulumuna uygunsa ve BT ekibi OIDC ile rahatsa, öncelik OIDC olmalıdır.\n\nSAML vazgeçilmez olabilir. Birçok büyük şirketin SAML politikaları ve tedarik kuralları vardır: "sadece SAML." Bu durumda en iyi yaklaşım kontrollü bir şekilde SAML'i bir kez uygulayıp bunu diğer oturum modellerinden izole tutmaktır.\n\nKarar vermeden önce sorulacaklar:\n\n- Hangi IdP'yi kullanacaklar (Okta, Entra ID, Google Workspace, Ping, ADFS)?\n- SAML mi istiyorlar yoksa OIDC kabul ediliyor mu?\n- Şimdi SCIM provisioning gerekli mi, sonra mı?\n- IdP'de step‑up MFA politikaları istiyorlar mı?\n- Kullanıcı yaşam döngüsünün sahibi kim: onların BT ekibi mi yoksa sizin yöneticileriniz mi?\n\nHızlı bir karar rehberi:\n\n| If the customer says... | Prefer | Why |\n|---|---|---|\n| "We use Entra ID and want a modern app integration" | OIDC | Web ve API akışlarına daha uygun |\n| "Our policy is SAML only for vendors" | SAML | Güvenlik onboarding'i geçmek için gerekli |\n| "We need both for different subsidiaries" | Both | Büyük kuruluşlarda yaygın |\n| "We need custom claims per app" | Either | Her ikisi de öznitelik eşlemeyi destekler |\n\nHer iki yöntemi de destekliyorsanız, uygulamanın geri kalanını tutarlı tutun: tek bir iç kullanıcı modeli, tek bir oturum modeli ve tek bir yetkilendirme seti. SSO yöntemi "bu kullanıcı kim ve hangi tenant'a ait" sorusuna cevap vermeli, erişimin nasıl çalıştığını yeniden yazmamalıdır.\n\n## Adım adım: mevcut kimliği bozmadan SSO ekleyin\n\nÖnce ürününüzde "tenant"ın ne anlama geldiğini tanımlayın. Çoğu B2B uygulamada SSO, kullanıcı başına değil organizasyon veya workspace başına yapılandırılır. Bu seçim IdP ayarlarını nerede saklayacağınızı, kimin değiştirebileceğini ve kullanıcıların workspace'ler arasında nasıl hareket edeceğini belirler.\n\nSonra tahmin edilebilir bir giriş davranışı seçin. E‑posta domain yönlendirmesi (e‑posta yazın, eğer domain SSO etkinse yönlendir) kafa karışıklığını azaltır ama yükleniciler ve çoklu domainli şirketler gibi uç durumları yönetmelisiniz. Basit bir "SSO ile devam et" butonu daha anlaşılırdır ama kullanıcı yanlış seçimi yapabilir.\n\nOIDC veya SAML için güvenli bir inşa sırası:\n\n- Tenant‑to‑SSO eşlemesini tanımlayın: bir workspace, bir IdP yapılandırması ve izin verilen e‑posta domainleri.\n- Hesap bağlama kuralları ekleyin: e‑postaya göre dikkatli eşleme, doğrulanmış domain gerektirme ve e‑postalar değiştiğinde davet tabanlı bağlantı desteği.\n- SSO'yu tenant başına isteğe bağlı yapın: tenant kararlı hale gelene kadar parola veya magic‑link girişini açık tutun.\n- Yönetici kontrolleri ekleyin: kimin SSO'yu etkinleştirebileceği, SSO gerektirme seçeneği ve bir break‑glass yerel yöneticisi.\n- Geri alma oluşturun: tenant için SSO'yu diğerlerini etkilemeden devre dışı bırakacak tek bir anahtar.\n\nTest etmek zorunludur. Sandbox bir IdP ve gerçekçi domainlere sahip staging tenantı kullanın. Mutlu yol ve hata durumlarını çalıştırın: süresi dolmuş sertifika, yanlış audience, saat farkı, IdP'den kaldırılmış kullanıcı. SSO dağıtımını bir feature flag gibi ele alın.\n\nKoder.ai gibi platformlar, tenant başına yapılandırma ve anlık görüntü/geri alma desteğiyle bu tür yinelemeyi kolaylaştırır; böylece kötü bir değişiklik tüm müşterileri kilitlemez.\n\n## İlk günden itibaren ihtiyacınız olan güvenlik ve operasyonlar\n\nSSO sadece bir giriş butonu değildir. Güvenlik ekipleri oturum süresi, offboarding ve bir şeyler ters gittiğinde kanıt ne sunabileceğinizi sorar. SSO'yu çekirdek kimlik sisteminizin parçası olarak (ekstra bir parça değil) ele alırsanız, çoğu acı veren yükseltmeyi önlersiniz.\n\nİlk olarak oturum kurallarını belirleyin. Boşta kalma zaman aşımı ve mutlak oturum ömrü seçin ve birinin laptopunu kapatıp ertesi gün geri geldiğinde ne olacağını açıkça belirtin. OIDC ile refresh tokenlar oturumları beklenmedik şekilde uzatabilir; kullanıyorsanız sınırlar (rotasyon, maksimum yaş) koyun. SAML ile tarayıcı oturumları uzun süre canlı kalabilir; yeniden kimlik doğrulama zorlamak gerekebilir.\n\nÇıkış (logout) başka bir tuzaktır. "Single logout" her IdP tarafından desteklenmez. Uygulama içinde yerel çıkışı güvenilir şekilde destekleyin ve küresel oturum kapatmanın IdP'ye bağlı olduğunu belgeleyin.\n\nMFA benzer şekilde: kurumlar IdP'de MFA uygulamak ister; uygulamanız, kimliği doğrulanmış kullanıcıyı tekrar sormadan kabul etmelidir. Yine de riskli işlemler (veri dışa aktarma veya fatura değişiklikleri gibi) için adım atma (step‑up) kontrolleri desteklemek faydalıdır; çünkü her IdP politikası mükemmel olmayabilir.\n\nKullanıcı sağlama (provisioning) erişim sızıntılarının olduğu yerdir. JIT provisioning kullanışlıdır ama kimlik doğrulaması yapabilen herkes için hesap oluşturabilir. Davet‑sadece daha güvenlidir ama yönetici işini artırır. Birçok ekip orta yolu seçer: JIT izinli ama izin verilen domainlerle veya (isteğe bağlı) grup beyanlarıyla sınırlı.\n\nSSO yapılandırmasını en az ayrıcalık ilkesine göre erişime açın. Birisi sertifika döndürmek veya IdP URL'sini güncellemek için süper‑admin olmasını gerektirmemeli.\n\nDestek için, gizli bilgileri saklamadan tek bir oturumu izleyebilecek yeterli log tutun:\n\n- Her oturum denemesi için bir istek veya korelasyon ID'si\n- IdP tanımlayıcısı (issuer veya entity ID) ve tenant/organizasyon\n- Token veya assertion meta verisi (zaman damgaları, audience, imzalama algoritması), ham token değil\n- Kullanıcı tanımlayıcıları (subject, e‑posta) ve alınan gruplar veya roller\n- İmza, saat farkı ve beyan eşleme için net hata kodları\n\nBu, "tekrar üretemiyoruz" ile kurumsal bir SSO kesintisini dakika içinde düzeltmek arasındaki farktır.\n\n## Gerçekçi bir örnek: SSO isteğiyle bir anlaşmayı kapamak\n\nOrta ölçekli bir şirket satınalma sürecinde "İmzalamadan önce SSO istiyoruz" der. Bu nadiren felsefi bir taleptir. Onboarding, offboarding ve denetim için ihtiyaç duydukları bir kontroldür.\n\nŞimdi kıvrım: iki ayrı takıma satış yapıyorsunuz. Takım A Okta ile modern uygulamalar için OIDC ile mutlu. Takım B ise miras araçları nedeniyle SAML konusunda ısrarcı. İşte OAuth vs SAML tartışması son bulur ve gerçek bir dağıtım planına dönüşür.\n\nBir kural koyun: SSO tenant başına bir giriş seçeneği olsun, global bir ikame değil. Mevcut kullanıcılar tenant yöneticisi "SSO zorunlu" yapana kadar eski yöntemle giriş yapmaya devam edebilsin.\n\nİlk SSO oturumunda güvenli hesap bağlama gerekir. Temiz bir yaklaşım: doğrulanmış e‑postaya göre eşleme yapın, tenant'ı domaine göre doğrulayın (veya bir davetle) ve sonra IdP kimliğini mevcut kullanıcıya bağlayın. Eşleşme yoksa, yönetici izin verdiyse kullanıcıyı JIT olarak oluşturun.\n\nRol atama genellikle anlaşmaları tıkayan yerdir. Basit tutun: yeni kullanıcılara varsayılan bir rol verin ve isteğe bağlı olarak IdP grup veya beyanlarından role eşleme sağlayın.\n\nYönetici tarafında genellikle yapılandırmaları ayarlamaları gerekir:\n\n- OIDC: redirect URI'ler, client ID ve secret, izin verilen e‑posta domainleri\n- SAML: ACS URL, entity ID, IdP sertifikası, NameID formatı, "sign assertion" ayarı\n- Her ikisi için: kullanıcı e‑postasının hangi beyan veya öznitelikte olduğunu ve isteğe bağlı grup eşlemesini belirtme\n\nGeçiş sırasında kilitlenmeleri önlemek için, SSO dışında bir break‑glass yönetici hesabı tutun, ilk birkaç oturum için test modunda çalışın ve en az bir doğrulanmış yönetici oturumu olduktan sonra SSO'yu zorunlu kılın.\n\n## Kesin hatalar: kesintilere veya erişim kayıplarına neden olanlar\n\nÇoğu SSO olayı IdP'den kaynaklanmaz. Uygulamanız SSO'yu global bir anahtar olarak ele aldığında ve tenant ayrımını göz ardı ettiğinde olur.\n\nKlasik hata: tenant sınırlarını kaçırmak. Yeni bir IdP yapılandırması global olarak kaydedilir ve birdenbire her müşteri son kaydettiğiniz IdP'ye yönlendirilir. IdP ayarlarını tenant'a bağlayın ve SSO el sıkışmasını başlamadan önce tenant'ı çözün.\n\nHesap eşleme ikinci büyük tuzaktır. Yalnızca e‑postaya güveniyorsanız, çoğaltılmış kullanıcılar oluşturur veya IdP'deki e‑postası daha önce kullandıkları e‑postayla farklı olan gerçek kullanıcıları kilitlersiniz. Birleştirme politikanızı önceden tanımlayın: hangi tanımlayıcılara güveniyorsunuz, e‑posta değişikliklerini nasıl ele alıyorsunuz ve yöneticilerin mühendislik desteği olmadan uyuşmazlıkları nasıl düzeltebileceği.\n\nEkipler ayrıca beyanlara fazla güvenir. Aldıklarınızı doğrulayın: issuer, audience, imza ve e‑postanın doğrulanmış olup olmadığı (veya bunun yerine sabit bir subject kullanın). Yanlış audience'ı veya doğrulanmamış e‑postayı kabul etmek yanlış kişiye erişim verme yoludur.\n\nBir şeyler başarısız olduğunda, belirsiz hatalar uzun destek çağrılarına yol açar. Kullanıcılara net bir mesaj verin ve yöneticilere tanılama ipucu (ör. "Audience mismatch" veya "Certificate expired") sunun, gizli bilgileri ifşa etmeden.\n\nZamana bağlı sorunları piyasaya sürmeden önce test etmeye değer. Saat farkı ve sertifika rotasyonu pazartesi sabahı 09:00'da girişleri bozabilir.\n\nÇoğu kesintiyi önleyen beş kontrol:\n\n- IdP yapılandırmasını tenant başına saklayın, asla global yapmayın\n- Sabit bir kullanıcı anahtarı kullanın (sub veya NameID) ve güvenli bir birleştirme politikası tanımlayın\n- Her seferinde imzaları doğrulayın ve issuer ile audience'ı valide edin\n- Kullanıcı dostu bir hata ile birlikte yönetici‑yönelik bir neden kodu döndürün\n- Staging'te saat farkı toleransı ve sertifika rotasyonunu test edin\n\n## SSO'yu yayına almadan önce hızlı kontrol listesi\n\nSSO, küçük varsayımların büyük destek ticket'larına dönüştiği yerdir. Bir kurumsal müşteriye destek verdiğinizi söylemeden önce, temel şeylerin demo değil ürününüzde de doğru olduğundan emin olun.\n\n### Ürün hazırlığı\n\nÜretimi yansıtan bir staging ortamında şu adımları çalıştırın:\n\n- Tenant modeliniz net: her müşteri için bir IdP bağlantısı (veya workspace başına) ve domainlerin, kullanıcıların ve organizasyonların nasıl eşlendiğini açıklayabiliyor olun.\n- OIDC veya SAML yapılandırma ekranınız uçtan uca çalışıyor: gerçek metadata yapıştırın, kaydedin, oturum açın ve kullanıcının doğru tenant'a indiğini doğrulayın.\n- Loglarınız güvenli: client secret, özel anahtar ve tam SAML assertion veya ham ID token saklamıyor olun.\n- Yedek yol testli: yerel yönetici girişi, break‑glass erişim, parola sıfırlama ve IdP yanlış yapılandırıldığında SSO'yu devre dışı bırakma yolu.\n- Bir destek senaryosu hazırlayın: müşteriden istenecek bilgiler (issuer, uç noktalar, sertifikalar, örnek beyanlar) ve düzeltmeleri nasıl doğrulayacağınız.\n\n### Yayın hazırlığı\n\nBir tam "kötü gün" tatbikatı yapın: bir sertifikayı döndürün, bir beyanı değiştirin veya IdP URL'sini bozun ve bunu hızlıca tespit edip düzeltebildiğinizi doğrulayın.\n\nAyrıca tenant bazında SSO hataları için izleme ve alarmlarınız olduğundan emin olun ve pratik yapmış olduğunuz bir geri alma planı (feature flag, konfigürasyon geri alma veya hızlı dağıtım) hazırlayın.\n\n## Sonraki adımlar: güvenle gönderin ve kurumsal incelemelere hazır olun\n\nNet bir başlangıç noktası seçin. Çoğu kurumsal alıcı "Okta/Entra ID ile SAML" veya "Google/Microsoft ile OIDC" ister; ilk aşamada her ikisini de vaat etmek istemezsiniz. Hangisini önce destekleyeceğinizi (SAML yalnızca, OIDC yalnızca veya her ikisi) ve ürün ile destek ekibi için "tamamlandı"nın ne anlama geldiğini yazılı hale getirin.\n\nGerçek bir müşteriyi dahil etmeden önce küçük bir dahili demo tenantı oluşturun. SSO'yu etkinleştirin, oturum açmayı test edin, bir domain ile sınırlandırın ve bir şey ters gittiğinde erişimi nasıl geri alacağınızı prova edin. Destek oyun planınız burada test edilir.\n\nSürekli güncel tutulan bir kurumsal gereksinimler dokümanı bulundurun. İncelemeler zamanla değişir ve desteklediğiniz şeyleri tek bir yerde tutmak, sonradan bozacak tekil vaatleri önler.\n\nPratikte işe yarayan basit bir plan:\n\n- Faz 1'i seçin: SAML, OIDC veya her ikisi ve test edeceğiniz IdP'ler.\n- Erken dönemde SSO ayar UI'sı ve tenant modelini prototipleyin, sonra gerçek müşteri sorularına göre rafine edin.\n- Kurtarma kurallarını tanımlayın: break‑glass yönetici erişimi, yedek giriş ve sahiplik kontrolleri.\n- Kanıt hazırlayın: yapılandırma ekran görüntüleri, test adımları ve alıcılar için güvenlik notları.\n- Bir kurak çalışma planlayın: destek, ürün ve mühendislik bir "yeni kurumsal tenant" kurulumu üzerinden yürüsün.\n\nHızlı ilerlemek istiyorsanız, ayar ekranlarını ve tenant yapısını Koder.ai üzerinde prototipleyebilir ve müşteri güvenlik anketleri geldikçe yineleyebilirsiniz. koder.ai (koder.ai)\n\nSSO'dan hemen sonra genellikle gelen eklentilere hazırlanın: SCIM provisioning, denetim günlükleri dışa aktarımı ve net izinlere sahip yönetici rolleri. Bunları hemen sunmasanız bile alıcılar soracaktır ve yanıtınız tutarlı olmalıdır.
