Wie man OIDC-Anmeldung mit .NET Core (Blazor Server) erstellt

Für unsere neuen Freunde:

Logto ist eine Auth0-Alternative, die für moderne Apps und SaaS-Produkte entwickelt wurde. Es bietet sowohl Cloud als auch Open-Source Dienste, um dir zu helfen, dein Identity and Management (IAM) System schnell zu starten. Genieße Authentifizierung, Autorisierung und Multi-Tenant-Management alles in einem.

Wir empfehlen, mit einem kostenlosen Entwicklungsmieter auf Logto Cloud zu beginnen. Dies ermöglicht es dir, alle Funktionen einfach zu erkunden.

In diesem Artikel werden wir die Schritte durchgehen, um schnell die OIDC Anmeldeerfahrung (Benutzerauthentifizierung) mit .NET Core (Blazor Server) und Logto aufzubauen.

Voraussetzungen

Eine laufende Logto-Instanz. Sieh dir die Einführungsseite an, um loszulegen.
Grundkenntnisse in .NET Core (Blazor Server).
Ein nutzbares OIDC Konto.

Eine Anwendung in Logto erstellen

Logto basiert auf OpenID Connect (OIDC) Authentifizierung und OAuth 2.0 Autorisierung. Es unterstützt föderiertes Identitätsmanagement über mehrere Anwendungen hinweg, was allgemein als Single Sign-On (SSO) bezeichnet wird.

Um deine Traditionelle Webanwendung Anwendung zu erstellen, folge einfach diesen Schritten:

Öffne die Logto Console. Klicke im Abschnitt "Erste Schritte" auf den Link "Alle anzeigen", um die Liste der Anwendungs-Frameworks zu öffnen. Alternativ kannst du zu Logto Console > Applications navigieren und auf die Schaltfläche "Anwendung erstellen" klicken.
Klicke im sich öffnenden Modal auf den Abschnitt "Traditionelle Webanwendung" oder filtere alle verfügbaren "Traditionelle Webanwendung" Frameworks mit den Schnellfilter-Checkboxen auf der linken Seite. Klicke auf die ".Net Core (Blazor Server)" Framework-Karte, um mit der Erstellung deiner Anwendung zu beginnen.
Gib den Anwendungsnamen ein, z. B. "Buchladen", und klicke auf "Anwendung erstellen".

🎉 Ta-da! Du hast gerade deine erste Anwendung in Logto erstellt. Du wirst eine Glückwunschseite sehen, die einen detaillierten Integrationsleitfaden enthält. Folge dem Leitfaden, um zu sehen, wie die Erfahrung in deiner Anwendung sein wird.

.Net Core (Blazor Server) SDK integrieren

tipp:

Die folgende Demonstration basiert auf .NET Core 8.0. Das SDK ist kompatibel mit .NET 6.0 oder höher.
Die .NET Core-Beispielprojekte sind im GitHub-Repository verfügbar.

Installation

Füge das NuGet-Paket zu deinem Projekt hinzu:

dotnet add package Logto.AspNetCore.Authentication

Logto-Authentifizierung hinzufügen

Öffne Startup.cs (oder Program.cs) und füge den folgenden Code hinzu, um die Logto-Authentifizierungsdienste zu registrieren:

Program.cs
using Logto.AspNetCore.Authentication;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddLogtoAuthentication(options =>
{
  options.Endpoint = builder.Configuration["Logto:Endpoint"]!;
  options.AppId = builder.Configuration["Logto:AppId"]!;
  options.AppSecret = builder.Configuration["Logto:AppSecret"];
});

Die Methode AddLogtoAuthentication wird Folgendes tun:

Das Standard-Authentifizierungsschema auf LogtoDefaults.CookieScheme setzen.
Das Standard-Challenge-Schema auf LogtoDefaults.AuthenticationScheme setzen.
Das Standard-Abmeldeschema auf LogtoDefaults.AuthenticationScheme setzen.
Cookie- und OpenID Connect-Authentifizierungs-Handler zum Authentifizierungsschema hinzufügen.

Bevor wir fortfahren, gibt es zwei verwirrende Begriffe im .NET Core Authentifizierungs-Middleware, die wir klären müssen:

CallbackPath: Die URI, zu der Logto den Benutzer zurückleitet, nachdem der Benutzer sich angemeldet hat (die "Redirect-URI" in Logto)
RedirectUri: Die URI, zu der weitergeleitet wird, nachdem die notwendigen Aktionen im Logto Authentifizierungs-Middleware durchgeführt wurden.

Der Anmeldeprozess kann wie folgt veranschaulicht werden:

Ähnlich hat .NET Core auch SignedOutCallbackPath und RedirectUri für den Abmeldefluss.

Zur Klarheit werden wir sie wie folgt bezeichnen:

Begriff, den wir verwenden	.NET Core Begriff
Logto Redirect-URI	CallbackPath
Logto Post-Abmeldung Redirect-URI	SignedOutCallbackPath
Anwendungs-Redirect-URI	RedirectUri

Dieser Authentifizierungsprozess folgt dem OpenID Connect (OIDC) Protokoll, und Logto erzwingt strenge Sicherheitsmaßnahmen, um die Benutzeranmeldung zu schützen.
Wenn du mehrere Apps hast, kannst du denselben Identitätsanbieter (Logto) verwenden. Sobald sich der Benutzer bei einer App anmeldet, wird Logto den Anmeldeprozess automatisch abschließen, wenn der Benutzer auf eine andere App zugreift.

Um mehr über die Gründe und Vorteile der umleitungsbasierten Anmeldung zu erfahren, siehe Logto-Anmeldeerfahrung erklärt.

Umleitungs-URIs konfigurieren

hinweis:

In den folgenden Code-Snippets gehen wir davon aus, dass deine App unter http://localhost:3000/ läuft.

Zuerst konfigurieren wir die Logto-Umleitungs-URI. Füge die folgende URI zur Liste der "Umleitungs-URIs" auf der Logto-Anwendungsdetailseite hinzu:

http://localhost:3000/Callback

Um die Logto-Post-Sign-Out-Umleitungs-URI zu konfigurieren, füge die folgende URI zur Liste der "Post-Sign-Out-Umleitungs-URIs" auf der Logto-Anwendungsdetailseite hinzu:

http://localhost:3000/SignedOutCallback

Ändere die Standardpfade

Die Logto-Umleitungs-URI hat einen Standardpfad von /Callback, und die Logto-Post-Sign-Out-Umleitungs-URI hat einen Standardpfad von /SignedOutCallback.

Du kannst sie so belassen, wenn es keine besonderen Anforderungen gibt. Wenn du sie ändern möchtest, kannst du die Eigenschaften CallbackPath und SignedOutCallbackPath für LogtoOptions festlegen:

Program.cs
builder.Services.AddLogtoAuthentication(options =>
{
  // Andere Konfigurationen...
  options.CallbackPath = "/Foo";
  options.SignedOutCallbackPath = "/Bar";
});

Denke daran, den Wert auf der Logto-Anwendungsdetailseite entsprechend zu aktualisieren.

Routen hinzufügen

Da Blazor Server SignalR verwendet, um zwischen dem Server und dem Client zu kommunizieren, bedeutet dies, dass Methoden, die den HTTP-Kontext direkt manipulieren (wie das Auslösen von Herausforderungen oder Weiterleitungen), nicht wie erwartet funktionieren, wenn sie von einer Blazor-Komponente aufgerufen werden.

Um dies richtig zu machen, müssen wir explizit zwei Endpunkte für Anmelde- und Abmelde-Weiterleitungen hinzufügen:

Program.cs
app.MapGet("/SignIn", async context =>
{
    if (!(context.User?.Identity?.IsAuthenticated ?? false))
    {
        await context.ChallengeAsync(new AuthenticationProperties { RedirectUri = "/" });
    } else {
        context.Response.Redirect("/");
    }
});

app.MapGet("/SignOut", async context =>
{
    if (context.User?.Identity?.IsAuthenticated ?? false)
    {
        await context.SignOutAsync(new AuthenticationProperties { RedirectUri = "/" });
    } else {
        context.Response.Redirect("/");
    }
});

Jetzt können wir zu diesen Endpunkten weiterleiten, um Anmelde- und Abmeldevorgänge auszulösen.

Anmelde- / Abmelde-Buttons implementieren

Im Razor-Komponent fügen Sie den folgenden Code hinzu:

Components/Pages/Index.razor
@using Microsoft.AspNetCore.Components.Authorization
@using System.Security.Claims
@inject AuthenticationStateProvider AuthenticationStateProvider
@inject NavigationManager NavigationManager

@* ... *@

<p>Ist authentifiziert: @User.Identity?.IsAuthenticated</p>
@if (User.Identity?.IsAuthenticated == true)
{
    <button @onclick="SignOut">Abmelden</button>
}
else
{
    <button @onclick="SignIn">Anmelden</button>
}

@* ... *@

@code {
    private ClaimsPrincipal? User { get; set; }

    protected override async Task OnInitializedAsync()
    {
        var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
        User = authState.User;
    }

    private void SignIn()
    {
        NavigationManager.NavigateTo("/SignIn", forceLoad: true);
    }

    private void SignOut()
    {
        NavigationManager.NavigateTo("/SignOut", forceLoad: true);
    }
}

Erklärung:

Der injizierte AuthenticationStateProvider wird verwendet, um den Authentifizierungsstatus des aktuellen Benutzers abzurufen und die User-Eigenschaft zu füllen.
Die Methoden SignIn und SignOut werden verwendet, um den Benutzer zu den Anmelde- bzw. Abmeldeendpunkten weiterzuleiten. Aufgrund der Natur von Blazor Server müssen wir NavigationManager mit force load verwenden, um die Weiterleitung auszulösen.

Die Seite zeigt die Schaltfläche "Anmelden" an, wenn der Benutzer nicht authentifiziert ist, und die Schaltfläche "Abmelden", wenn der Benutzer authentifiziert ist.

Die `<AuthorizeView />`-Komponente

Alternativ kannst du das AuthorizeView-Komponente verwenden, um Inhalte basierend auf dem Authentifizierungsstatus des Benutzers bedingt anzuzeigen. Diese Komponente ist nützlich, wenn du unterschiedlichen Inhalt für authentifizierte und nicht authentifizierte Benutzer anzeigen möchtest.

Füge in deiner Razor-Komponente den folgenden Code hinzu:

Components/Pages/Index.razor
@using Microsoft.AspNetCore.Components.Authorization

@* ... *@

<AuthorizeView>
    <Authorized>
        <p>Name: @User?.Identity?.Name</p>
        @* Inhalt für authentifizierte Benutzer *@
    </Authorized>
    <NotAuthorized>
        @* Inhalt für nicht authentifizierte Benutzer *@
    </NotAuthorized>
</AuthorizeView>

@* ... *@

Die AuthorizeView-Komponente erfordert einen kaskadierenden Parameter vom Typ Task<AuthenticationState>. Eine direkte Möglichkeit, diesen Parameter zu erhalten, besteht darin, die <CascadingAuthenticationState>-Komponente hinzuzufügen. Aufgrund der Natur von Blazor Server können wir die Komponente jedoch nicht einfach zum Layout oder zur Root-Komponente hinzufügen (es könnte nicht wie erwartet funktionieren). Stattdessen können wir den folgenden Code zum Builder (Program.cs oder Startup.cs) hinzufügen, um den kaskadierenden Parameter bereitzustellen:

Program.cs
builder.Services.AddCascadingAuthenticationState();

Dann kannst du die AuthorizeView-Komponente in jeder Komponente verwenden, die sie benötigt.

Checkpoint: Teste deine Anwendung

Jetzt kannst du deine Anwendung testen:

Starte deine Anwendung, du wirst den Anmeldebutton sehen.
Klicke auf den Anmeldebutton, das SDK wird den Anmeldeprozess initiieren und dich zur Logto-Anmeldeseite weiterleiten.
Nachdem du dich angemeldet hast, wirst du zurück zu deiner Anwendung geleitet und siehst den Abmeldebutton.
Klicke auf den Abmeldebutton, um den Token-Speicher zu leeren und dich abzumelden.

OIDC Connector hinzufügen

Um eine schnelle Anmeldung zu ermöglichen und die Benutzerkonversion zu verbessern, verbinde dich mit .Net Core (Blazor Server) als Identitätsanbieter (IdP). Der Logto Social Connector hilft dir, diese Verbindung in wenigen Minuten herzustellen, indem er mehrere Parameter-Eingaben ermöglicht.

Um einen Social Connector hinzuzufügen, folge einfach diesen Schritten:

Navigiere zu Console > Connectors > Social Connectors.
Klicke auf "Add social connector" und wähle "OIDC".
Folge der README-Anleitung und fülle die erforderlichen Felder aus und passe die Einstellungen an.

hinweis:

Wenn du der In-Place Connector-Anleitung folgst, kannst du den nächsten Abschnitt überspringen.

Standard OIDC-App einrichten

Erstelle deine OIDC-App

Wenn du diese Seite öffnest, gehen wir davon aus, dass du bereits weißt, mit welchem sozialen Identitätsanbieter du dich verbinden möchtest. Das Erste, was du tun solltest, ist zu bestätigen, dass der Identitätsanbieter das OIDC-Protokoll unterstützt, da dies eine Voraussetzung für die Konfiguration eines gültigen Connectors ist. Folge dann den Anweisungen des Identitätsanbieters, um die relevante App für die OIDC-Autorisierung zu registrieren und zu erstellen.

Konfiguriere deinen Connector

Wir unterstützen aus Sicherheitsgründen NUR den "Authorization Code"-Grant-Typ, und er passt perfekt zu Logtos Szenario.

clientId und clientSecret findest du auf der Detailseite deiner OIDC-Apps.

clientId: Die Client-ID ist ein eindeutiger Identifikator, der die Client-Anwendung während der Registrierung beim Autorisierungsserver identifiziert. Diese ID wird vom Autorisierungsserver verwendet, um die Identität der Client-Anwendung zu überprüfen und um alle autorisierten Zugangstokens mit dieser spezifischen Client-Anwendung zu verknüpfen.

clientSecret: Das Client-Secret ist ein vertraulicher Schlüssel, der der Client-Anwendung vom Autorisierungsserver während der Registrierung ausgestellt wird. Die Client-Anwendung verwendet diesen geheimen Schlüssel, um sich beim Autorisierungsserver zu authentifizieren, wenn sie Zugangstokens anfordert. Das Client-Secret wird als vertrauliche Information betrachtet und sollte jederzeit sicher aufbewahrt werden.

tokenEndpointAuthMethod: Die Authentifizierungsmethode des Token-Endpunkts wird von der Client-Anwendung verwendet, um sich beim Autorisierungsserver zu authentifizieren, wenn Zugangstokens angefordert werden. Um unterstützte Methoden zu entdecken, konsultiere das Feld token_endpoint_auth_methods_supported, das am OpenID Connect Discovery-Endpunkt des OAuth 2.0-Dienstanbieters verfügbar ist, oder beziehe dich auf die relevante Dokumentation des OAuth 2.0-Dienstanbieters.

clientSecretJwtSigningAlgorithm (Optional): Nur erforderlich, wenn tokenEndpointAuthMethod client_secret_jwt ist. Der Client-Secret-JWT-Signaturalgorithmus wird von der Client-Anwendung verwendet, um das JWT zu signieren, das während der Token-Anfrage an den Autorisierungsserver gesendet wird.

scope: Der Scope-Parameter wird verwendet, um die Menge der Ressourcen und Berechtigungen anzugeben, auf die die Client-Anwendung zugreifen möchte. Der Scope-Parameter wird typischerweise als durch Leerzeichen getrennte Liste von Werten definiert, die spezifische Berechtigungen darstellen. Zum Beispiel könnte ein Scope-Wert von "read write" anzeigen, dass die Client-Anwendung Lese- und Schreibzugriff auf die Daten eines Benutzers anfordert.

Du solltest authorizationEndpoint, tokenEndpoint, jwksUri und issuer als Konfigurationsinformationen des OpenID Providers finden. Diese sollten in der Dokumentation des sozialen Anbieters verfügbar sein.

authenticationEndpoint: Dieser Endpunkt wird verwendet, um den Authentifizierungsprozess zu initiieren. Der Authentifizierungsprozess beinhaltet typischerweise, dass sich der Benutzer anmeldet und der Client-Anwendung die Berechtigung erteilt, auf seine Ressourcen zuzugreifen.

tokenEndpoint: Dieser Endpunkt wird von der Client-Anwendung verwendet, um ein ID-Token zu erhalten, das zum Zugriff auf die angeforderten Ressourcen verwendet werden kann. Die Client-Anwendung sendet typischerweise eine Anfrage an den Token-Endpunkt mit einem Grant-Typ und einem Autorisierungscode, um ein ID-Token zu erhalten.

jwksUri: Dies ist der URL-Endpunkt, an dem das JSON Web Key Set (JWKS) des sozialen Identitätsanbieters (kurz IdP) abgerufen werden kann. Das JWKS ist eine Sammlung kryptografischer Schlüssel, die der IdP verwendet, um JSON Web Tokens (JWTs) zu signieren und zu verifizieren, die während des Authentifizierungsprozesses ausgestellt werden. Die jwksUri wird von der vertrauenden Partei (RP) verwendet, um die öffentlichen Schlüssel zu erhalten, die vom IdP zum Signieren der JWTs verwendet werden, sodass die RP die Authentizität und Integrität der vom IdP empfangenen JWTs überprüfen kann.

issuer: Dies ist der eindeutige Identifikator des IdP, der von der RP verwendet wird, um die vom IdP empfangenen JWTs zu überprüfen. Er ist in den JWTs als iss Anspruch enthalten (ID-Token ist immer ein JWT). Der Ausstellerwert sollte mit der URL des Autorisierungsservers des IdP übereinstimmen und eine URI sein, der die RP vertraut. Wenn die RP ein JWT erhält, überprüft sie den iss-Anspruch, um sicherzustellen, dass es von einem vertrauenswürdigen IdP ausgestellt wurde und dass das JWT für die Verwendung mit der RP bestimmt ist.

Zusammen bieten jwksUri und issuer einen sicheren Mechanismus für die RP, um die Identität des Endbenutzers während des Authentifizierungsprozesses zu überprüfen. Durch die Verwendung der von der jwksUri erhaltenen öffentlichen Schlüssel kann die RP die Authentizität und Integrität der vom IdP ausgestellten JWTs überprüfen. Der Ausstellerwert stellt sicher, dass die RP nur JWTs akzeptiert, die von einem vertrauenswürdigen IdP ausgestellt wurden und dass die JWTs für die Verwendung mit der RP bestimmt sind.

Da eine Authentifizierungsanfrage immer erforderlich ist, wird ein authRequestOptionalConfig bereitgestellt, um alle optionalen Konfigurationen zu umschließen. Details findest du unter OIDC Authentication Request. Du wirst vielleicht auch feststellen, dass nonce in dieser Konfiguration fehlt. Da nonce für jede Anfrage identisch sein sollte, haben wir die Generierung von nonce in die Code-Implementierung aufgenommen. Also mach dir keine Sorgen darüber! Die zuvor erwähnten jwksUri und issuer sind ebenfalls in idTokenVerificationConfig enthalten.

Du fragst dich vielleicht, warum ein standardmäßiges OIDC-Protokoll sowohl die impliziten als auch die hybriden Flows unterstützt, während der Logto-Connector nur den Autorisierungs-Flow unterstützt. Es wurde festgestellt, dass die impliziten und hybriden Flows weniger sicher sind als der Autorisierungs-Flow. Aufgrund von Logtos Fokus auf Sicherheit unterstützt es nur den Autorisierungs-Flow für das höchste Sicherheitsniveau für seine Benutzer, trotz seiner etwas weniger bequemen Natur.

responseType und grantType können NUR feste Werte mit dem "Authorization Code"-Flow sein, daher machen wir sie optional und Standardwerte werden automatisch ausgefüllt.

hinweis:

Für alle Flow-Typen haben wir einen OPTIONALEN customConfig-Schlüssel bereitgestellt, um deine benutzerdefinierten Parameter einzufügen. Jeder soziale Identitätsanbieter könnte seine eigene Variante des OIDC-Standardprotokolls haben. Wenn dein gewünschter sozialer Identitätsanbieter strikt am OIDC-Standardprotokoll festhält, musst du dich nicht um customConfig kümmern.

Konfigurationstypen

Name	Typ	Erforderlich
scope	string	Ja
clientId	string	Ja
clientSecret	string	Ja
authorizationEndpoint	string	Ja
tokenEndpoint	string	Ja
idTokenVerificationConfig	IdTokenVerificationConfig	Ja
authRequestOptionalConfig	AuthRequestOptionalConfig	Nein
customConfig	Record<string, string>	Nein

AuthRequestOptionalConfig Eigenschaften	Typ	Erforderlich
responseType	string	Nein
tokenEndpoint	string	Nein
responseMode	string	Nein
display	string	Nein
prompt	string	Nein
maxAge	string	Nein
uiLocales	string	Nein
idTokenHint	string	Nein
loginHint	string	Nein
acrValues	string	Nein

IdTokenVerificationConfig Eigenschaften	Typ	Erforderlich
jwksUri	string	Ja
issuer	string \| string[]	Nein
audience	string \| string[]	Nein
algorithms	string[]	Nein
clockTolerance	string \| number	Nein
crit	Record<string, string \| boolean>	Nein
currentDate	Date	Nein
maxTokenAge	string \| number	Nein
subject	string	Nein
typ	string	Nein

Siehe hier, um mehr Details über IdTokenVerificationConfig zu finden.

Konfiguration speichern

Überprüfe, ob du alle notwendigen Werte im Logto Connector-Konfigurationsbereich ausgefüllt hast. Klicke auf "Speichern und Fertig" (oder "Änderungen speichern") und der OIDC Connector sollte jetzt verfügbar sein.

Sobald du einen sozialen Connector erfolgreich erstellt hast, kannst du ihn als "Weiter mit OIDC"-Button in der Anmeldeerfahrung aktivieren.

Navigiere zu Konsole > Anmeldeerfahrung > Registrierung und Anmeldung.
(Optional) Wähle "Nicht zutreffend" für das Registrierungskennzeichen, wenn du nur die soziale Anmeldung benötigst.
Füge den konfigurierten OIDC Connector zum Abschnitt "Soziale Anmeldung" hinzu.

Anmeldeerfahrungs-Tab

Testen und Validieren

Kehre zu deiner .NET Core (Blazor Server)-App zurück. Du solltest dich jetzt mit OIDC anmelden können. Viel Spaß!

Weiterführende Lektüre

Endbenutzerflüsse: Logto bietet sofort einsatzbereite Authentifizierungsflüsse, einschließlich Multi-Faktor-Authentifizierung (MFA) und Enterprise SSO, zusammen mit leistungsstarken APIs für die flexible Implementierung von Kontoeinstellungen, Sicherheitsüberprüfung und Multi-Tenant-Erfahrung.

Autorisierung: Autorisierung (Authorization) definiert die Aktionen, die ein Benutzer ausführen kann, oder die Ressourcen, auf die er nach der Authentifizierung zugreifen kann. Erfahre, wie du deine API für native und Single-Page-Anwendungen schützen und rollenbasierte Zugangskontrolle (RBAC) implementieren kannst.

Organisationen: Besonders effektiv in Multi-Tenant-SaaS- und B2B-Anwendungen, ermöglicht die Organisationsfunktion die Erstellung von Mandanten, das Mitgliedermanagement, organisationsweite RBAC und Just-in-Time-Bereitstellung.

Kunden-IAM-Serie: Unsere Blogserie über Customer (oder Consumer) Identity and Access Management, von den Grundlagen bis zu fortgeschrittenen Themen und darüber hinaus.

Eine Anwendung in Logto erstellen​

.Net Core (Blazor Server) SDK integrieren​

Installation​

Logto-Authentifizierung hinzufügen​

Anmelde- und Abmeldeflüsse​

Bezüglich der umleitungsbasierten Anmeldung​

Umleitungs-URIs konfigurieren​

Ändere die Standardpfade​

Routen hinzufügen​

Anmelde- / Abmelde-Buttons implementieren​

Die <AuthorizeView />-Komponente​

Checkpoint: Teste deine Anwendung​

OIDC Connector hinzufügen​

Standard OIDC-App einrichten​

Erstelle deine OIDC-App​

Konfiguriere deinen Connector​

Konfigurationstypen​

Konfiguration speichern​

OIDC Connector in der Anmeldeerfahrung aktivieren​

Testen und Validieren​

Weiterführende Lektüre​

Eine Anwendung in Logto erstellen

.Net Core (Blazor Server) SDK integrieren

Installation

Logto-Authentifizierung hinzufügen

Anmelde- und Abmeldeflüsse

Bezüglich der umleitungsbasierten Anmeldung

Umleitungs-URIs konfigurieren

Ändere die Standardpfade

Routen hinzufügen

Anmelde- / Abmelde-Buttons implementieren

Die `<AuthorizeView />`-Komponente

Checkpoint: Teste deine Anwendung

OIDC Connector hinzufügen

Standard OIDC-App einrichten

Erstelle deine OIDC-App

Konfiguriere deinen Connector

Konfigurationstypen

Konfiguration speichern

OIDC Connector in der Anmeldeerfahrung aktivieren

Testen und Validieren

Weiterführende Lektüre