Single Sign-on (SSO)

Single Sign-on lässt alle in deinem Team sich mit eurem bestehenden Unternehmens-Identity-Provider bei CrunchJunkie anmelden — Microsoft Entra ID (Azure AD), Google Workspace, Okta oder jeder OpenID-Connect-Provider — statt mit einem separaten Passwort. Neue Teammitglieder werden beim ersten Login automatisch in deinen Workspace aufgenommen. SSO ist in den Tarifen Pro, Agency und Scale verfügbar und wird von einem Inhaber oder Admin unter Einstellungen → SSO konfiguriert. Ohne aktiven Pro-, Agency- oder Scale-Tarif ist Single Sign-on pausiert: Dein Team meldet sich dann mit Passwort oder Google an, und wer bisher nur SSO genutzt hat, legt über „Passwort vergessen“ ein Passwort fest. Dieses Passwort ist vorübergehend. Sobald der Tarif wieder aktiv ist und SSO funktioniert, wird es entfernt, Sitzungen, die damit angemeldet waren, enden innerhalb von etwa einer Minute, und die Person meldet sich wieder mit SSO an; wir schicken ihr dann einmal eine E-Mail. Ein Passwort, das jemand schon vorher hatte, bleibt. Solange sich jemand mit einem solchen vorübergehenden Passwort anmeldet, lässt sich seine E-Mail-Adresse nicht ändern. API-Schlüssel gehören zum Workspace, nicht zu einem Passwort, und werden deshalb nicht entfernt: Wird ein vorübergehendes Passwort entfernt, nennt das Admin-Audit-Protokoll die API-Schlüssel, die diese Person in der Zwischenzeit erstellt hat, und Inhaber oder Admins können sie unter Einstellungen → API prüfen und nicht benötigte widerrufen. Inhaber oder Admins können SSO weiterhin ausschalten, Domains entfernen oder die Verbindung löschen; sobald der Tarif wieder aktiv ist, funktioniert SSO wieder. SSO ist ein zusätzlicher Weg hinein, bis du es verlangst: Ist „SSO verlangen“ eingeschaltet (siehe „SSO verlangen“ unten), melden sich Mitglieder auf deinen verifizierten Domains nur noch über deinen Identity Provider an. Wir unterstützen heute OpenID Connect, das die große Mehrheit der Enterprise-IdPs abdeckt. Wenn euer Provider nur SAML spricht, meldet euch – SAML gibt es im Scale-Plan auf Anfrage.

Lege in deinem Identity Provider eine neue OIDC-Anwendung (OpenID Connect) an. Setze die Redirect-URI auf den in Einstellungen → SSO angezeigten Wert — sie sieht aus wie https://app.crunchjunkie.io/api/auth/sso/callback. Fordere die Standard-Scopes openid, email und profile an. Dein IdP gibt dir drei Dinge: eine Issuer-URL, eine Client-ID und ein Client-Secret. Füge sie in Einstellungen → SSO ein und speichere. Das Secret wird verschlüsselt gespeichert und nie wieder angezeigt — zum Ändern speicherst du einfach ein neues. Zwei häufige Fälle. Google Workspace: Lege in der Google-Cloud-Konsole eine OAuth-Client-ID vom Typ „Webanwendung“ an, trage dort die Redirect-URI ein und nutze https://accounts.google.com als Issuer-URL. Microsoft Entra ID: Registriere eine App, füge die Redirect-URI als Plattform „Web“ hinzu und nutze https://login.microsoftonline.com/<deine Tenant-ID>/v2.0 als Issuer-URL. Meldet dein IdP „redirect_uri_mismatch“, weicht die dort eingetragene Adresse von der unter Einstellungen → SSO angezeigten ab — kopiere sie erneut, Zeichen für Zeichen.

SSO leitet einen Login anhand der E-Mail-Domain des Nutzers, du gibst uns also an, welche Domains zu dir gehören, und weist deren Besitz nach. Füge eine Domain (z. B. acme.com) unter Einstellungen → SSO hinzu, und wir zeigen einen DNS-TXT-Eintrag — trage ihn im DNS dieser Domain ein und klicke auf Verifizieren. Eine Domain leitet erst nach der Verifizierung Logins, und jede Domain kann nur zu einem Workspace gehören, sodass niemand sonst deine beanspruchen kann. Eine Domain, die 30 Tage lang nicht verifiziert wird, wird wieder freigegeben, damit ein unfertiger Anspruch den echten Inhaber nicht blockiert; um sie danach zu verifizieren, füge sie erneut hinzu und du erhältst einen neuen TXT-Eintrag. Lege ihn als neuen TXT-Eintrag auf der Domain selbst an (Host @ oder leer), zusätzlich zu den TXT-Einträgen, die es schon gibt — SPF- und andere Verifizierungseinträge bleiben, wie sie sind. Füge den vollständigen Wert ein, einschließlich des Codes nach dem Gleichheitszeichen: Manche DNS-Oberflächen schneiden einen eingefügten Wert am „=“ ab. DNS-Änderungen brauchen ein paar Minuten; schlägt die Verifizierung fehl, warte kurz und versuche es erneut.

Sobald mindestens eine Domain verifiziert ist, aktiviere SSO. Ab dann öffnet ein Nutzer die Login-Seite, klickt auf „Continue with single sign-on (SSO)“ — oder geht direkt auf app.crunchjunkie.io/auth/sso —, gibt seine geschäftliche E-Mail ein und wird zu deinem IdP geleitet; nach der Authentifizierung dort (einschließlich eines zweiten Faktors, falls dein IdP ihn verlangt) landet er angemeldet auf seiner CrunchJunkie-Startseite. Beim ersten Login von einer verifizierten Domain wird die Person automatisch deinem Workspace hinzugefügt. Im Hintergrund validieren wir das signierte Token des Identity Providers (Signatur, Issuer, Audience und eine Nonce pro Login), bevor wir der E-Mail vertrauen — nur eine echte Antwort deines IdP kann also jemanden anmelden. Und dein IdP kann nur Adressen auf den Domains anmelden, die du verifiziert hast: Eine Adresse auf jeder anderen Domain wird abgelehnt, auch wenn das Token selbst echt ist. Du kannst SSO jederzeit deaktivieren, was das Weiterleiten von Logins an deinen IdP sofort stoppt (bestehende Passwort-Logins bleiben unberührt). SSO einzuschalten schaltet Passwörter nicht ab: Wer schon ein Passwort hat, kann es weiter nutzen, bis du „SSO verlangen“ einschaltest (nächster Abschnitt). Solange SSO eingeschaltet ist, bleiben Mitglieder deines Workspace, deren Adresse auf einer seiner verifizierten Domains liegt, bei eurem Identity Provider. Sie können ihre E-Mail-Adresse nur auf eine andere Adresse unter diesen Domains ändern. Für jede andere Adresse öffnet ein Inhaber oder Admin Einstellungen → Team, klickt auf das Menü des Mitglieds und wählt „Anmelde-E-Mail ändern“ (ein Admin für Mitglieder und Nur-Lesen-Zugänge, der Inhaber für alle): Ein Bestätigungslink geht an die neue Adresse, die Änderung greift, sobald er angeklickt wird (innerhalb von 24 Stunden), die bisherige Adresse bekommt einen Hinweis, und beide Schritte werden in unserem Audit-Log festgehalten. Und solange SSO funktioniert, schickt „Passwort vergessen“ diesen Mitgliedern keinen Link für ein Passwort, ob sie eins haben oder nicht: Sie bekommen stattdessen eine E-Mail, die sie zum Single Sign-on schickt. Die Ausnahme ist der Inhaber des Workspace: Er behält „Passwort vergessen“ als Weg zurück, falls dein Identity Provider ihn aussperrt (siehe „SSO verlangen“ unten). Läuft der Tarif des Workspace aus, gelten die Regeln für vorübergehende Passwörter von oben. Solange SSO für eine Domain aktiv ist, legt das Registrierungsformular für ihre Adressen kein Konto mit Passwort an: Die Adresse bekommt stattdessen eine E-Mail mit dem Link zur SSO-Anmeldung, und das Formular antwortet wie immer, verrät also nicht, ob es zu der Adresse ein Konto gibt, und ein Link zum Bestätigen einer Adresse auf dieser Domain wird nicht verschickt. Und hat jemand ein Konto für eine Adresse angelegt, bevor ihr Inhaber sie je bestätigt hat, werden Passwort und Sitzungen dieses Kontos entfernt, sobald sich die richtige Person zum ersten Mal per SSO oder mit einem Google-Konto anmeldet, das die Adresse belegt (Gmail oder Google Workspace). So kann niemand vorab ein Konto für die Adresse eines Kollegen einrichten. Zwei-Faktor-Einstellungen, API-Schlüssel und weitere verknüpfte Anmeldungen werden ebenfalls entfernt, außer die Google-Anmeldung, die die Adresse belegt, ist die einzige verknüpfte: Dann hat dieselbe Person sie eingerichtet, behält sie und bekommt eine E-Mail, dass das Passwort entfernt wurde. Wer seine Adresse schon früher bestätigt hat, behält sein Passwort.

Ist SSO an, funktionieren Passwörter und „Continue with Google“ daneben weiter. Damit dein Identity Provider der einzige Weg hinein wird, schaltet ein Inhaber oder Admin unter Einstellungen → SSO „SSO verlangen“ ein. Ab dann können sich Mitglieder, deren E-Mail-Adresse auf einer deiner verifizierten Domains liegt, nur noch mit SSO anmelden, sodass die Zwei-Faktor-Regeln und das Offboarding deines IdP für jede Anmeldung gelten. Ihr Passwort und die Anmeldung mit Google werden mit „Dein Unternehmen verlangt die Anmeldung mit SSO.“ abgelehnt, und eine Sitzung, die sie nicht mit SSO begonnen haben, endet innerhalb von etwa einer Minute, bei ihrem nächsten Seitenaufruf oder ihrer nächsten Anfrage. Mitglieder mit einer Adresse auf einer anderen Domain, etwa ein externer Berater mit gmail.com, sind nicht betroffen, ebenso wenig alle außerhalb deines Workspace. Wer an eine Adresse auf deinen Domains eingeladen ist, kommt über eine Anmeldung mit SSO dazu. Einschalten lässt es sich erst, wenn SSO mit einer verifizierten Domain eingeschaltet ist, der Workspace einen aktiven Pro-, Agency- oder Scale-Tarif hat und sich mindestens einmal jemand über deine Verbindung angemeldet hat – das beweist, dass die Einrichtung funktioniert. Vor dem Einschalten nennt eine Bestätigung jedes Mitglied, das es betrifft, und jedes, das es nicht betrifft, mit den Anzahlen, den offenen Einladungen an deine Domains und den aktiven API-Schlüsseln, die diese Mitglieder erstellt haben. Ein- und Ausschalten werden in unserem Audit-Protokoll festgehalten. Schaltest du SSO aus oder entfernst seine letzte verifizierte Domain, wird auch „SSO verlangen“ ausgeschaltet; wieder einschalten braucht eine neue Bestätigung. Solange der Workspace keinen aktiven Tarif hat, pausiert SSO und „SSO verlangen“ mit ihm, sodass niemand ausgesperrt ist. Fällt dein Identity Provider aus, kann sich der Inhaber des Workspace weiterhin mit seinem Passwort und Zwei-Faktor-Authentifizierung anmelden: einem Code aus der Authenticator-App oder einem seiner Wiederherstellungscodes. Google bleibt abgelehnt. Deshalb lässt sich „SSO verlangen“ nur einschalten, wenn der Inhaber beides hat, deshalb kann der Inhaber Zwei-Faktor nicht ausschalten, solange es an ist, und deshalb geht die Inhaberschaft nur an jemanden, der beides hat (oder dessen Adresse nicht auf deinen Domains liegt). Jede solche Anmeldung wird protokolliert, und der Inhaber bekommt jedes Mal eine E-Mail. Solange dein SSO an ist, kann der Inhaber immer „Passwort vergessen“ nutzen, mit oder ohne „SSO verlangen“. Niemand kann die Anmelde-E-Mail des Inhabers für ihn ändern, damit sich die Inhaberrolle so nicht übernehmen lässt; verliert der Inhaber Passwort und Authenticator, melde dich bei uns. API-Schlüssel funktionieren weiter: Sie gehören dem Workspace, nicht der Sitzung einer Person, und Integrationen würden sonst ausfallen. Prüfe die in der Bestätigung genannten unter Einstellungen → API. KI-Assistenten (MCP) handeln als die Person; für diese Mitglieder funktioniert der Connector deshalb nur, solange ihre letzte Verbindung nach einer Anmeldung mit SSO hergestellt wurde. Ein Assistent, der nach einer Anmeldung mit Passwort oder Google verbunden wurde, vor oder nach dem Einschalten von „SSO verlangen“, funktioniert nicht mehr, bis sie ihn nach einer Anmeldung mit SSO neu verbinden. „SSO verlangen“ legt fest, wie man sich anmeldet; es entfernt niemanden. Eine mit SSO begonnene Sitzung funktioniert, solange sie genutzt wird, und endet nach 7 Tagen ohne Aktivität. Um jemandem sofort den Zugang zu nehmen, entferne die Person unter Einstellungen → Team: Damit endet ihr Zugang zum Workspace, und die API-Schlüssel, die sie erstellt hat, werden widerrufen. Änderst du deinen Identity Provider, während „SSO verlangen“ an ist (ein neuer Issuer, eine neue Client-ID oder ein neues Secret), bleibt es an: Die neuen Einstellungen müssen sofort funktionieren, und wenn nicht, meldet sich der Inhaber mit Passwort und Zwei-Faktor-Authentifizierung an, um sie zu korrigieren oder „SSO verlangen“ auszuschalten. Die Änderung wird in unserem Audit-Protokoll festgehalten. Nach jeder solchen Änderung lässt sich „SSO verlangen“ erst wieder einschalten, wenn sich jemand über die neuen Einstellungen mit SSO angemeldet hat. Löschst du die SSO-Verbindung, wird „SSO verlangen“ ausgeschaltet, und auch das wird festgehalten.

Ein fehlgeschlagener Versuch führt mit einer kurzen Meldung zurück zur Login-Seite (die Meldungen dort sind auf Englisch). Was sie bedeuten: „isn't available for that email domain“ — die Domain ist nicht verifiziert, SSO ist für sie nicht aktiviert, oder der Workspace hat keinen aktiven Pro-, Agency- oder Scale-Tarif. Die Meldung ist in allen drei Fällen dieselbe, die Login-Seite verrät also niemandem den Tarif eines Workspace; melde dich so lange mit Passwort oder Google an (noch kein Passwort? Leg über „Passwort vergessen“ eins fest). „Couldn't reach your company's identity provider“ — die Issuer-URL unter Einstellungen → SSO stimmt nicht oder der IdP ist nicht erreichbar. „Couldn't verify the response“ oder „didn't return a sign-in token“ — Client-ID oder Client-Secret passen nicht zur App im IdP. „Expired or was opened in a different browser“ — der Versuch hat länger als zehn Minuten gedauert oder Cookies sind blockiert; starte neu. „Hasn't verified your email address“ — der IdP bestätigt dieses Postfach nicht, also melden wir es nicht an. „Domain isn't verified for your workspace's single sign-on“ — dein IdP hat eine Adresse auf einer Domain geliefert, die du nicht verifiziert hast (zum Beispiel eine Alias-Domain oder eine Subdomain); verifiziere auch diese Domain oder lass den IdP die Adresse auf deiner verifizierten Domain senden. „Your company's single sign-on is active again“ — das Passwort, mit dem du dich anmelden wolltest, wurde festgelegt, während SSO nicht verfügbar war, und ist entfernt, seit SSO wieder funktioniert: Klick auf „Continue with single sign-on (SSO)“. „Dein Unternehmen verlangt die Anmeldung mit SSO.“ (dieser Hinweis erscheint in deiner Sprache) — in deinem Workspace ist „SSO verlangen“ eingeschaltet, Passwort und Google melden dich also nicht an: Klick auf „Continue with single sign-on (SSO)“. Eine Fehlermeldung des IdP selbst (zum Beispiel „redirect_uri_mismatch“) heißt: Die dort registrierte App muss korrigiert werden, nicht CrunchJunkie.