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-Übersicht

SecureCodingHub unterstützt Single Sign-On über OpenID Connect (OIDC) und SAML 2.0. SSO ermöglicht es Ihrem Team, sich mit dem Identitätsanbieter Ihres Unternehmens anzumelden — keine separaten Passwörter erforderlich.

Unterstützte Protokolle

SecureCodingHub unterstützt zwei branchenübliche SSO-Protokolle:

OIDC (OpenID Connect)

Modernes auf OAuth 2.0 basierendes Protokoll. Empfohlen für Azure AD, Okta und die meisten Cloud-Identitätsanbieter. Verwendet Authorization Code Flow mit PKCE.

SAML 2.0

XML-basiertes Föderationsprotokoll. Unterstützt für Legacy-Identitätsanbieter und Unternehmensumgebungen.

Wie SSO funktioniert

Wenn SSO für Ihre Organisation konfiguriert ist, funktioniert der Anmeldevorgang wie folgt:

Benutzer navigiert zur SecureCodingHub-Anmeldung

Landet auf dem SSO-Einstiegspunkt für seine Organisation (der Link enthält den Organisations-Slug; es gibt heute keine automatische E-Mail-Domain-Erkennung)

Browser leitet zu Ihrem Identitätsanbieter weiter (Azure AD, Okta usw.)

Benutzer authentifiziert sich mit Unternehmensanmeldedaten

IdP leitet mit Auth-Token zurück zu SecureCodingHub

SecureCodingHub erstellt eine Sitzung und meldet den Benutzer an

JIT-Bereitstellung

Wenn SSO aktiviert ist, werden Benutzer bei der ersten Anmeldung automatisch erstellt — dies wird Just-In-Time (JIT)-Bereitstellung genannt. Neuen Benutzern wird standardmäßig die Rolle Lernender zugewiesen. Ihre Organisation muss verfügbare Sitzplätze haben, damit neue Benutzer bereitgestellt werden können.

Konfigurations-URLs

Verwenden Sie die folgenden URLs bei der Konfiguration Ihres Identitätsanbieters:

Einstellung	Wert
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`

Hinweis: Die SSO-Konfiguration erfordert Organisationsadministrator- oder Plattformadministrator-Zugang. Siehe die Einrichtungsanleitungen für Azure AD oder Okta, um loszulegen.

Zwischen SAML und OIDC wählen

Wenn Ihr Identitätsanbieter beide Protokolle unterstützt, lautet die praktische Antwort, das zu wählen, was Ihr Sicherheitsteam bereits betreibt und dem es vertraut. OIDC ist das neuere, JSON-basierte Protokoll, das auf OAuth 2.0 aufbaut. Es ist freundlicher zu entwickeln, einfacher zu debuggen und die Standardoption in den meisten modernen IdPs, einschließlich Azure AD und Okta. Für Organisationen, die auf Cloud-Native-Werkzeuge standardisieren, ist OIDC normalerweise die richtige Wahl.

SAML ist der ältere, XML-basierte Föderationsstandard und bleibt die häufigste Wahl in Unternehmensumgebungen. Der Grund ist selten technische Präferenz. Es ist, dass das IdP-Team bereits Dutzende von SAML-Integrationen betreibt, der Zertifikatsrotationskalender etabliert ist und das interne Playbook für SAML-Fehlerbehebung reif ist. Wenn Sie in einer Umgebung mit PingFederate, ADFS oder einem Legacy-SAML-IdP bereitstellen, ermöglicht Ihnen die Wahl von SAML, bestehende Muster wiederzuverwenden, anstatt das IdP-Team zu bitten, eine einmalige OIDC-Integration zu unterstützen. Beide Protokolle bieten gleichwertige Sicherheit; die Wahl betrifft den operationellen Fit, nicht die Kryptographie.

Pre-SSO-Checkliste

Bevor Sie SSO in der Produktion aktivieren, planen Sie um drei Realitäten. Erstens, richten Sie eine Testumgebung ein oder verwenden Sie einen Tenant, den Sie End-to-End kontrollieren. Falsch konfiguriertes SSO kann jeden aussperren, einschließlich des Administrators, der es konfiguriert hat. Führen Sie den vollständigen Anmeldevorgang gegen eine nicht kritische Organisation zuerst durch, idealerweise mit einer Wegwerf-IdP-Anwendung, damit Sie die Attributzuordnung ohne Dringlichkeit iterieren können. Zweitens, behalten Sie mindestens ein Fallback-Administratorkonto, das nicht auf SSO angewiesen ist. SecureCodingHub respektiert einen Notfall-Local-Admin-Pfad, und die Zeit, ihn zu testen, ist vor der Inbetriebnahme von SSO, nicht um 21 Uhr an einem Freitag, wenn etwas schief gegangen ist.

Drittens, denken Sie über die nachgelagerten Auswirkungen auf E-Mail-basierte Einladungsabläufe nach. Sobald SSO aktiv ist, werden Benutzer aus Ihrer verifizierten Domain zum IdP umgeleitet und bei der ersten Anmeldung über JIT bereitgestellt. Das bedeutet, dass ein Administrator, der Benutzer manuell per E-Mail einlädt, und ein Verzeichnisadministrator, der die App im IdP zuweist, beide Konten erstellen können, und die beiden Streams werden kollidieren, wenn Sie nicht einen wählen. Das saubere Muster ist, manuelle Einladungen für die SSO-verwaltete Domain zu deaktivieren und den IdP als einzige Quelle der Wahrheit sein zu lassen. Siehe die SAML-Einrichtungsanleitung und protokollspezifische Anleitungen für den nächsten Schritt.

SSO: häufig gestellte Fragen

Wofür steht SSO und welches Problem löst es?

SSO steht für Single Sign-On. Es ist ein Authentifizierungsmuster, das es einem Benutzer ermöglicht, sich einmal mit seinem Unternehmens-Identitätsanbieter anzumelden und dann auf mehrere nachgelagerte Anwendungen zuzugreifen — einschließlich SecureCodingHub — ohne Anmeldedaten erneut einzugeben. Der Punkt ist nicht nur Bequemlichkeit; es ermöglicht Ihrem Sicherheitsteam, Passwortrichtlinien, MFA und Offboarding an einem Ort statt pro Anwendung zu erzwingen.

SSO vs SAML — sind sie dasselbe?

Nein. SSO ist das benutzerorientierte Muster; SAML ist eines der Protokolle, das es implementieren kann. Wenn Sie SSO vs SAML vergleichen, ist die sauberere Rahmung, dass SAML 2.0 ein Föderationsstandard ist, der die Authentifizierungsbehauptung von Ihrem Identitätsanbieter zur Anwendung trägt, und SecureCodingHub spricht es. OIDC (auf OAuth 2.0 aufbauend) ist die moderne Alternative für dasselbe SSO-Ergebnis.

SSO vs OAuth — was ist der tatsächliche Unterschied?

Die SSO vs OAuth-Unterscheidung verwirrt Menschen, weil OIDC auf OAuth 2.0 aufsitzt. OAuth 2.0 allein ist ein Autorisierungsframework — es gewährt einer Anwendung Zugriff auf eine Ressource. OIDC fügt eine Identitätsschicht obendrauf hinzu, was OAuth-basiertes SSO möglich macht. Also gibt Ihnen OAuth 2.0 allein kein SSO; OIDC über OAuth 2.0 schon.

Kann ich SSO mit einem Open-Source-Identitätsanbieter verwenden?

Ja. Weil SecureCodingHub die offenen Standards unterstützt — SAML 2.0 und OIDC — funktioniert jeder Open-Source-SSO-Identitätsanbieter, der sie implementiert. Keycloak, Authentik und Zitadel sind häufige Optionen für Teams, die den IdP selbst hosten möchten. Die Konfigurationsschritte auf der SecureCodingHub-Seite sind identisch mit denen für Azure AD oder Okta; Sie liefern die Metadata- oder Discovery-URL und ordnen die Attribute zu.