SSO-Setup
SSO-Einrichtung
Dieser Leitfaden richtet sich an IT-Administratoren, die einen Unternehmens-Identity-Provider (IdP) mit InterMIND verbinden. Nach der Einrichtung melden sich Mitglieder über die reguläre Login-Seite an: Mit SSO anmelden → geschäftliche E-Mail-Adresse → Ihr IdP → zurück in InterMIND. Eine nicht-technische Übersicht finden Sie auf der Single Sign-On-Funktionsseite.
Verfügbar für: Business- und Enterprise-Pläne Konfiguriert von: Team-Owner oder Administrator Protokoll: Nur OpenID Connect (OIDC). SAML 2.0 wird nicht angeboten — Okta, Microsoft Entra ID und Google Workspace unterstützen alle OIDC.
Voraussetzungen
- Eine verifizierte Domain — verifizieren Sie Ihre E-Mail-Domain zunächst über einen DNS-TXT-Eintrag (siehe Domain-Verwaltung). Die SSO-Anmeldung akzeptiert nur Konten, deren E-Mail-Domain Ihr Team verifiziert hat; dies ist die Mandantengrenze.
- Ein IdP, der OIDC mit Discovery unterstützt — er muss
/.well-known/openid-configurationunter der Issuer-URL bereitstellen. Okta, Microsoft Entra ID und Google tun dies alle.
Was Sie in Ihrem IdP registrieren müssen
Erstellen Sie eine OIDC-Webanwendung in Ihrem IdP mit:
| Einstellung | Wert |
|---|---|
| Redirect-URI (Callback) | https://intermind.com/api/auth/sso/callback — wird auch auf der SSO-Karte angezeigt, nachdem Sie OIDC ausgewählt haben |
| Grant-Typ | Authorization Code (PKCE S256 wird automatisch verwendet) |
| Scopes | openid email profile |
Das ID-Token, das Ihr IdP ausstellt, muss die email des Benutzers enthalten, und die Domain der E-Mail-Adresse muss eine Ihrer verifizierten Domains sein — andernfalls wird die Anmeldung abgelehnt.
Füllen Sie dann die SSO-Karte auf der Integrations-Seite aus:
| Feld | Was Sie eintragen |
|---|---|
| Anzeigename | Ein beliebiges Label, das Ihre Mitglieder wiedererkennen |
| Issuer URL | Der Issuer Ihres IdP — die URL, die /.well-known/openid-configuration bereitstellt |
| Authorization URL | Der authorization_endpoint aus diesem Discovery-Dokument |
| Client ID / Client Secret | Aus der von Ihnen registrierten App |
Das Client-Secret wird verschlüsselt gespeichert und nach dem Speichern nie an den Browser zurückgegeben.
Okta
- Admin console → Applications → Create App Integration → Sign-in method OIDC, Application type Web Application
- Sign-in redirect URI:
https://intermind.com/api/auth/sso/callback - Weisen Sie die Benutzer oder Gruppen zu, die Zugriff erhalten sollen
- Kopieren Sie die Client ID und das Client Secret
- In InterMIND: Issuer URL = Ihre Okta-Org-URL (z. B.
https://acme.okta.comoder der Issuer Ihres Authorization Servers wiehttps://acme.okta.com/oauth2/default, falls Sie einen verwenden); Authorization URL = derauthorization_endpointaus<issuer>/.well-known/openid-configuration
Microsoft Entra ID (Azure AD)
- Entra admin center → App registrations → New registration
- Platform Web, Redirect-URI
https://intermind.com/api/auth/sso/callback - Certificates & secrets → New client secret — kopieren Sie den Value sofort
- Client ID = die Application (client) ID auf der Overview-Seite
- Stellen Sie sicher, dass das ID-Token die E-Mail-Adresse des Benutzers enthält: Token configuration → Add optional claim → ID → email
- In InterMIND: Issuer URL =
https://login.microsoftonline.com/<tenant-id>/v2.0; Authorization URL =https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
Google Workspace
Keine App-Registrierung erforderlich. Wählen Sie in der SSO-Karte den Provider-Typ Google Workspace und speichern Sie — Mitglieder auf Ihren verifizierten Domains melden sich mit ihrem Google-Konto an und treten Ihrem Team automatisch bei. (Google lässt sich auch als generischer OIDC-Provider mit dem Issuer https://accounts.google.com verbinden, falls Sie explizite Client-Credentials bevorzugen.)
Verbindung testen
- Öffnen Sie die Login-Seite in einem privaten/Incognito-Fenster
- Klicken Sie auf Mit SSO anmelden und geben Sie eine geschäftliche E-Mail-Adresse auf Ihrer verifizierten Domain ein
- Sie werden zu Ihrem IdP weitergeleitet; nach der Authentifizierung landen Sie wieder in InterMIND angemeldet
- Die Anmeldung wird im Team-Audit-Log erfasst (exportierbar über die Users-Seite) als
auth.loginmit Methodesso
Fehlerbehebung
| Symptom | Ursache |
|---|---|
| "SSO is not configured" nach Eingabe der E-Mail-Adresse | Keine aktivierte SSO-Konfiguration passt zu dieser E-Mail-Domain — prüfen Sie, ob die Domain verifiziert und die SSO-Karte gespeichert ist |
SSO login is not available: plan | Der Plan des Teams enthält SSO nicht mehr |
SSO login is not available: domain-not-verified | Die Domain wartet noch auf die DNS-Verifizierung |
SSO login is not available: config-incomplete | Client ID oder Client Secret fehlen — speichern Sie die SSO-Karte erneut |
SSO login is not available: type-unsupported | Der gespeicherte Provider-Typ wird vom Anmelde-Flow nicht unterstützt — löschen Sie die SSO-Konfiguration und erstellen Sie sie als OIDC oder Google Workspace neu |
SSO IdP discovery failed | Issuer URL ist falsch oder stellt /.well-known/openid-configuration nicht bereit |
| "login session expired, start again" | Zwischen Anmeldungsstart und IdP-Callback sind mehr als 5 Minuten vergangen |
| Anmeldung nach IdP-Redirect abgelehnt | Der IdP hat eine E-Mail-Adresse außerhalb Ihrer verifizierten Domains zurückgegeben oder gar keinen email-Claim (Entra: optionalen Email-Claim hinzufügen) |
Sicherheitseigenschaften
Für Security-Fragebögen: Der SSO-Flow nutzt Authorization Code mit PKCE (S256), state und nonce; die Signatur des ID-Tokens wird gegen die JWKS des IdP validiert, zusammen mit Issuer und Audience; der IdP ist nur für über DNS verifizierte Domains autoritativ — eine Assertion für eine andere E-Mail-Adresse erzeugt niemals eine Session; das OIDC-Client-Secret ist encrypted at rest; jede SSO-Anmeldung wird im Team-Audit-Log erfasst. Plan-, Domain- und Konfigurations-Gates werden serverseitig sowohl beim Anmeldungsstart als auch beim Callback erzwungen.