What does SSO stand for, and what problem does it solve?

SSO stands for Single Sign-On. It is an authentication pattern that lets a user sign in once with their corporate identity provider and then access multiple downstream applications — including SecureCodingHub — without re-entering credentials. The point is not just convenience; it lets your security team enforce password policy, MFA, and offboarding in one place rather than per-application.

SSO vs SAML — are they the same thing?

No. SSO is the user-facing pattern; SAML is one of the protocols that can implement it. When you compare SSO vs SAML, the cleaner framing is that SAML 2.0 is a federation standard that carries the authentication assertion from your identity provider to the application, and SecureCodingHub speaks it. OIDC (built on OAuth 2.0) is the modern alternative for the same SSO outcome.

SSO vs OAuth — what is the actual difference?

The SSO vs OAuth distinction trips people up because OIDC sits on top of OAuth 2.0. OAuth 2.0 by itself is an authorization framework — it grants an application access to a resource. OIDC adds an identity layer on top, which is what makes OAuth-based SSO possible. So OAuth 2.0 alone does not give you SSO; OIDC over OAuth 2.0 does.

Can I use SSO with an open source identity provider?

Yes. Because SecureCodingHub supports the open standards — SAML 2.0 and OIDC — any open source SSO identity provider that implements them works. Keycloak, Authentik, and Zitadel are common picks for teams that want to self-host the IdP. The configuration steps on the SecureCodingHub side are identical to those for Azure AD or Okta; you supply the metadata or discovery URL and map the attributes.

SSO Genel Bakış

SecureCodingHub, OpenID Connect (OIDC) ve SAML 2.0 üzerinden Tek Oturum Açma'yı destekler. SSO, ekibinizin kurumsal kimlik sağlayıcılarıyla giriş yapmasını sağlar — ayrı parolalara gerek yoktur.

Desteklenen Protokoller

SecureCodingHub iki endüstri standardı SSO protokolünü destekler:

OIDC (OpenID Connect)

OAuth 2.0 tabanlı modern protokol. Azure AD, Okta ve çoğu bulut kimlik sağlayıcısı için önerilir. PKCE ile authorization code akışını kullanır.

SAML 2.0

XML tabanlı federasyon protokolü. Eski kimlik sağlayıcılar ve kurumsal ortamlar için desteklenir.

SSO Nasıl Çalışır

Kuruluşunuz için SSO yapılandırıldığında giriş akışı şöyle çalışır:

Kullanıcı SecureCodingHub girişine gider

Kuruluşunun SSO giriş noktasına ulaşır (bağlantı kurum slug'ını taşır; bugün otomatik e-posta-domain algılaması yoktur)

Tarayıcı kimlik sağlayıcınıza (Azure AD, Okta vb.) yönlendirir

Kullanıcı kurumsal kimlik bilgileriyle kimlik doğrular

IdP, kimlik doğrulama token'ı ile SecureCodingHub'a geri yönlendirir

SecureCodingHub bir oturum oluşturur ve kullanıcıyı giriş yaptırır

JIT Sağlama

SSO etkinleştirildiğinde kullanıcılar ilk girişlerinde otomatik olarak oluşturulur — buna Anında (JIT, Just-In-Time) sağlama denir. Yeni kullanıcılara varsayılan olarak Öğrenci rolü atanır. Yeni kullanıcıların sağlanabilmesi için kuruluşunuzun boş koltukları olmalıdır.

Yapılandırma URL'leri

Kimlik sağlayıcınızı yapılandırırken aşağıdaki URL'leri kullanın:

Ayar	Değer
OIDC Callback URL	`https://api.limeplate.com/api/sch/auth/sso/callback/oidc`
SAML ACS URL	`https://api.limeplate.com/api/sch/auth/sso/callback/saml`
SP Metadata URL	`https://api.limeplate.com/api/sch/auth/sso/metadata`

Not: SSO yapılandırması Kurum Yöneticisi veya Platform Yöneticisi erişimi gerektirir. Başlamak için Azure AD veya Okta kurulum kılavuzlarına bakın.

SAML ve OIDC arasında seçim yapmak

Kimlik sağlayıcınız her iki protokolü de destekliyorsa pratik yanıt, güvenlik ekibinizin halihazırda işlettiği ve güvendiği şeyi seçmektir. OIDC, OAuth 2.0 üzerine kurulmuş daha yeni, JSON tabanlı bir protokoldür. Geliştirmek için daha dostane, ayıklamak daha kolaydır ve Azure AD ile Okta dahil çoğu modern IdP'de varsayılan seçenektir. Bulut yerel araç setine geçen kuruluşlar için genellikle OIDC doğru seçimdir.

SAML daha eski, XML tabanlı federasyon standardıdır ve kurumsal ortamlarda en yaygın seçim olarak kalır. Bunun nedeni nadiren teknik tercihtir. IdP ekibinin halihazırda onlarca SAML entegrasyonu işletmesi, sertifika rotasyon takviminin oturmuş olması ve SAML sorun giderme için iç oyun kitabının olgun olmasıdır. PingFederate, ADFS ya da eski bir SAML IdP'nin olduğu bir ortama dağıtım yapıyorsanız SAML'i seçmek, IdP ekibinden tek seferlik bir OIDC entegrasyonunu desteklemesini istemek yerine mevcut kalıpları yeniden kullanmanızı sağlar. Her iki protokol de eşdeğer güvenlik sunar; seçim kriptografi değil, operasyonel uyum meselesidir.

SSO öncesi kontrol listesi

Üretimde SSO'yu etkinleştirmeden önce üç gerçek etrafında plan yapın. Birinci, bir test ortamı kurun ya da uçtan uca kontrol ettiğiniz bir kiracıyı kullanın. Yanlış yapılandırılmış SSO, yapılandıran yönetici dahil herkesi dışarıda bırakabilir. Tam giriş akışını önce kritik olmayan bir kurum üzerinde, ideal olarak tek kullanımlık bir IdP uygulamasıyla çalıştırın; böylece özellik eşlemesi üzerinde aciliyet olmadan iterasyon yapabilirsiniz. İkincisi, SSO'ya bağlı olmayan en az bir yedek yönetici hesabı tutun. SecureCodingHub bir cam-kırma yerel yönetici yolunu onurlandırır ve onu test etme zamanı SSO yayına girmeden öncedir, bir Cuma akşamı saat 21:00'de bir şeyler ters gittiğinde değil.

Üçüncüsü, e-posta tabanlı davet akışlarının aşağı akış etkisini düşünün. SSO aktif olduğunda doğrulanmış domain'inizdeki kullanıcılar IdP'ye yönlendirilir ve ilk girişte JIT ile sağlanır. Bu, kullanıcıları e-posta ile manuel davet eden bir yöneticinin ve IdP'de uygulamayı atayan bir dizin yöneticisinin her ikisinin de hesap oluşturabileceği ve birini seçmezseniz iki akışın çakışacağı anlamına gelir. Daha temiz kalıp, SSO ile yönetilen domain için manuel davetleri devre dışı bırakıp IdP'nin tek doğruluk kaynağı olmasına izin vermektir. Bir sonraki adım için SAML kurulum kılavuzu ve protokole özgü kılavuzlara bakın.

SSO: sıkça sorulanlar

SSO ne anlama gelir ve hangi sorunu çözer?

SSO, Single Sign-On (Tek Oturum Açma) anlamına gelir. Bir kullanıcının kurumsal kimlik sağlayıcısıyla bir kez giriş yapıp ardından kimlik bilgilerini yeniden girmeden — SecureCodingHub dahil — birden fazla aşağı akış uygulamasına erişmesini sağlayan bir kimlik doğrulama kalıbıdır. Mesele yalnızca kolaylık değildir; güvenlik ekibinizin parola politikası, MFA ve hesap kapatma kurallarını uygulama başına değil tek bir yerde uygulamasını sağlar.

SSO ve SAML — aynı şey midir?

Hayır. SSO kullanıcıya yönelik bir kalıptır; SAML ise onu uygulayabilecek protokollerden biridir. SSO ile SAML'i karşılaştırırken daha temiz çerçeveleme şudur: SAML 2.0, kimlik sağlayıcınızdan uygulamaya kimlik doğrulama iddiasını taşıyan bir federasyon standardıdır ve SecureCodingHub bu protokolü konuşur. OIDC (OAuth 2.0 üzerine kurulu) aynı SSO sonucu için modern alternatiftir.

SSO ve OAuth — gerçek fark nedir?

SSO ile OAuth arasındaki ayrım insanları yanıltır çünkü OIDC, OAuth 2.0'ın üstünde oturur. OAuth 2.0 tek başına bir yetkilendirme çerçevesidir — bir uygulamaya bir kaynağa erişim verir. OIDC ise üstüne bir kimlik katmanı ekler ve OAuth tabanlı SSO'yu mümkün kılan şey budur. Yani tek başına OAuth 2.0 size SSO vermez; OAuth 2.0 üzerinde OIDC verir.

Açık kaynak bir kimlik sağlayıcı ile SSO kullanabilir miyim?

Evet. SecureCodingHub açık standartları — SAML 2.0 ve OIDC — desteklediği için, bunları uygulayan herhangi bir açık kaynak SSO kimlik sağlayıcısı çalışır. Keycloak, Authentik ve Zitadel, IdP'yi kendi kendine barındırmak isteyen ekiplerin yaygın tercihleridir. SecureCodingHub tarafındaki yapılandırma adımları Azure AD ya da Okta için olanlarla aynıdır; metadata ya da keşif URL'sini sağlar ve özellikleri eşlersiniz.