Authentifizierung und Autorisierung in Microfrontends

Ein Produkt braucht nicht pro Remote einen Login

Microfrontends trennen Verantwortlichkeiten. Teams können Produktbereiche unabhängig entwickeln, testen und ausliefern. Daraus folgt jedoch nicht, dass jede technisch unabhängige Einheit auch alle übergreifenden Fähigkeiten selbst implementieren muss.

Besonders deutlich wird das bei der Authentifizierung.

Ein Produkt besteht vielleicht aus einem Host und zehn dynamisch geladenen Remotes. Würde jedes Remote den Benutzer selbst anmelden, entstünden zehn Integrationen mit dem Identity Server, zehn Login-Lebenszyklen und zehn Stellen, an denen Tokens gespeichert, erneuert und verworfen werden. Die vermeintliche Autonomie würde vor allem dieselbe technische Verantwortung vervielfachen.

Ein Produkt mit zehn Remotes braucht nicht zehn Logins.

Für gemountete Microfrontends ist ein anderes Modell sinnvoller:

Nicht jedes Remote meldet den Benutzer an. Die Anwendung meldet ihn einmal an.

Die Plattform besitzt den Login-Lebenszyklus und etabliert den Authentifizierungskontext der Anwendung. Die Remotes verwenden diesen Kontext über einen kleinen Vertrag. Sie müssen dafür weder den OpenID-Connect-Flow kennen noch selbst Tokens verwalten.

Die geschützten Backends übernehmen eine andere Verantwortung. Sie entscheiden, ob eine konkrete Aktion auf einer konkreten Ressource erlaubt ist. Ein Remote darf die Oberfläche an bekannte UI-Capabilities anpassen. Es kann aber keine wirksame Autorisierung ersetzen.

Damit entstehen drei klar getrennte Verantwortungen:

OpenID Provider
└── authentifiziert die Person

Host / Plattform
└── besitzt den Authentifizierungskontext

Resource Server
└── autorisiert den Zugriff auf geschützte Ressourcen

Diese Trennung ist wichtiger als die konkrete OIDC-Bibliothek, das verwendete Frontend-Framework oder die Frage, ob die Anwendung ihre API-Zugriffe über einen BFF oder direkt aus dem Browser organisiert.

Die wenigen OIDC-Begriffe, die wirklich notwendig sind

OpenID Connect verwendet eine Reihe standardisierter Begriffe. Für das Architekturmodell einer Microfrontend-Anwendung genügt ein kleiner Ausschnitt.

Begriff	Bedeutung im beschriebenen Modell
End-User	Die Person, die das Produkt verwendet und sich authentifiziert.
User-Agent	Das Programm, über das der End-User handelt. In diesem Fall ist das der Browser.
Client beziehungsweise Relying Party	Die Anwendung, die einen Login benötigt und dem Ergebnis des OpenID Providers vertraut.
OpenID Provider	Der Identity Server, der die Person authentifiziert.
Authorization Endpoint	Der Einstiegspunkt des Login-Flows beim OpenID Provider.
Redirect URI	Die registrierte Adresse, zu der der Browser nach dem Login zur Anwendung zurückkehrt.
Authorization Code	Ein kurzlebiges Zwischenergebnis des erfolgreichen Login-Flows.
ID Token	Eine überprüfbare Aussage des OpenID Providers über die erfolgte Authentifizierung.
Access Token	Ein Credential, das für den Zugriff auf eine geschützte Ressource bestimmt ist.
Resource Server	Die geschützte API, die das für sie bestimmte Access Token und die fachliche Berechtigung des Zugriffs überprüft.

Entscheidend ist zunächst die Rolle des Clients. Bei einer rein browserbasierten Anwendung kann der Host den OIDC-Client implementieren. Bei einer BFF-Architektur kann die eigentliche Protokollabwicklung serverseitig liegen.

Für die Remotes ändert diese technische Variante nichts: Sie sind Bestandteile derselben Anwendung und nicht automatisch zusätzliche Clients gegenüber dem OpenID Provider.

Ein Login, ein Host, mehrere Remotes

Der grundlegende Login-Ablauf muss nicht für jedes Remote wiederholt werden. Er findet an der Grenze zwischen Anwendung und OpenID Provider statt.

1. Der Browser öffnet die Anwendung.
2. Die Plattform erkennt, dass noch kein gültiger Authentifizierungskontext existiert.
3. Die Auth-Schicht der Anwendung startet den OIDC-Flow und leitet den Browser zum OpenID Provider weiter.
4. Der OpenID Provider authentifiziert den End-User.
5. Der Browser kehrt mit einem Authorization Code zur Redirect URI zurück.
6. Die Anwendung verarbeitet das Ergebnis und etabliert ihren Authentifizierungskontext.
7. Anschließend aktiviert sie die geschützten Produktbereiche.

Browserbasierte Clients verwenden dafür heute den Authorization Code Flow mit PKCE. Für die Verantwortungsverteilung zwischen Plattform und Remotes sind die kryptografischen Details jedoch nicht entscheidend.

Das Architekturmodell bleibt überschaubar:

End-User
    │
    ▼
Browser
    │
    ▼
Host / Plattform ─────────► OpenID Provider
    │
    │ etabliert Authentifizierungskontext
    ▼
Remotes
    │
    ▼
geschützte APIs

Die Plattform erkennt, ob bereits ein gültiger Authentifizierungskontext besteht. Falls nicht, startet sie den Login. Nach der erfolgreichen Rückkehr verarbeitet ihre Auth-Schicht das Ergebnis und macht den für die Produktoberfläche notwendigen Kontext verfügbar.

Ein Remote muss dafür weder den Authorization Endpoint noch die Redirect URI kennen. Es benötigt keine eigene OIDC-Konfiguration und muss nicht wissen, wie der Authorization Code verarbeitet oder eine Sitzung beziehungsweise ein Token-Lebenszyklus organisiert wird.

Es muss lediglich erkennen können, ob der Benutzer authentifiziert ist und welche für seine Oberfläche relevanten Informationen verfügbar sind.

Eine Deployment-Einheit ist noch kein OIDC-Client

Microfrontends werden häufig über ihre technische Auslieferung definiert. Ein Remote kann unabhängig gebaut und deployt werden. Sein Bundle liegt möglicherweise auf einem eigenen Server oder wird über eine eigene Domain ausgeliefert.

Diese Deployment-Autonomie sagt jedoch noch nichts darüber aus, wer gegenüber dem OpenID Provider als Client auftritt.

Eine eigene Deployment-Einheit macht ein Remote nicht zu einem eigenen OIDC-Client.

Wird das Remote in einen Host geladen und innerhalb dessen Anwendungskontext ausgeführt, bleibt es Bestandteil dieser Anwendung. Es besitzt keinen eigenen Login-Lebenszyklus, nur weil sein JavaScript separat gebaut wurde. Die Remotes benötigen in diesem Modell weder eigene Redirect URIs noch eigene Login-Flows.

Eigenständig navigierbare Anwendungen sind davon zu unterscheiden. Sie können jeweils eigene Client-Registrierungen besitzen und trotzdem von der SSO-Sitzung des OpenID Providers profitieren. Die Person muss ihre Zugangsdaten dann normalerweise nicht erneut eingeben.

Für das Metamodell genügt diese Abgrenzung:

Client-ID
└── identifiziert eine Anwendung

SSO-Sitzung beim OpenID Provider
└── erkennt einen bereits authentifizierten End-User

Deployment-Autonomie erzeugt weder automatisch einen neuen OIDC-Client noch eine eigene Benutzersitzung.

Die Session muss nicht zwischen Remotes geteilt werden

In Diskussionen über Authentifizierung in Microfrontends fällt häufig der Satz:

Dann müssen die Remotes die Session teilen.

Diese Aussage beginnt bereits mit einem problematischen Modell. Sie setzt voraus, dass jedes Remote zunächst eine eigene Sitzung besitzt und diese anschließend mit anderen Remotes synchronisieren muss.

Das führt zu einer Vorstellung wie dieser:

Remote A besitzt eine Session
        ⇅
Remote B besitzt eine Session
        ⇅
Remote C besitzt eine Session

Bei gemounteten Remotes ist jedoch ein anderes Modell angemessen:

Anwendung besitzt Authentifizierungskontext
        │
        ├── Remote A verwendet ihn
        ├── Remote B verwendet ihn
        └── Remote C verwendet ihn

Eine gemeinsame Anwendungssitzung muss nicht zwischen Remotes verteilt werden. Sie muss zentral besessen und über einen klaren Vertrag nutzbar gemacht werden.

Dabei sind drei Ebenen zu unterscheiden.

Der OpenID Provider kann eine eigene SSO-Sitzung besitzen. Sie ermöglicht ihm, einen bereits authentifizierten End-User bei einem späteren Login-Vorgang wiederzuerkennen.

Die Anwendung kann zusätzlich eine eigene Sitzung oder einen eigenen Token-Lebenszyklus verwalten. Wie sie das technisch umsetzt, ist eine interne Architekturentscheidung.

Die Remotes sehen davon nur den Authentifizierungskontext, den sie für ihre Darstellung und Interaktion benötigen.

Eine Sitzung wird deshalb nicht zwischen Remotes synchronisiert. Sie wird von der Anwendung besessen.

Das Remote braucht Kontext, keine Tokens

Ein Remote muss häufig wissen, ob ein Benutzer angemeldet ist. Es benötigt möglicherweise einen Anzeigenamen, eine stabile Benutzerkennung oder Informationen darüber, welche Funktionen in der Oberfläche angeboten werden sollen.

Daraus folgt aber nicht, dass es Zugriff auf ID Tokens, Access Tokens oder die konkrete OIDC-Client-Instanz erhalten muss.

Ein möglicher frameworkneutraler Plattformvertrag kann klein bleiben:

interface AuthContext {
  status: 'anonymous' | 'authenticated';

  user: {
    id: string;
    displayName: string;
  } | null;

  uiCapabilities: readonly string[];

  requestLogin(): void;
  requestLogout(): void;
}

status und user ermöglichen es dem Remote, seinen sichtbaren Zustand zu bestimmen. Ein anonymer Benutzer erhält möglicherweise einen Login-Hinweis. Ein authentifizierter Benutzer sieht den geschützten Produktbereich und seinen Anzeigenamen.

uiCapabilities helfen, die Oberfläche an grundsätzlich verfügbare Funktionen anzupassen. Sie können Navigationseinträge ausblenden, Aktionen deaktivieren oder unnötige Requests vermeiden. Sie sind eine Projektion für die Oberfläche, keine abschließende Berechtigungsentscheidung.

requestLogin() und requestLogout() drücken Intentionen aus. Ein Remote kann einen Login anfordern oder einen Logout auslösen. Die eigentliche Durchführung delegiert es an die Plattform.

Der Vertrag enthält bewusst keine Roh-Tokens. Er enthält auch keine konkrete OIDC-Bibliothek, keine Storage-Schlüssel, keine Refresh-Callbacks und keine provider-spezifischen Datenstrukturen.

Die Plattform stellt eine Fähigkeit bereit, nicht ihre interne Authentifizierungsimplementierung.

Das ist dieselbe Grenze, die auch für andere Plattformfähigkeiten gilt. Ein Remote soll Navigation verwenden können, ohne den Router des Hosts zu übernehmen. Es soll Benachrichtigungen anzeigen können, ohne deren zentrale Infrastruktur zu besitzen. Ebenso soll es auf den Authentifizierungskontext reagieren können, ohne selbst zum OIDC-Client zu werden.

Das Remote braucht den Benutzerkontext, nicht das Token.

Claims werden in einen Produktvertrag übersetzt

Nach einer erfolgreichen Authentifizierung können ID Token oder andere Antworten des Identity Providers verschiedene Claims enthalten. Claims sind Aussagen über die authentifizierte Person oder den Kontext der Authentifizierung.

Es wäre technisch einfach, diese Struktur vollständig an alle Remotes weiterzureichen. Architektonisch wäre das meist die falsche Grenze.

OIDC Claims
     │
     ▼
Plattform-Adapter
     │
     ▼
stabiler AuthContext

Der Plattform-Adapter übersetzt technische und provider-spezifische Informationen in den stabilen Vertrag des Produkts.

Ein Remote sollte deshalb nicht direkt von beliebigen Rollenpfaden, Gruppenstrukturen oder benutzerdefinierten Provider-Claims abhängen. Solche Felder koppeln die Produktoberfläche an einen konkreten Identity Provider und dessen aktuelle Konfiguration. Ändert sich der Provider oder das Berechtigungsmodell, müssten andernfalls zahlreiche Remotes angepasst werden.

Auch Rollenbezeichnungen sind nicht automatisch geeignete Produktverträge. Eine technische Rolle kann mehrere fachliche Bedeutungen bündeln. Umgekehrt kann eine UI-Capability aus mehreren Rollen, Attributen oder fachlichen Regeln abgeleitet werden.

Der Adapter kapselt diese Unterschiede:

provider-spezifische Claims
        │
        ▼
produktbezogene UI-Capabilities

Dadurch bleiben die Remotes von der konkreten Identitätsinfrastruktur unabhängig. Sie erhalten nur die Informationen, die sie für ihre Oberfläche tatsächlich benötigen.

Das begrenzt außerdem die Verteilung von Identitätsdaten. Nicht jedes Remote benötigt sämtliche Claims über den Benutzer. Ein kleiner Vertrag macht sichtbar, welche Informationen Teil der gemeinsamen Produktplattform sind.

ID Token, Access Token und JWT sind nicht dasselbe

In Frontend-Projekten werden die Begriffe ID Token, Access Token und JWT häufig beinahe synonym verwendet. Dadurch verschwimmen unterschiedliche Verantwortungen.

Das ID Token beschreibt die erfolgte Authentifizierung gegenüber dem Client. Es ist eine überprüfbare Aussage des OpenID Providers darüber, dass und in welchem Kontext der End-User authentifiziert wurde.

Das Access Token ist dagegen für den Zugriff auf eine geschützte Ressource bestimmt. Der Resource Server prüft, ob das Credential für ihn vorgesehen und für den angeforderten Zugriff verwendbar ist.

Das ID Token ist deshalb nicht automatisch das Credential für eine Fach-API.

Ein JWT wiederum ist zunächst ein Format, in dem strukturierte Aussagen transportiert werden können. Ein ID Token wird üblicherweise als JWT dargestellt. Ein Access Token kann ebenfalls ein JWT sein, muss es aber nicht zwingend sein.

JWT beschreibt ein Format. Es beschreibt weder den Zweck eines Tokens noch eine Sitzungsarchitektur.

Aus einem String mit drei durch Punkte getrennten Teilen lässt sich daher noch keine sinnvolle Architektur ableiten. Entscheidend ist, wer das Token ausgestellt hat, für welchen Empfänger es bestimmt ist, welchen Zweck es erfüllt und welche Komponente seinen Lebenszyklus besitzt.

Warum ein Token im localStorage kein gemeinsamer Login ist

Ein verbreitetes Modell für browserbasierte Anwendungen sieht ungefähr so aus:

localStorage.setItem('token', accessToken);

Damit scheint das Credential einfach für alle Bestandteile der Anwendung verfügbar zu sein. Jedes im selben Dokument ausgeführte Remote kann es lesen und seinen Requests hinzufügen.

Gerade diese Einfachheit ist jedoch das Problem.

localStorage ist für JavaScript erreichbar, das im jeweiligen Dokument ausgeführt wird. Bei gemounteten Microfrontends kann dieser Code aus mehreren unabhängig entwickelten und ausgelieferten Remotes stammen. Ein dort gespeichertes Bearer-Credential wird dadurch zu einer global erreichbaren technischen Ressource innerhalb der Anwendung.

Das erzeugt keinen klaren Besitzer. Stattdessen entsteht eine implizite Konvention: Viele Bestandteile dürfen das Credential lesen, aber die Verantwortung für seinen Lebenszyklus bleibt unscharf.

Ein JWT im localStorage ist keine geteilte Session. Es ist ein für JavaScript erreichbares Credential.

Diese Feststellung ist keine pauschale Aussage, dass jede browserbasierte Authentifizierung unzulässig sei. Sie beschreibt die architektonische Folge einer frei zugänglichen Tokenablage.

Das Credential wird zur gemeinsamen Infrastruktur aller Remotes. Änderungen an seinem Namen, seinem Format, seiner Erneuerung oder seinem Ablauf betreffen potenziell das gesamte Frontend. Remotes können eigene Annahmen über seine Gültigkeit treffen oder es versehentlich protokollieren, kopieren und in weiteren Zuständen ablegen.

Eine saubere Plattformgrenze ermöglicht geschützte Aufrufe, ohne den Remotes das zugrunde liegende Credential als globale Ressource anzubieten.

Tokens gehören nicht in globale Events

Der gleiche Fehler kann in einer stärker entkoppelten Form auftreten. Der Host speichert das Token nicht in einem globalen Browser-Storage, sondern verteilt es über Events:

Host
└── veröffentlicht „token-changed“

Remote A speichert das Token
Remote B speichert das Token
Remote C speichert das Token

Formal sind die Remotes nun voneinander getrennt. Tatsächlich besitzen sie jedoch Kopien desselben Credentials und müssen auf denselben technischen Lebenszyklus reagieren.

Was passiert, wenn das Token abläuft? Welches Remote erneuert es? Was geschieht, wenn ein Remote ein veraltetes Event verarbeitet? Wie wird sichergestellt, dass nach einem Logout alle Kopien verworfen wurden? Welche Komponente behandelt Fehler bei der Erneuerung?

Aus einem Besitzer werden mehrere Besitzer. Aus einem Lebenszyklus werden mehrere teilweise synchronisierte Lebenszyklen.

Zusätzlich entsteht eine horizontale Kopplung über den globalen Kanal. Jedes Remote muss das Token-Event und dessen Payload kennen. Die Remotes werden damit unmittelbar an die Authentifizierungsimplementierung der Plattform gebunden.

Token-Sharing ist häufig keine Lösung für Microfrontends, sondern ein Hinweis darauf, dass die Authentifizierungsverantwortung nicht klar geschnitten wurde.

Die bessere Grenze lautet:

Remote
└── nutzt einen Plattform- oder API-Vertrag

Plattform
└── verwaltet Sitzung oder Credential

Tokens sollten deshalb nicht über globale Events, Shared Stores oder frei zugängliche Browserobjekte verteilt werden. Ein globaler Store ändert lediglich den Transportweg. Er beantwortet nicht die Frage nach dem verantwortlichen Besitzer.

Geschützte API-Aufrufe als Plattformfähigkeit

Ein Remote muss auf geschützte APIs zugreifen können. Dafür muss es jedoch nicht selbst ein Access Token besitzen.

Die Grenze kann beispielsweise so aussehen:

Remote
└── fachliches Gateway
    └── authentifizierter Transportadapter
        └── geschützte API

Das Remote ruft eine fachliche Funktion auf:

interface InvoiceGateway {
  approve(invoiceId: string): Promise<void>;
}

Die Implementierung kann intern eine Anwendungssitzung verwenden, einen serverseitigen BFF aufrufen, ein Access Token ergänzen oder eine notwendige Erneuerung organisieren. Diese technischen Entscheidungen bleiben hinter dem Gateway beziehungsweise dem Transportadapter verborgen.

Das Remote soll eine geschützte Operation ausführen können. Es muss nicht wissen, welches Credential die Plattform dafür verwendet.

Ein generischer HTTP-Client kann in einzelnen Produkten sinnvoll sein. Ein fachliches Gateway beschreibt die benötigte Fähigkeit jedoch häufig präziser und verhindert, dass URL-Strukturen und Authentifizierungsdetails in die Präsentationslogik wandern.

Entscheidend ist nicht die konkrete Form der Schnittstelle, sondern die gekapselte Verantwortung. Das Remote darf von geschützter Kommunikation abhängen. Es sollte nicht von der internen Tokenverwaltung der Anwendung abhängen.

BFF oder Browser-Client ändert nicht den Remote-Vertrag

Die Anwendung kann ihre Sitzung und ihre API-Zugriffe unterschiedlich organisieren.

Eine Variante verwendet einen serverseitigen BFF. Der Browser kommuniziert mit diesem Backend, während die eigentliche OIDC- und Tokenverwaltung serverseitig gekapselt bleibt.

Eine andere Variante implementiert den OIDC-Client und die notwendigen Access Tokens zentral im Browser-Host.

Welche Variante angemessen ist, hängt von den Rahmenbedingungen des Produkts ab. Dieser Artikel muss die Entscheidung nicht vorwegnehmen.

Für die Remotes sollte sie möglichst unsichtbar bleiben.

Ob die Anwendung ihre API-Zugriffe über eine serverseitige Sitzung und einen BFF oder über einen zentralen Token-Handler im Browser organisiert, ist eine nachgelagerte Architekturentscheidung. Für die Remotes sollte sich der Vertrag dadurch nicht verändern.

In beiden Fällen meldet sich nicht jedes Remote selbst an. In beiden Fällen verwaltet nicht jedes Remote seinen eigenen Token-Lebenszyklus. Und in beiden Fällen sollte ein Wechsel der Authentifizierungsimplementierung nicht zu einer Migration sämtlicher Produktbereiche führen.

Gerade darin zeigt sich die Qualität des Plattformvertrags: Er trennt die benötigte Fähigkeit von ihrer aktuellen technischen Umsetzung.

Authentifizierung ist nicht Autorisierung

Authentifizierung und Autorisierung beantworten unterschiedliche Fragen:

Authentifizierung
└── Wer ist die Person?

Autorisierung
└── Darf sie diese konkrete Aktion
    auf dieser Ressource ausführen?

Der OpenID Provider authentifiziert den End-User. Er bestätigt gegenüber der Anwendung, dass eine bestimmte Identität erfolgreich geprüft wurde.

Damit ist noch nicht automatisch entschieden, ob diese Person eine Rechnung freigeben, ein Projekt löschen, einen fremden Datensatz bearbeiten oder einen vertraulichen Bericht öffnen darf.

Die Anwendung kann den Authentifizierungskontext verwenden, um ihre Oberfläche sinnvoll zusammenzusetzen. Ein Remote kann Navigation ausblenden, Aktionen deaktivieren und verständliche Hinweise anzeigen.

Die abschließende Autorisierungsentscheidung gehört jedoch in die geschützte API beziehungsweise den Resource Server.

Ein ausgeblendeter Menüpunkt ist keine Autorisierung.

Die Oberfläche kann umgangen werden. Requests können außerhalb des vorgesehenen Bedienflusses erzeugt werden. Eine URL kann direkt aufgerufen und eine API unabhängig vom sichtbaren Remote angesprochen werden.

Ein nicht gemountetes Remote verhindert keinen direkten API-Aufruf.

Deshalb muss der Resource Server die Identität, die angeforderte Aktion, die betroffene Ressource und den fachlichen Kontext prüfen. Nur er kann wirksam erlauben oder verweigern.

Der Identity Provider kann dafür Identitätsinformationen, Rollen oder andere Merkmale liefern. Die fachliche Entscheidung bleibt trotzdem eine Verantwortung der geschützten Ressource. Der Identity Provider kennt nicht automatisch sämtliche Regeln des Fachmodells.

Die Oberfläche darf helfen, das Backend muss entscheiden

UI-Capabilities im Authentifizierungskontext sind dennoch nützlich. Sie verbessern das Produkterlebnis und verhindern, dass Benutzer wiederholt in vorhersehbare Fehler laufen.

Das Frontend kann bekannte Einschränkungen sichtbar machen:

Frontend
├── gestaltet die erlaubten Wege
├── blendet irrelevante Funktionen aus
├── zeigt verständliche Zustände
└── verhindert unnötige Bedienfehler

Das Backend setzt dagegen die wirksame Grenze:

Backend
├── prüft Identität
├── prüft Aktion und Ressource
├── berücksichtigt den fachlichen Kontext
└── erlaubt oder verweigert den Zugriff

Eine UI-Capability wie invoice:approve kann dem Remote signalisieren, dass der Freigabe-Button grundsätzlich angeboten werden darf. Ob eine konkrete Rechnung tatsächlich freigegeben werden kann, hängt möglicherweise zusätzlich von ihrem Status, dem zuständigen Geschäftsbereich, einem Betragslimit oder einer bereits erfolgten Freigabe ab.

Diese Entscheidung kann nicht allein aus einem beim Login ausgestellten Claim abgeleitet werden. Sie gehört zur geschützten Operation.

Das Frontend gestaltet den erlaubten Weg. Das Backend erzwingt ihn.

Das Frontend stellt damit eine möglichst hilfreiche Projektion der Berechtigungen dar. Es muss dennoch mit einer abgelehnten Operation umgehen können. Berechtigungen und fachliche Zustände können sich ändern, ohne dass der Authentifizierungskontext des Browsers sofort neu aufgebaut wird.

Login und Logout bleiben Plattformverantwortung

Ein Remote darf einen Login- oder Logout-Intent auslösen. Es implementiert den OIDC-Ablauf deshalb noch nicht selbst.

Ein öffentlicher Produktbereich kann beispielsweise feststellen, dass eine Aktion einen authentifizierten Benutzer benötigt. Er ruft dann auth.requestLogin() auf. Die Plattform entscheidet, wie der aktuelle Zustand gesichert, welche Redirect URI verwendet und wie der OIDC-Flow gestartet wird.

Entsprechend kann ein Remote auth.requestLogout() auslösen. Die Plattform beendet daraufhin ihren Authentifizierungskontext und führt die dafür vorgesehene Logout-Logik aus.

Das Remote reagiert lediglich auf den sichtbaren Zustand:

switch (auth.status) {
  case 'anonymous':
    return showLoginHint();

  case 'authenticated':
    return showProtectedContent();
}

In einer realen Anwendung kann zusätzlich ein vorübergehender Lade- oder Fehlerzustand sinnvoll sein. Daraus sollte jedoch keine eigene Authentifizierungs-State-Machine pro Remote entstehen.

Ablauf, Erneuerung und Fehlerbehandlung des zentralen Authentifizierungskontexts bleiben Plattformverantwortung. Andernfalls könnten mehrere Remotes gleichzeitig Redirects starten, Erneuerungen anfordern oder den Benutzer aufgrund unterschiedlicher Annahmen abmelden.

Eine Sitzung wird nicht zwischen Remotes synchronisiert. Sie wird von der Anwendung besessen.

Dynamische Remotes brauchen keinen echten Login für jeden Test

Dynamische Remotes sollen unabhängig entwickelt und getestet werden können. Daraus entsteht manchmal die Forderung, jedes Remote müsse auch lokal einen vollständigen OIDC-Login implementieren.

Notwendig ist jedoch nur der Vertrag, nicht die Produktionsimplementierung.

Ein Mini-Host kann kontrollierte Authentifizierungszustände bereitstellen:

Produktion
└── echter Host liefert den AuthContext

Lokale Entwicklung
└── Mini-Host liefert definierte Testidentitäten

Damit lassen sich unterschiedliche Zustände gezielt prüfen:

• nicht authentifiziert,
• normaler Benutzer,
• Benutzer mit bestimmten UI-Capabilities,
• abgelaufener oder nicht verfügbarer Kontext.

Der Mini-Host benötigt dafür keine echten Produktionstokens. Er kann einen stabilen Benutzerkontext und vorhersehbare API-Antworten simulieren.

Der Mini-Host simuliert den Plattformvertrag. Er macht das Remote nicht zu einem eigenen Authentifizierungssystem.

Diese Form der Entwicklung stärkt die Autonomie des Remotes, ohne die Plattformverantwortung zu duplizieren. Das Team kann seine Oberfläche unabhängig testen und muss trotzdem keine zweite Login-Architektur pflegen.

Gleichzeitig wird der Vertrag explizit. Ein Remote, das nur mit einer konkreten OIDC-Client-Instanz oder einem bestimmten Token im localStorage funktioniert, ist nicht wirklich unabhängig. Es ist lediglich implizit an die Produktionsumgebung gekoppelt.

Was wie Autonomie aussieht, vervielfacht oft nur Infrastruktur

Wird die Authentifizierung in jedes Remote verlagert, entstehen nicht automatisch fachlich autonome Produktbereiche. Es entstehen zunächst mehrere Implementierungen derselben Plattformfunktion.

Jedes Team wählt möglicherweise eine eigene OIDC-Bibliothek oder eine andere Version derselben Bibliothek. Callback-Verarbeitung, Tokenablage, Erneuerung und Logout werden mehrfach umgesetzt. Fehlerzustände unterscheiden sich. Einige Remotes leiten sofort zum Login weiter, andere zeigen einen Hinweis, wieder andere bleiben in einem inkonsistenten Ladezustand.

Auch die Kopplung an den Identity Provider wächst. Provider-spezifische Claims, Konfigurationsschlüssel und Rollenstrukturen verteilen sich über das gesamte Produkt. Eine Migration betrifft dann nicht mehr eine Plattformkomponente, sondern zahlreiche unabhängig ausgelieferte Remotes.

Die zusätzliche technische Freiheit führt damit zu höheren Sicherheits-, Wartungs- und Abstimmungskosten.

Was wie zusätzliche Autonomie des Remotes aussieht, vervielfacht häufig nur dieselbe Infrastrukturverantwortung.

Ein zentraler Plattformvertrag erzeugt dagegen eine erkennbare Verantwortung. Login und Logout verhalten sich im gesamten Produkt einheitlich. Der Identity Provider kann ausgetauscht oder anders angebunden werden, ohne dass jedes Remote dessen interne Strukturen kennen muss.

Die Verträge werden kleiner. Tests werden einfacher. Die Remotes können definierte Identitäten verwenden, ohne Produktionstokens zu benötigen. Benutzer erleben eine Anwendung statt einer Ansammlung konkurrierender Login-Implementierungen.

Authentifizierungsautonomie ist bei gemounteten Remotes selten echte fachliche Autonomie. Meist ist sie duplizierte Plattformtechnik.

Authentifizierung ist eine Plattformfähigkeit

Microfrontends sollen fachliche Verantwortung trennen. Sie sollen Teams ermöglichen, Produktbereiche unabhängig weiterzuentwickeln. Diese Unabhängigkeit entsteht jedoch nicht dadurch, dass jede globale Fähigkeit mehrfach implementiert wird.

Bei gemounteten Microfrontends gehört die Authentifizierung zur Anwendung beziehungsweise zur Plattform.

Die Plattform besitzt die OIDC-Client-Verantwortung und etabliert den Authentifizierungskontext. Bei einer rein browserbasierten Umsetzung kann der Host den Protokollablauf ausführen; bei einer BFF-Architektur kann diese Verantwortung serverseitig implementiert sein. Für die Remotes bleibt der Vertrag gleich.

Sie erhalten einen kleinen, stabilen und frameworkneutralen Authentifizierungskontext. Sie kennen den Benutzer- und UI-Kontext, aber normalerweise keine Roh-Tokens, keine Redirect URIs und keine konkrete OIDC-Client-Instanz.

Eine eigene Deployment-Einheit macht ein Remote nicht zu einem eigenen OIDC-Client. Ebenso ist eine gemeinsame Sitzung kein Zustand, der zwischen Remotes verteilt und synchronisiert werden muss.

Ein Produkt mit zehn Remotes braucht nicht zehn Logins.

Eine Sitzung wird nicht zwischen Remotes synchronisiert. Sie wird von der Anwendung besessen.

Das Remote braucht den Benutzerkontext, nicht das Token.

Die Oberfläche kann anhand von UI-Capabilities verständliche Wege anbieten und nicht verfügbare Funktionen ausblenden. Die abschließende Entscheidung über eine geschützte Operation trifft jedoch der Resource Server.

Das Frontend gestaltet den erlaubten Weg. Das Backend erzwingt ihn.

Authentifizierung ist eine Plattformfähigkeit. Autorisierung bleibt eine Verantwortung der geschützten Ressource.