Zum Inhalt springen
Einführungsleitfaden

Eine gepflegte Grundlage für Browser- und API-Sicherheit.

Ihr Frontend-Team entwickelt Anwendungsfunktionen und eine verständliche Bedienung. Authentifizierung bringt zusätzlich Token-Verarbeitung, Sitzungsablauf, API-Zugriff und die Koordination mehrerer Anwendungsinstanzen mit sich.

← Alle Szenarien und Leitfäden

Zur ProAuth-Produktfamilie gehören .NET-Pakete für BFF, OAuth/OIDC-Clients und ASP.NET-Core-APIs. Sie liefern wiederverwendbare Implementierungen, die Ihr Team innerhalb seiner Anwendungsarchitektur konfiguriert.

Token-Verarbeitung im Backend
BrowserSPA
Sitzungscookie
BFFIn Ihrer Anwendung
Token + Sendernachweis¹
APIValidierung + Berechtigungen

ProAuth ↔ BFFOIDC / OAuth

Serverseitiger SpeicherTokens, Tickets und koordinierte Erneuerung

¹ Wenn DPoP oder mTLS konfiguriert ist; die API muss den Nachweis prüfen.

Architekturübersicht, kein vollständiger Protokollablauf. Der Browser nutzt ein Sitzungscookie. Der BFF verwendet OIDC/OAuth mit ProAuth und ruft die API mit Token und gegebenenfalls Sendernachweis auf. Die API prüft beides und setzt Berechtigungen durch. Tokens und Tickets liegen im konfigurierten serverseitigen Speicher.

OAuth-Tokens im Backend verarbeiten

Ein Backend for Frontend (BFF) übernimmt den OAuth-Ablauf und leitet API-Aufrufe für die Browser-Anwendung weiter. Mit konfigurierter serverseitiger Ticket- und Token-Speicherung verwendet der Browser ein Sitzungscookie, während OAuth-Tokens im Backend bleiben.

Frontend-Entwickler arbeiten mit Anwendungsendpunkten und den vom BFF bereitgestellten Benutzerinformationen. Sie implementieren weiterhin An- und Abmeldung, das Verhalten bei Sitzungsablauf und den erforderlichen Schutz ihrer Anfragen gegen gefälschte Aufrufe. API-Berechtigungen werden weiterhin im Backend durchgesetzt.

Das Verhalten im Betrieb berücksichtigen

Die BFF-Pakete liefern Integrationen für Sitzungs- und Token-Speicher, Proxying und Token-Erneuerung. Deployments mit mehreren Instanzen benötigen gemeinsamen Speicher, koordinierte Sperren und passende Schlüsselkonfiguration, damit Anfragen instanzübergreifend konsistent verarbeitet werden.

Ihr Team konfiguriert Routen, vertrauenswürdige Proxies, Client-Registrierung, Speicher und Schlüsselverwaltung und prüft die Gesamtanwendung. Dokumentation und CLI-Hilfen unterstützen Konfiguration und Schlüsselerzeugung. Sichere Speicherung und Rotation bleiben Betriebsaufgaben.

Token-Schutz in Clients und APIs einführen

Sendergebundene Tokens binden die Nutzung an einen kryptografischen Schlüssel oder ein Zertifikat des Clients. Der Client liefert den erforderlichen Nachweis, die API prüft ihn. Die ProAuth-Client-Pakete und das ASP.NET-Core-Resource-Server-Paket unterstützen diese Integration einschliesslich der Erkennung wiederverwendeter DPoP-Nachweise.

Beginnen Sie mit ausgewählten Anwendungen. APIs können während einer Migration bestehende Bearer-Token-Clients und korrekt validierte Clients mit sendergebundenen Tokens parallel akzeptieren. Setzen Sie die geforderte Richtlinie verbindlich durch, sobald die relevanten Clients bereit sind. Die Replay-Erkennung über mehrere Instanzen benötigt gemeinsamen Zustand.

PAR und JAR bieten zusätzliche Möglichkeiten zum Schutz von Autorisierungsanfragen. Das FAPI-2.0-Profil von ProAuth ist optional aktivierbar und erfordert passende Client- und API-Konfiguration. Wählen Sie geeignete Kontrollen und prüfen Sie den gesamten Ablauf. Ein aktiviertes Profil ist keine Zertifizierungszusage.

Der nächste Schritt

Prüfen Sie den Ansatz an Ihrem Projekt.

Verfolgen Sie eine Browser-API-Anfrage einschliesslich Anmeldung, Token-Erneuerung, Abmeldung und Sitzungsablauf. Erfassen Sie, wo Tokens, Schlüssel, Tickets und Replay-Zustand liegen und wer sie betreut.

Ihre Browser- und API-Architektur besprechen