Enterprise SSO

Auris ermöglicht es Unternehmenskunden, sich mit ihrem bestehenden Unternehmens-Identity-Provider (IdP) zu authentifizieren — Azure Active Directory, Okta, Google Workspace, OneLogin, PingIdentity oder jeder SAML 2.0 oder OIDC-konforme IdP.

SSO-Verbindungen sind auf Organisationen beschränkt. Jede Organisation in Auris kann eine oder mehrere SSO-Verbindungen haben, und die passende Verbindung wird automatisch anhand der E-Mail-Domain des Benutzers erkannt.

Übersicht

Wenn ein Benutzer mit einer E-Mail, die zu einer verifizierten Domain passt, versucht sich anzumelden, unternimmt Auris folgendes:

1. Erkennt die SSO-Verbindung über die E-Mail-Domain
2. Leitet den Benutzer zur Unternehmens-IdP-Login-Seite weiter
3. Empfängt die SAML-Assertion oder das OIDC-Token vom IdP
4. Ordnet IdP-Benutzerattribute Auris-Benutzerfeldern zu
5. Stellt das Benutzerkonto in Auris bereit, falls es nicht existiert (JIT-Provisionierung)
6. Stellt ein Auris-Access-Token und Refresh-Token aus

Aus Sicht deiner Anwendung ist der Flow identisch mit jedem anderen Auris-Login — du verwendest dasselbe SDK, dieselbe Callback-URL und erhältst dasselbe Token-Format.

SAML 2.0-Einrichtung

OIDC-Provider-Einrichtung

Domain-Verifizierung

Damit die SSO-Erkennung funktioniert, musst du das Eigentum an der/den von den Mitgliedern der Organisation verwendeten E-Mail-Domain(s) nachweisen.

Typ:  TXT
Name: _auris-verify.acme.com
Wert: auris-verify=abc123xyz456...

SSO-Erkennung

Auris erkennt automatisch die SSO-Verfügbarkeit, wenn ein Benutzer seine E-Mail auf der gehosteten Login-Seite eingibt. Die Erkennung ist auch als API-Aufruf für benutzerdefinierte Login-Oberflächen verfügbar:

// Benutzerdefinierte Login-Oberfläche: auf SSO prüfen, bevor das Passwortfeld angezeigt wird
async function checkSso(email) {
  const domain = email.split('@')[1]
  const response = await fetch('/api/auth/sso/detect', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email }),
  })
  const data = await response.json()
 
  if (data.ssoEnabled) {
    // Zu SSO weiterleiten — Passwortfeld überspringen
    window.location.href = `/api/auth/sso/login/${data.connectionAlias}`
  } else {
    // Passwortfeld anzeigen
    showPasswordField()
  }
}

JIT-Provisionierung

Just-in-Time-Provisionierung erstellt automatisch ein neues Auris-Benutzerkonto beim ersten SSO-Login eines Benutzers. Dies eliminiert die Notwendigkeit, Konten vorab zu erstellen oder Benutzerlisten manuell zu synchronisieren.

Beim ersten SSO-Login:

• Auris erstellt ein Benutzerkonto mit den aus der SAML-Assertion oder dem OIDC-Token zugeordneten Attributen
• Der Benutzer erhält alle für die Organisation konfigurierten Standardrollen
• Ein user.created-Audit-Log-Ereignis wird mit source: 'sso_jit' aufgezeichnet

Bei nachfolgenden SSO-Logins:

• Auris aktualisiert die Benutzerattribute vom IdP (Name, E-Mail), wenn sie sich geändert haben
• Rollenzuweisungen aus früheren Sitzungen werden beibehalten
• Ein user.login-Audit-Log-Ereignis wird aufgezeichnet

JIT-Provisionierung deaktivieren: Schalte JIT Provisioning in den SSO-Verbindungseinstellungen aus. Bei deaktiviertem JIT müssen Benutzer vorab in Auris erstellt werden (manuell oder über SCIM), bevor sie SSO verwenden können.

Rollen-Mapping

Standardmäßig erhalten SSO-Benutzer keine Rollen in Auris. Du kannst automatische Rollenzuweisung basierend auf IdP-Gruppenmitgliedschaft konfigurieren:

1. In den SSO-Verbindungseinstellungen → Tab Role Mapping
2. IdP-Gruppenwerte (aus einem groups-SAML-Attribut oder OIDC-Claim) Auris-Rollen zuordnen
3. Rollen-Mappings werden bei jedem Login angewendet — wenn ein Benutzer aus einer IdP-Gruppe entfernt wird, verliert er beim nächsten Login die entsprechende Auris-Rolle

Beispiel-Mapping:

• IdP-Gruppe AurisAdmins → Auris-Rolle Administrator
• IdP-Gruppe AurisViewers → Auris-Rolle Viewer

API-Endpunkte

Sicherheitsüberlegungen

SAML-Signatur-Verifizierung — Auris validiert SAML-Assertions mit dem Signaturzertifikat des IdP. Unsignierte oder falsch signierte Assertions werden abgelehnt.

OIDC-State und Nonce — Der OIDC-Flow verwendet einen State-Parameter für CSRF-Schutz und einen Nonce-Claim zur Verhinderung von Token-Replay.

Domain-Übernahme-Schutz — Eine verifizierte Domain kann nur von einer Organisation pro Tenant beansprucht werden. Eine erneute Verifizierung nach Domain-Übertragung erfordert explizite Admin-Aktion.

Bypass-Verhinderung — Sobald eine Domain verifiziert und SSO aktiv ist, werden Benutzer mit dieser E-Mail-Domain zum SSO-Flow geleitet. Sie können SSO nicht umgehen und sich mit einem Passwort anmelden, es sei denn, die Verbindung wird deaktiviert.

Verwandte Anleitungen

• Organisationen — Organisationen für B2B-Multi-Tenancy einrichten
• Hosted Login (PKCE) — Der OAuth2-Flow, den deine Anwendung verwendet (bei SSO unverändert)
• Benutzerverwaltung — SSO-provisionierte Benutzerkonten verwalten