Nextcloud und OAuth2: Ein tiefer Blick auf Authentifizierung, Tokens und die Frage, wem man eigentlich vertraut

Wer heute eine Nextcloud-Instanz betreibt, kommt früher oder später an den Punkt, an dem das lokale Benutzerkonto nicht mehr genügt. Vielleicht sollen Mitarbeiter sich mit ihrem bestehenden Microsoft-Konto anmelden. Vielleicht soll eine externe Anwendung auf Dateien zugreifen, ohne dass jemand das Passwort weitergibt. Oder es geht schlicht darum, dass die IT-Abteilung nicht länger fünfzehn verschiedene Passwörter pflegen möchte. In allen diesen Fällen landet man bei OAuth2 – genauer gesagt bei dem, was Nextcloud unter diesem Begriff versteht, und das ist deutlich mehr, als die reine Spezifikation vermuten lässt.

Der folgende Beitrag versucht, das Thema einigermaßen vollständig zu beleuchten. Nicht als Schnellstartanleitung, sondern als Orientierung für Administratoren, Integratoren und Entscheider, die verstehen wollen, was im Hintergrund passiert und an welchen Stellen man sich die Finger verbrennen kann. Denn OAuth2 ist, das sei vorweg gesagt, kein Sicherheitsversprechen. Es ist ein Rahmenwerk, und wie so oft liegt die Verantwortung bei dem, der es einsetzt.

Was OAuth2 in Nextcloud eigentlich bedeutet

Zunächst eine Begriffsklärung, die in vielen Diskussionen untergeht: Nextcloud tritt in zwei völlig unterschiedlichen Rollen auf, wenn von OAuth2 die Rede ist. Einerseits kann die Instanz als OAuth2-Provider agieren, also als jene Stelle, die Tokens ausstellt. Andererseits kann sie als OAuth2-Consumer auftreten, also als Anwendung, die sich gegenüber einem externen Identitätsanbieter authentifiziert. Beide Rollen haben eigene Apps, eigene Fallstricke und eine recht unterschiedliche Relevanz für den Betrieb.

Die Provider-Rolle steckt in der App oauth2, die seit Jahren zum Standardumfang gehört. Sie ist standardmäßig aktiv, sobald die Instanz installiert ist – ein Detail, das viele nicht wissen und das durchaus sicherheitsrelevant ist. Über diese App lassen sich sogenannte OAuth2-Clients registrieren, also Anwendungen, die im Namen eines Nutzers auf Nextcloud-Ressourcen zugreifen dürfen. Typische Nutznießer sind Desktop-Clients, Mobile-Apps, aber auch Drittanbieter wie Monitoring-Tools, Skripte oder Anbindungen an eine externe Wissensdatenbank.

Die Consumer-Rolle hingegen ist nicht im Kern enthalten. Wer Nextcloud gegen Keycloak, Authentik, Azure AD (beziehungsweise Entra ID), Okta oder einen anderen OpenID-Connect-fähigen Identity Provider betreiben will, braucht die App user_oidc, früher bekannt als oidc oder im Umfeld von ownCloud als openidconnect. Diese App wurde vom Nextcloud-Team übernommen und wird inzwischen aktiv gepflegt, auch wenn sie in manchen Deployments noch als Stiefkind behandelt wird.

Ein interessanter Aspekt: Beide Rollen bedienen sich zwar derselben Protokollfamilie, folgen aber unterschiedlichen Denkweisen. Der Provider stellt Vertrauen her, der Consumer konsumiert es. Und genau an der Nahtstelle zwischen beiden entstehen jene Probleme, über die in Foren und Mailinglisten am häufigsten diskutiert wird.

Die Provider-Seite: Nextcloud als Token-Ausgeber

Wer die OAuth2-App in den administrativen Einstellungen öffnet, sieht zunächst wenig Spektakuläres. Man kann einen Client anlegen, ihm einen Namen geben, eine Redirect-URI hinterlegen und erhält anschließend Client-ID und Client-Secret. Das war es im Wesentlichen. Keine granularen Scopes, keine ausgeklügelten Policies, keine Rollenverwaltung auf Token-Ebene. Nextcloud beschränkt sich hier bewusst auf das Nötigste – und das ist je nach Anwendungsfall Fluch und Segen zugleich.

Was die Provider-Implementierung kann – und was nicht

Die aktuelle Umsetzung unterstützt den Authorization-Code-Flow mit optionalem PKCE sowie den Client-Credentials-Flow. Ein Resource-Owner-Password-Credentials-Flow, wie er in älteren Integrationen noch gelegentlich vorausgesetzt wird, ist nicht vorgesehen. Wer also eine Anwendung anbinden möchte, die ausschließlich diesen Flow beherrscht, steht vor der Wahl, entweder die Anwendung zu patchen oder einen vorgeschalteten Proxy wie OAuth2-Proxy, Keycloak oder Authentik einzusetzen.

Scopes sind in Nextcloud praktisch nicht granular. Die von der App ausgestellten Tokens gewähren Zugriff auf die vollständige API im Namen des Nutzers. Es gibt keinen Weg, einem Client zu sagen: „Du darfst nur Dateien lesen, aber keine Kalender anfassen.“ Das ist eine Einschränkung, die in regulierten Umgebungen schmerzt. In der Praxis behilft man sich, indem man eigene, möglichst wenig privilegierte Benutzerkonten für Integrationen anlegt – ein Vorgehen, das funktioniert, aber nicht schön ist.

Ein weiterer Punkt, der immer wieder für Verwirrung sorgt: Die Nextcloud-OAuth2-App ist nicht identisch mit dem klassischen Nextcloud-App-Token-Konzept. Jeder angemeldete Nutzer kann in seinen persönlichen Sicherheitseinstellungen App-Passwörter generieren, die ebenfalls für API-Zugriffe verwendet werden können. Diese App-Passwörter haben mit OAuth2 technisch nichts zu tun, erfüllen aber in vielen Szenarien denselben Zweck. Man sollte sich dessen bewusst sein, bevor man mit großem Aufwand eine OAuth2-Integration baut, die am Ende durch ein simples App-Passwort ersetzt werden könnte.

Redirect-URIs, Wildcards und der Ärger mit dem Reverse-Proxy

Ein Klassiker, über den sich Einsteiger regelmäßig die Haare raufen: Die Redirect-URI, die bei der Client-Registrierung angegeben wird, muss exakt mit der URI übereinstimmen, die der Client beim Authorization-Request mitschickt. Nextcloud akzeptiert keine Wildcards, keine Trailing-Slashes-Toleranz, keine Groß-/Kleinschreibung-Abweichungen. Wer hinter einem Reverse-Proxy mit abweichendem Hostnamen arbeitet – etwa intern cloud.local, extern cloud.example.com –, muss sicherstellen, dass die in der Konfiguration hinterlegte trusted_domains-Liste und die tatsächliche Request-URL konsistent sind. Andernfalls bricht der Flow an einer Stelle ab, an der die Fehlermeldung maximal unspezifisch ist.

Hilfreich ist hier ein Blick in das Nextcloud-Log (data/nextcloud.log). Bei fehlgeschlagenen OAuth2-Vorgängen findet man dort in der Regel einen Hinweis auf das Problem, auch wenn dieser nicht immer selbsterklärend ist. Nicht selten lautet er schlicht „Invalid redirect URI“, und der geneigte Administrator darf dann selbst raten, welche Nuance gemeint ist.

Die Consumer-Seite: Nextcloud als abhängige Anwendung

Deutlich komplexer wird die Angelegenheit, wenn Nextcloud sich gegen einen externen Identity Provider authentifizieren soll. Hier kommt die App user_oidc ins Spiel, und hier entscheidet sich, ob ein Single-Sign-on-Setup im Alltag funktioniert oder zur dauerhaften Baustelle wird.

Warum überhaupt ein externer IdP?

Die Argumente für einen zentralen Identity Provider sind bekannt und dennoch unterschiedlich schwergewichtig. In Unternehmen mit heterogener Anwendungslandschaft ist die zentrale Benutzerverwaltung der offensichtlichste Vorteil: Ein Austritt, eine Deaktivierung, und der Zugang zu allen verbundenen Diensten endet gleichzeitig. Für kleinere Installationen hingegen kann genau das zum Nachteil werden, weil der IdP selbst betrieben, aktualisiert und abgesichert werden muss.

Ein zweiter Grund, der oft übersehen wird: Multi-Faktor-Authentifizierung. Nextcloud bringt zwar eine eigene TOTP-Unterstützung mit, und es gibt Apps für WebAuthn. Aber wenn im Unternehmen bereits eine zentrale MFA-Lösung existiert, will man diese nicht doppelt pflegen. Über einen externen IdP lässt sich MFA erzwingen, ohne dass die Nextcloud-Instanz davon überhaupt etwas mitbekommt.

Nicht zuletzt spielt die Provisionierung eine Rolle. Wer neu in ein Team kommt, soll nicht erst einen Admin bitten müssen, ein Nextcloud-Konto anzulegen. Der IdP kennt die Person bereits, liefert die relevanten Attribute, und Nextcloud übernimmt sie beim ersten Login.

Ersteinrichtung mit Keycloak als Beispiel

Die Einrichtung folgt im Prinzip immer demselben Muster, egal ob Keycloak, Authentik, Entra ID oder ein anderer Anbieter dahintersteht:

• Im IdP wird ein Client vom Typ „confidential“ angelegt, mit gültiger Redirect-URI auf https://cloud.example.com/apps/user_oidc/code.
• Die Client-ID und das Secret werden notiert.
• In Nextcloud wird die App user_oidc aktiviert und über die administrativen Einstellungen konfiguriert: Discovery-Endpunkt (typischerweise /.well-known/openid-configuration), Client-ID, Secret, eventuell explizite Endpunkt-URLs, falls der IdP keine Discovery anbietet.
• Optional lassen sich Attribute wie die E-Mail-Adresse oder der Anzeigename auf Nextcloud-Felder mappen.

Nach dem Speichern erscheint auf dem Nextcloud-Login-Bildschirm ein zusätzlicher Button. Wer darauf klickt, wird zum IdP weitergeleitet, authentifiziert sich dort und landet mit einem gültigen Token zurück in Nextcloud. Im Idealfall sieht man dabei nicht einmal einen zweiten Login-Schirm.

In der Realität läuft es jedoch selten beim ersten Versuch. Häufige Stolpersteine sind fehlende oder falsch konfigurierte Claims, abweichende Subject-Identifier (etwa wenn der IdP die E-Mail-Adresse als sub verwendet und diese sich ändert), sowie Gruppeninformationen, die nicht in Nextcloud ankommen. Grundsätzlich gilt: Je expliziter der IdP konfiguriert ist, desto weniger Überraschungen. Auto-Discovery und dynamische Client-Registrierung klingen praktisch, führen aber in der Praxis zu Fehlern, die schwer zu diagnostizieren sind.

Gruppen-Provisionierung und Rollenmapping

Ein Feature, das viele unterschätzen: user_oidc kann Gruppen aus dem IdP übernehmen und in Nextcloud abbilden. Das funktioniert, indem der IdP einen Claim mit Gruppeninformationen liefert – bei Keycloak etwa groups, bei Entra ID typischerweise roles oder groups über den entsprechenden Endpunkt. Nextcloud legt die Gruppen bei Bedarf an und ordnet den Nutzer zu.

Wichtig zu verstehen: Das ersetzt keine vollständige Gruppenverwaltung. Wenn ein Nutzer aus einer Gruppe im IdP entfernt wird, wird er in Nextcloud nicht automatisch aus der entsprechenden Gruppe entfernt – zumindest nicht in älteren Versionen der App. Die Synchronisation erfolgt in der Regel nur beim Login. Wer einen nächtlichen Cronjob erwartet, der die Gruppenstruktur abgleicht, wird enttäuscht. Das mag für viele Szenarien ausreichen, ist aber für Umgebungen mit strengen Compliance-Anforderungen ein echter Schwachpunkt.

Ein weiterer Punkt: Gruppen, die in Nextcloud administrativen Zugriff verleihen, sollten niemals blind aus einem IdP übernommen werden. Wenn im IdP ein Claim falsch gesetzt ist oder ein Angreifer Zugriff auf die Gruppenverwaltung erlangt, wird daraus schnell ein Rechte-Problem in der Cloud. Man sollte also sehr genau überlegen, welche IdP-Gruppen auf welche Nextcloud-Gruppen abgebildet werden – und Admin-Gruppen besser manuell pflegen.

OAuth2 und die Nextcloud-Clients: Desktop, Mobile, Talk

Eine Frage, die in Einführungsworkshops regelmäßig gestellt wird: Funktioniert der Desktop-Client mit einem externen IdP? Die Antwort lautet ja, aber mit einem Umweg. Der Client selbst öffnet beim Anlegen eines Kontos einen Browser, in dem der Login-Flow abgeschlossen wird. Bei einem externen IdP ist dies der richtige Weg – der Nutzer authentifiziert sich dort und der Client erhält anschließend einen Token, der für die weitere Kommunikation genutzt wird.

Problematisch wird es, wenn der IdP keine Browser-Redirects zulässt oder wenn der Client auf einem System läuft, auf dem kein Browser verfügbar ist (seltener Fall, aber möglich). Dann greift man auf App-Passwörter zurück – sofern der IdP das nicht unterbindet. Hier zeigen sich die Grenzen der Integration: App-Passwörter werden gegenüber Nextcloud verwendet, nicht gegenüber dem IdP. Sie sind also nur dann möglich, wenn der Nutzer zuvor durch einen regulären Login gegangen ist, um sie überhaupt generieren zu können. Bei SSO-only-Setups ohne Passwort-Authentifizierung wird das schnell zum Henne-Ei-Problem.

Nextcloud Talk, die hauseigene Videokonferenzlösung, nutzt intern ebenfalls OAuth2-Mechanismen – allerdings zwischen Server und Clients, nicht zwischen Nutzer und IdP. Das ist nur dann relevant für Administratoren, wenn Talk gegen einen externen Signaling-Server betrieben wird oder wenn Gastlinks in einem SSO-Setup funktionieren sollen. Letzteres ist ein Spezialfall, der immer wieder Fragen aufwirft: Gäste haben naturgemäß kein Konto im IdP und müssen über eine alternative Authentifizierung in den Talk-Raum kommen.

Sicherheitsaspekte, die oft übersehen werden

OAuth2 ist kein Allheilmittel. Es ist ein Werkzeug, das falsch eingesetzt mehr Schaden anrichten kann als eine schlichte Passwort-Authentifizierung. Einige Aspekte, die in der Praxis regelmäßig zu kurz kommen:

Token-Lebensdauer und Refresh

Nextcloud stellt als Provider Access Tokens mit einer recht langen Gültigkeit aus – konkret hängt die Gültigkeitsdauer von der Konfiguration ab, und sie unterscheidet sich zwischen den Flows. Refresh Tokens sind ebenfalls möglich. Was fehlt, ist eine administrative Oberfläche, über die man Tokens einsehen und widerrufen kann. Wer wissen will, welche OAuth2-Clients derzeit gültige Tokens besitzen, muss in die Datenbank schauen. Das ist nicht nur unbequem, sondern in Vorfalls- oder Compliance-Situationen ein echtes Problem.

Die Empfehlung lautet daher, den Refresh-Flow zu nutzen und die Access-Token-Lebensdauer kurz zu halten. Das erfordert allerdings, dass die angebundene Anwendung sauber mit Refresh umgehen kann. Nicht jede tut das, und manche Integrationen scheitern daran, dass ihre Autoren den Refresh-Flow schlicht ignoriert haben.

Client-Secrets richtig behandeln

Ein Klassiker: Beim Anlegen eines OAuth2-Clients wird das Secret einmal angezeigt und danach nie wieder im Klartext. Wer es nicht sofort hinterlegt, muss den Client neu anlegen. In der Praxis führt das dazu, dass Secrets in irgendwelchen Ticketsystemen, Chatverläufen oder – schlimmer – Konfigurationsdateien im Klartext landen. Ein Umdenken ist hier dringend ratsam. Secrets gehören in einen Secret Store, egal wie klein die Umgebung ist.

Public Clients, also Anwendungen, die kein Secret sicher verwahren können (etwa Single-Page-Webanwendungen oder mobile Apps), sollten PKCE verwenden. Nextcloud unterstützt dies. Man sollte darauf achten, dass PKCE auch tatsächlich aktiviert ist und nicht durch eine Konfigurationsoption umgangen wird.

Die Kleinigkeit mit den Redirect-URIs

Immer wieder unterschätzt: Eine zu großzügig konfigurierte Redirect-URI kann als Einfallstor dienen, um Tokens abzugreifen. Zwar prüft Nextcloud exakt, aber wenn man etwa https://app.example.com/* erlaubt – was die App nicht tut, aber manche IdPs schon –, öffnet das Tür und Tor. Die konservative Regel lautet: exakt eine URI pro Client, keine Wildcards, keine zusätzlichen Test-URLs.

Der Fall user_oidc: Wenn SSO plötzlich nicht mehr funktioniert

Es gibt kaum eine Betriebsphase, in der nicht irgendwann das Setup zusammenbricht. Ein Zertifikat läuft ab, der IdP wird aktualisiert, die Nextcloud-Version steigt, und plötzlich können sich Nutzer nicht mehr anmelden. Eine kleine Auswahl an Szenarien, die in der Praxis häufig auftreten:

• Discovery-Endpunkt antwortet nicht: Oft ein Zertifikatsproblem. Nextcloud prüft TLS streng, und selbstsignierte Zertifikate im IdP werden abgelehnt. Ein occ-Kommando, um dies temporär zu umgehen, existiert, sollte aber nur für Diagnosezwecke verwendet werden.
• Clock-Skew: Wenn Nextcloud und IdP unterschiedliche Uhrzeiten haben, laufen Token-Validierungen fehl. Ein NTP-Setup, das den Namen verdient, ist hier die halbe Miete.
• Claim-Namen ändern sich: IdPs sind da kreativ. Ein Update kann den Namen eines Claims ändern, und Nextcloud findet die erwartete E-Mail-Adresse nicht mehr. Ein Blick ins Token (etwa mit jwt.io) hilft, das Problem zu isolieren.
• Subject-Identifier nicht stabil: Wenn der IdP das Feld sub ändert – etwa nach einem Migrationsschritt –, kann Nextcloud den Nutzer nicht mehr zuordnen und legt im schlimmsten Fall einen neuen an. Die Folge: Doppelte Konten, verlorene Freigaben, Frust.
• Cache: Die App cached Discovery-Daten. Nach Änderungen am IdP kann ein geleerter Cache Wunder wirken.

Hilfreich in all diesen Fällen: Logging auf beiden Seiten hochdrehen, den tatsächlichen Redirect-Flow im Browser nachverfolgen (Entwicklertools, Netzwerk-Tab), und die Claims im ID-Token inspizieren. Nicht selten liegt das Problem in einem einzigen Feld, das der IdP in einem Format liefert, das Nextcloud so nicht erwartet.

OAuth2 in der Praxis: Beispiele für gelungene und weniger gelungene Integrationen

Ein gelungenes Beispiel ist die Anbindung einer Monitoring-Anwendung, die regelmäßig Dateien aus einem bestimmten Nextcloud-Verzeichnis liest und in ein Dashboard einspeist. Hier genügt ein eigener, technischer Nutzer mit eingeschränkten Rechten, ein OAuth2-Client mit exakt einer Redirect-URI und einem Refresh-Token, das die Anwendung sauber erneuert. Der Aufwand ist überschaubar, der Nutzen klar.

Ein weniger gelungenes Beispiel ist der Versuch, eine Drittanbieter-Webanwendung ohne SSO-Unterstützung anzubinden, indem man mit viel Mühe einen OAuth2-Proxy dazwischenbaut. Das funktioniert, ist aber wartungsintensiv und bricht bei jedem Update des Proxys oder der Anwendung aufs Neue. In solchen Fällen ist es oft sinnvoller, auf eine andere Lösung zu wechseln oder die Anbindung gänzlich zu überdenken.

Ein Sonderfall, der immer wieder unterschätzt wird: Die Anbindung von Nextcloud an ein bestehendes Microsoft-365-Umfeld über Entra ID. Hier treffen zwei unterschiedliche Welten aufeinander. Entra ID ist funktional mächtig, hat aber Eigenheiten, die die Integration erschweren. Beispielsweise werden Gruppen nicht in jedem Token mitgeliefert; man muss den entsprechenden Endpunkt explizit konfigurieren, und die Anzahl der Gruppen pro Nutzer ist begrenzt. Wer hier nachlässig plant, merkt das erst, wenn das Rollout in Produktion geht.

Was Nextcloud noch verbessern könnte – und was Administratoren selbst tun können

Man kann es offen sagen: Die OAuth2-Unterstützung in Nextcloud ist zweckmäßig, aber nicht elegant. Die Provider-Seite ist schlicht, teils zu schlicht. Die Consumer-Seite ist funktional, aber mit einer Reihe von Ecken und Kanten behaftet, die langjährige Administratoren regelmäßig zur Verzweiflung treiben.

Was sich Administratoren wünschen, wären unter anderem:

• Granulare Scopes für die Provider-Seite, damit Clients nur die Rechte bekommen, die sie wirklich brauchen.
• Eine administrative Oberfläche zur Token-Verwaltung, inklusive der Möglichkeit, Tokens zu widerrufen.
• Bessere Diagnosewerkzeuge, etwa einen Log-Viewer, der OAuth2-Vorgänge filtert und verständlich aufbereitet.
• Regelmäßige Gruppensynchronisation statt Zuordnung nur beim Login.
• Eine saubere Trennung zwischen App-Passwörtern und OAuth2-Tokens in der Dokumentation, damit Einsteiger nicht den falschen Weg wählen.

Bis dahin gilt: Wer Nextcloud mit OAuth2 betreibt, sollte sich mit den Grundlagen des Protokolls vertraut machen. Nicht bis ins letzte Detail, aber so weit, dass man den Flow nachvollziehen kann. Nur dann ist man in der Lage, Fehlermeldungen richtig zu interpretieren und gezielt zu reagieren.

Es lohnt sich außerdem, die Konfiguration zu dokumentieren. Wer in einem Jahr eine neue Kollegin einarbeitet oder selbst nach einem Ausfall Hand anlegt, wird dankbar sein. OAuth2-Konfigurationen sind nichts, was man im Kopf behält.

Fazit: Ein mächtiges Werkzeug, aber kein Selbstläufer

Nextcloud und OAuth2 – das ist eine Beziehung, die in den letzten Jahren deutlich gereift ist, aber noch längst nicht perfekt funktioniert. Die Provider-Seite ist für einfache Anbindungen ausreichend, die Consumer-Seite mit user_oidc ist stabil genug für viele Produktionsumgebungen. Wer jedoch komplexe Anforderungen hat – granulare Rechte, saubere Gruppenverwaltung, umfassendes Monitoring –, wird an der einen oder anderen Stelle Kompromisse eingehen müssen oder auf zusätzliche Komponenten wie Keycloak, OAuth2-Proxy oder Authentik zurückgreifen.

Das ist kein Grund, das Thema zu meiden. Im Gegenteil: Wer Nextcloud heute ernsthaft betreibt, kommt an einer Auseinandersetzung mit OAuth2 und OpenID Connect nicht vorbei. Die Alternative wäre, für jede Integration ein eigenes Passwort zu pflegen, jede Anbindung von Hand zu konfigurieren und bei jeder personellen Änderung manuell nachzuziehen. Das mag in kleinen Installationen funktionieren, skaliert aber nicht – und ist aus Sicherheitsgesichtspunkten schwer zu verteidigen.

Die Empfehlung lautet daher: So früh wie möglich mit dem Thema befassen, lieber mit einem kleinen Szenario anfangen und dieses sauber umsetzen, als gleich die große SSO-Revolution zu versuchen. Wer einen IdP einführt, sollte ihn für mindestens zwei Anwendungen nutzen, sonst steht der Aufwand in keinem Verhältnis zum Nutzen. Und wer die Provider-Seite einsetzt, sollte gelegentlich prüfen, welche Clients tatsächlich registriert sind – nicht selten finden sich dort Altlasten aus Testphasen, die längst nicht mehr benötigt werden, aber weiterhin gültige Tokens besitzen.

Am Ende bleibt ein Satz, den man kaum oft genug betonen kann: OAuth2 verschiebt die Verantwortung für Sicherheit, es nimmt sie einem nicht ab. Wer die Tokens ausstellt, muss wissen, wem er vertraut. Wer sie entgegennimmt, muss wissen, was er damit anfängt. Und wer beides betreibt, tut gut daran, die Konfiguration regelmäßig zu prüfen. Nextcloud macht das nicht von selbst.

In diesem Sinne: Die OAuth2-Integration ist eine der Baustellen, an denen sich zeigt, ob eine Nextcloud-Umgebung ernsthaft betrieben wird oder nur so aussieht. Wer sie beherrscht, hat einen erheblichen Teil der administrativen Arbeit hinter sich. Wer sie ignoriert, wird früher oder später darüber stolpern – meist genau dann, wenn es gerade am wenigsten passt.