Verwenden von Identity zum Schützen eines Web-API-Back-Ends für SPAs

ASP.NET Core Identity stellt APIs für die Authentifizierung, Autorisierung und Verwaltung der identity bereit. Die APIs ermöglichen es, Endpunkte eines Web-API-Back-Ends mit cookie-basierter Authentifizierung zu schützen. Eine tokenbasierte Option ist für Clients verfügbar, die keine Cookies verwenden können, doch wenn Sie diese verwenden, sind Sie dafür verantwortlich, sicherzustellen, dass die Token sicher bleiben. Es wird empfohlen, s für browserbasierte Anwendungen zu verwenden, da der Browser sie standardmäßig automatisch verarbeitet, ohne sie JavaScript verfügbar zu machen.

In diesem Artikel erfahren Sie, wie Sie Identity verwenden, um ein Web-API-Back-End für SPAs wie Angular-, React- und Vue-Apps zu schützen. Die gleichen Back-End-APIs können zum Schützen von Blazor WebAssembly-Apps verwendet werden.

Voraussetzungen

Die in diesem Artikel gezeigten Schritte fügen einer ASP.NET Core-Web-API-App Authentifizierungs- und Autorisierungsfunktionen hinzu, für die Folgendes gilt:

• noch nicht für die Authentifizierung konfiguriert ist
• Sie ist auf net8.0 oder höhere Versionen ausgerichtet.
• Sie kann eine minimale API oder eine controllerbasierte API sein.

Einige der Testanweisungen in diesem Artikel verwenden die Swagger-Benutzeroberfläche, die in der Projektvorlage enthalten ist. Die Swagger-Benutzeroberfläche ist nicht erforderlich, um Identity mit einem Web-API-Back-End zu verwenden.

Installieren von NuGet-Paketen

Installieren Sie die folgenden NuGet-Pakete:

• Microsoft.AspNetCore.Identity.EntityFrameworkCore: Ermöglicht es Identity, mit Entity Framework Core (EF Core) zu arbeiten.
• Ein Paket, das es EF Core ermöglicht, mit einer Datenbank zu arbeiten – beispielsweise eines der folgenden Pakete:
  • Microsoft.EntityFrameworkCore.SqlServer oder
  • Microsoft.EntityFrameworkCore.Sqlite oder
  • Microsoft.EntityFrameworkCore.InMemory.

Verwenden Sie für den schnellstmöglichen Einstieg die In-Memory-Datenbank.

Ändern Sie die Datenbank später in SQLite oder SQL Server, um Benutzerdaten beim Testen oder für die Produktionsverwendung sitzungsübergreifend zu speichern. Dies führt zu einem gewissen Maß an Komplexität im Vergleich zum In-Memory-Modell, da die Datenbank über Migrationen erstellt werden muss, wie im Tutorial Erste Schritte mit EF Core gezeigt.

Installieren Sie diese Pakete über den NuGet-Paket-Manager in Visual Studio oder mithilfe des CLI-Befehls dotnet add package.

Erstellen Sie einen IdentityDbContext.

Fügen Sie eine Klasse namens ApplicationDbContext hinzu, die von IdentityDbContext<TUser> erbt:

using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : IdentityDbContext<IdentityUser>
{
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) :
        base(options)
    { }
}

Der gezeigte Code enthält einen speziellen Konstruktor, mit dem die Datenbank für verschiedene Umgebungen konfiguriert werden kann.

Fügen Sie bei Bedarf eine oder mehrere der folgenden using-Direktiven hinzu, wenn Sie den in diesen Schritten gezeigten Code hinzufügen.

using Microsoft.AspNetCore.Identity;
using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore;

Konfigurieren des EF Core-Kontexts

Wie bereits erwähnt, ist es am einfachsten, zunächst die In-Memory-Datenbank zu verwenden. Beim In-Memory-Modell beginnt jede Ausführung mit einer neuen Datenbank, und es müssen keine Migrationen verwendet werden. Fügen Sie nach dem Aufruf von WebApplication.CreateBuilder(args) den folgenden Code hinzu, um Identity für die Verwendung einer In-Memory-Datenbank zu konfigurieren:

builder.Services.AddDbContext<ApplicationDbContext>(
    options => options.UseInMemoryDatabase("AppDb"));

Ändern Sie die Datenbank später in SQLite oder SQL Server, um Benutzerdaten beim Testen oder für die Verwendung in der Produktion sitzungsübergreifend zu speichern.

Hinzufügen von Identity-Diensten zum Container

Nach dem Aufruf von WebApplication.CreateBuilder(args) muss AddAuthorization aufgerufen werden, um dem DI-Container (Dependency Injection) Dienste hinzuzufügen:

builder.Services.AddAuthorization();

Aktivieren von Identity-APIs

Nach dem Aufruf von WebApplication.CreateBuilder(args) müssen AddIdentityApiEndpoints<TUser>(IServiceCollection) und AddEntityFrameworkStores<TContext>(IdentityBuilder) aufgerufen werden.

builder.Services.AddIdentityApiEndpoints<IdentityUser>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

Standardmäßig werden sowohl Cookies als auch proprietäre Token aktiviert. Cookies und Token werden bei der Anmeldung ausgegeben, wenn der Abfragezeichenfolgenparameter useCookies am Anmeldeendpunkt true lautet.

Zuordnen von Identity-Routen

Nach dem Aufruf von builder.Build() muss MapIdentityApi<TUser>(IEndpointRouteBuilder) aufgerufen werden, um die Identity-Endpunkte zuzuordnen:

app.MapIdentityApi<IdentityUser>();

Sichere ausgewählte Endpunkte

Verwenden Sie zum Schützen eines Endpunkts die RequireAuthorization-Erweiterungsmethode für den Map{Method}-Aufruf, der die Route definiert. Beispiel:

app.MapGet("/weatherforecast", (HttpContext httpContext) =>
{
    var forecast = Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = summaries[Random.Shared.Next(summaries.Length)]
        })
        .ToArray();
    return forecast;
})
.WithName("GetWeatherForecast")
.WithOpenApi()
.RequireAuthorization();

Die RequireAuthorization-Methode kann auch für Folgendes verwendet werden:

• Schützen von Swagger-Benutzeroberflächenendpunkten, wie im folgenden Beispiel gezeigt:

  app.MapSwagger().RequireAuthorization();
  

• Schützen mit einem bestimmten Anspruch oder einer bestimmten Berechtigung, wie im folgenden Beispiel gezeigt:

  .RequireAuthorization("Admin");
  

Schützen Sie die Endpunkte in einem controllerbasierten Web-API-Projekt, indem Sie das Attribut [Authorize] auf einen Controller oder eine Aktion anwenden.

Testen der API

Eine schnelle Möglichkeit zum Testen der Authentifizierung besteht darin, die In-Memory-Datenbank und die Swagger-Benutzeroberfläche zu verwenden, die in der Projektvorlage enthalten ist. Die folgenden Schritte zeigen, wie Sie die API mit der Swagger-Benutzeroberfläche testen. Vergewissern Sie sich, dass die Endpunkte der Swagger-Benutzeroberfläche nicht geschützt sind.

Versuchen, auf einen geschützten Endpunkt zuzugreifen

• Führen Sie die App aus, und navigieren Sie zur Swagger-Benutzeroberfläche.
• Erweitern Sie einen geschützten Endpunkt (z. B. /weatherforecast) in einem Projekt, das von der Web-API-Vorlage erstellt wurde.
• Wählen Sie Ausprobieren aus.
• Wählen Sie Execute(Ausführen). Die Antwort lautet: 401 - not authorized.

Testen der Registrierung

• Erweitern Sie /register, und wählen Sie Ausprobieren aus.

• Im Abschnitt Parameter der Benutzeroberfläche wird ein exemplarischer Anforderungstext angezeigt:

  {
    "email": "string",
    "password": "string"
  }
  

• Ersetzen Sie „string“ durch eine gültige E-Mail-Adresse und ein gültiges Kennwort, und wählen Sie dann Ausführen aus.

  Um den Standardregeln für Kennwörter zu entsprechen, muss das Kennwort mindestens sechs Zeichen lang sein und mindestens eins der folgenden Zeichen enthalten:

  • Großbuchstabe
  • Kleinbuchstabe
  • Numerische Ziffer
  • Nicht alphanumerisches Zeichen

  Wenn Sie eine ungültige E-Mail-Adresse oder ein ungültiges Kennwort eingeben, enthält das Ergebnis die Überprüfungsfehler. Hier sehen Sie ein Beispiel für einen Antworttext mit Überprüfungsfehlern:

  {
    "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "errors": {
      "PasswordTooShort": [
        "Passwords must be at least 6 characters."
      ],
      "PasswordRequiresNonAlphanumeric": [
        "Passwords must have at least one non alphanumeric character."
      ],
      "PasswordRequiresDigit": [
        "Passwords must have at least one digit ('0'-'9')."
      ],
      "PasswordRequiresLower": [
        "Passwords must have at least one lowercase ('a'-'z')."
      ]
    }
  }
  

  Die Fehler werden im Format ProblemDetails zurückgegeben, sodass der Client sie analysieren und bei Bedarf Validierungsfehler anzeigen kann.

  Eine erfolgreiche Registrierung führt zu einer Antwort vom Typ 200 - OK.

Testen der Anmeldung

• Erweitern Sie /login, und wählen Sie Ausprobieren aus. Der exemplarische Anforderungstext enthält zwei zusätzliche Parameter:

  {
    "email": "string",
    "password": "string",
    "twoFactorCode": "string",
    "twoFactorRecoveryCode": "string"
  }
  

  Die zusätzlichen JSON-Eigenschaften werden für dieses Beispiel nicht benötigt und können gelöscht werden. Setzen Sie useCookies auf true.

• Ersetzen Sie „string“ durch die E-Mail-Adresse und das Kennwort, die Sie bei der Registrierung verwendet haben, und wählen Sie anschließend Ausführen aus.

  Eine erfolgreiche Anmeldung führt zu einer Antwort vom Typ 200 - OK mit einem cookie im Antwortheader.

Erneutes Testen des geschützten Endpunkts

Führen Sie nach einer erfolgreichen Anmeldung erneut den geschützten Endpunkt aus. Das cookie für die Authentifizierung wird automatisch zusammen mit der Anforderung gesendet, und der Endpunkt wird autorisiert. Die Cookie-basierte Authentifizierung ist sicher in den Browser integriert und funktioniert reibungslos.

Testen mit browserfremden Clients

Einige Webclients enthalten möglicherweise standardmäßig keine Cookies im Header:

• Wenn Sie ein Tool zum Testen von APIs verwenden, müssen Cookies möglicherweise in den Einstellungen aktiviert werden.

• Die JavaScript fetch-API enthält standardmäßig keine Cookies. Aktivieren Sie sie, indem Sie credentials in den Optionen auf den Wert include festlegen.

• Bei einer in einer Blazor WebAssembly-App ausgeführten HttpClient-Instanz muss HttpRequestMessage Anmeldeinformationen enthalten. Beispiel:

  request.SetBrowserRequestCredential(BrowserRequestCredentials.Include);
  

Verwenden der tokenbasierten Authentifizierung

Es wird empfohlen, Cookies für browserbasierte Anwendungen zu verwenden da der Browser sie standardmäßig automatisch verarbeitet, ohne sie JavaScript verfügbar zu machen.

Ein benutzerdefiniertes Token (also ein proprietäres Token der ASP.NET Core-identity-Plattform) wird ausgegeben und kann zum Authentifizieren nachfolgender Anforderungen verwendet werden. Das Token wird im Authorization-Header als Bearertoken übergeben. Außerdem wird ein Aktualisierungstoken bereitgestellt. Mit diesem Token kann die Anwendung ein neues Token anfordern, wenn das alte abläuft, ohne dass sich die Benutzer*innen erneut anmelden müssen.

Die Token sind standardmäßig keine JSON-Webtoken (JWTs). Die Verwendung benutzerdefinierter Token ist beabsichtigt, da die integrierte Identity-API in erster Linie für einfache Szenarien vorgesehen ist. Die Tokenoption ist nicht als vollständiger Identitätsdienstanbieter oder Tokenserver gedacht, sondern als Alternative zur Cookie-Option für Clients, die keine Cookies verwenden können.

Um die tokenbasierte Authentifizierung zu verwenden, legen Sie den useCookies-Abfragezeichenfolgenparameter beim Aufrufen des /login-Endpunkts auf false fest. Token verwenden das Bearerauthentifizierungsschema. Wenn Sie das vom Aufruf von /loginzurückgegebene Token verwenden, sollten nachfolgende Aufrufe von geschützten Endpunkten den Header Authorization: Bearer <token> hinzufügen, wobei <token> das Zugriffstoken ist. Weitere Informationen finden Sie unter Verwenden des POST /login-Endpunkts weiter unten in diesem Artikel.

Abmelden

Um Benutzer*innen eine Möglichkeit zum Abmelden bereitzustellen, definieren Sie einen /logout-Endpunkt wie im folgenden Beispiel:

app.MapPost("/logout", async (SignInManager<IdentityUser> signInManager,
    [FromBody] object empty) =>
{
    if (empty != null)
    {
        await signInManager.SignOutAsync();
        return Results.Ok();
    }
    return Results.Unauthorized();
})
.WithOpenApi()
.RequireAuthorization();

Stellen Sie beim Aufrufen dieses Endpunkts ein leeres JSON-Objekt ({}) im Anforderungstext bereit. Der folgende Code ist ein Beispiel für einen Aufruf des Abmeldeendpunkts:

public signOut() {
  return this.http.post('/logout', {}, {
    withCredentials: true,
    observe: 'response',
    responseType: 'text'

Die MapIdentityApi<TUser>-Endpunkte

Der Aufruf von MapIdentityApi<TUser> fügt der App die folgenden Endpunkte hinzu:

• POST /register
• POST /login
• POST /refresh
• GET /confirmEmail
• POST /resendConfirmationEmail
• POST /forgotPassword
• POST /resetPassword
• POST /manage/2fa
• GET /manage/info
• POST /manage/info

Verwenden des POST /register-Endpunkts

Der Anforderungstext muss über Email- und Password-Eigenschaften verfügen:

{
  "email": "string",
  "password": "string",
}

Weitere Informationen finden Sie unter:

• Testen der Registrierung weiter oben in diesem Artikel
• RegisterRequest.

Verwenden des POST /login-Endpunkts

Im Anforderungstext sind Email und Password erforderlich. Wenn die Zwei-Faktor-Authentifizierung (2FA) aktiviert ist, ist entweder TwoFactorCode oder TwoFactorRecoveryCode erforderlich. Wenn 2FA nicht aktiviert ist, lassen Sie sowohl twoFactorCode als auch twoFactorRecoveryCode weg. Weitere Informationen finden Sie unter Verwenden des POST /manage/2fa-Endpunkts weiter unten in diesem Artikel.

Hier ist ein Anforderungstextbeispiel mit nicht aktivierter 2FA:

{
  "email": "string",
  "password": "string"
}

Hier sind Anforderungstextbeispiele mit aktivierter 2FA:

• {
    "email": "string",
    "password": "string",
    "twoFactorCode": "string",
  }
  

• {
    "email": "string",
    "password": "string",
    "twoFactorRecoveryCode": "string"
  }
  

Der Endpunkt erwartet einen Abfragezeichenfolgenparameter:

• useCookies: Für die cookie-basierte Authentifizierung auf true festgelegt. Legen Sie diesen Wert auf false fest, oder lassen Sie ihn für die tokenbasierte Authentifizierung weg.

Weitere Informationen zur cookie-basierten Authentifizierung finden Sie unter Testen der Anmeldung weiter oben in diesem Artikel.

Tokenbasierte Authentifizierung

Wenn useCookies gleich false ist oder weggelassen wird, wird die tokenbasierte Authentifizierung aktiviert. Der Antworttext enthält die folgenden Eigenschaften:

{
  "tokenType": "string",
  "accessToken": "string",
  "expiresIn": 0,
  "refreshToken": "string"
}

Weitere Informationen zu diesen Eigenschaften finden Sie unter AccessTokenResponse.

Fügen Sie das Zugriffstoken in einen Header ein, um authentifizierte Anforderungen vorzunehmen, wie im folgenden Beispiel gezeigt.

Authorization: Bearer {access token}

Wenn das Zugriffstoken bald abläuft, rufen Sie den /refresh-Endpunkt auf.

Verwenden des POST /refresh-Endpunkts

Dieser ist nur zur Verwendung mit tokenbasierter Authentifizierung vorgesehen. Er ruft ein neues Zugriffstoken ab, ohne dass Benutzer*innen gezwungen werden, sich erneut anzumelden. Rufen Sie diesen Endpunkt auf, wenn das Zugriffstoken bald abläuft.

Der Anforderungstext enthält nur RefreshToken. Hier ist ein Anforderungstextbeispiel:

{
  "refreshToken": "string"
}

Wenn der Aufruf erfolgreich ist, ist der Antworttext eine neue AccessTokenResponse, wie im folgenden Beispiel gezeigt:

{
  "tokenType": "string",
  "accessToken": "string",
  "expiresIn": 0,
  "refreshToken": "string"
}

Verwenden des GET /confirmEmail-Endpunkts

Wenn Identity für die E-Mail-Bestätigung eingerichtet ist, sendet ein erfolgreicher Aufruf des /register-Endpunkts eine E-Mail, die einen Link zum /confirmEmail-Endpunkt enthält. Der Link enthält die folgenden Abfragezeichenfolgenparameter:

• userId
• code
• changedEmail: nur enthalten, wenn der oder die Benutzer*in die E-Mail-Adresse während der Registrierung geändert hat

Identity stellt Standardtext für die Bestätigungs-E-Mail bereit. Standardmäßig lautet der E-Mail-Betreff „Bestätigen Sie Ihre E-Mail-Adresse“, und der E-Mail-Textkörper sieht wie im folgenden Beispiel aus:

 Please confirm your account by <a href='https://contoso.com/confirmEmail?userId={user ID}&code={generated code}&changedEmail={new email address}'>clicking here</a>.

Wenn die RequireConfirmedEmail-Eigenschaft auf true festgelegt ist, können sich Benutzer*innen erst anmelden, wenn die E-Mail-Adresse durch Klicken auf den Link in der E-Mail bestätigt wird. Der /confirmEmail-Endpunkt:

• bestätigt die E-Mail-Adresse und ermöglicht es dem oder der Benutzer*in, sich anzumelden
• gibt den Text „Vielen Dank für die Bestätigung Ihrer E-Mail-Adresse“ im Antworttext zurück

Um Identity für die E-Mail-Bestätigung einzurichten, fügen Sie Code in Program.cs hinzu, um RequireConfirmedEmail auf true festzulegen, und fügen Sie eine Klasse hinzu, die IEmailSender im DI-Container implementiert. Zum Beispiel:

builder.Services.Configure<IdentityOptions>(options =>
{
    options.SignIn.RequireConfirmedEmail = true;
});

builder.Services.AddTransient<IEmailSender, EmailSender>();

Weitere Informationen finden Sie unter Kontobestätigung und Kennwortwiederherstellung in ASP.NET Core.

Identity stellt Standardtext für die anderen E-Mails bereit, die ebenfalls gesendet werden müssen, z. B. für die 2FA- und Kennwortzurücksetzung. Um diese E-Mails anzupassen, stellen Sie eine benutzerdefinierte Implementierung der IEmailSender Schnittstelle bereit. Im vorherigen Beispiel ist EmailSender eine Klasse, die IEmailSender implementiert. Weitere Informationen, einschließlich eines Beispiels für eine Klasse, die IEmailSender implementiert, finden Sie unter Kontobestätigung und Kennwortwiederherstellung in ASP.NET Core.

Verwenden des POST /resendConfirmationEmail-Endpunkts

Dieser sendet nur eine E-Mail, wenn die Adresse für eine*n registrierte*n Benutzer*in gültig ist.

Der Anforderungstext enthält nur Email. Hier ist ein Anforderungstextbeispiel:

{
  "email": "string"
}

Weitere Informationen finden Sie unter Verwenden des GET /confirmEmail-Endpunkts weiter oben in diesem Artikel.

Verwenden des POST /forgotPassword-Endpunkts

Dieser generiert eine E-Mail, die einen Kennwortzurücksetzungscode enthält. Senden Sie diesen Code mit einem neuen Kennwort an /resetPassword.

Der Anforderungstext enthält nur Email. Ein Beispiel:

{
  "email": "string"
}

Informationen zum Aktivieren von Identity zum Senden von E-Mails finden Sie unter Verwenden des GET /confirmEmail-Endpunkts.

Verwenden des POST /resetPassword-Endpunkts

Rufen Sie diesen Endpunkt nach dem Abruf eines Zurücksetzungscodes auf, indem Sie den /forgotPassword-Endpunkt aufrufen.

Der Anforderungstext erfordert Email, ResetCode und NewPassword. Ein Beispiel:

{
  "email": "string",
  "resetCode": "string",
  "newPassword": "string"
}

Verwenden des POST /manage/2fa-Endpunkts

Dieser konfiguriert die Zwei-Faktor-Authentifizierung (2FA) für den oder die Benutzer*in. Wenn die 2FA aktiviert ist, ist für die erfolgreiche Anmeldung zusätzlich zur E-Mail-Adresse und dem Kennwort ein Code erforderlich, der von einer Authentifikator-App generiert wird.

2FA aktivieren

So aktivieren Sie die 2FA für den oder die aktuelle*n Benutzer*in:

• Rufen Sie den /manage/2fa-Endpunkt auf, und senden Sie ein leeres ON-Objekt ({}) im Anforderungstext.

• Der Antworttext stellt SharedKey zusammen mit einigen anderen Eigenschaften bereit, die zu diesem Zeitpunkt nicht benötigt werden. Der freigegebene Schlüssel wird zum Einrichten der Authentifikator-App verwendet. Beispiel für einen Antworttext:

  {
    "sharedKey": "string",
    "recoveryCodesLeft": 0,
    "recoveryCodes": null,
    "isTwoFactorEnabled": false,
    "isMachineRemembered": false
  }
  

• Verwenden Sie den freigegebenen Schlüssel, um ein zeitbasiertes Einmalkennwort (TOTP) abzurufen. Weitere Informationen finden Sie unter Aktivieren der QR-Code-Generierung für TOTP-Authentifikator-Apps in ASP.NET Core.

• Rufen Sie den /manage/2fa-Endpunkt auf, und senden Sie das TOTP und "enable": true im Anforderungstext. Beispiel:

  {
    "enable": true,
    "twoFactorCode": "string"
  }
  

• Der Antworttext bestätigt, dass IsTwoFactorEnabled zutrifft und RecoveryCodesbereitstellt. Die Wiederherstellungscodes werden für die Anmeldung verwendet, wenn die Authentifikator-App nicht verfügbar ist. Beispiel für den Antworttext nach erfolgreicher Aktivierung der 2FA:

  {
    "sharedKey": "string",
    "recoveryCodesLeft": 10,
    "recoveryCodes": [
      "string",
      "string",
      "string",
      "string",
      "string",
      "string",
      "string",
      "string",
      "string",
      "string"
    ],
    "isTwoFactorEnabled": true,
    "isMachineRemembered": false
  }
  

Anmelden mit 2FA

Rufen Sie den /login-Endpunkt auf, und übermitteln Sie die E-Mail-Adresse, das Kennwort und das TOTP im Anforderungstext. Beispiel:

{
  "email": "string",
  "password": "string",
  "twoFactorCode": "string"
}

Wenn der oder die Benutzer*in keinen Zugriff auf die Authentifikator-App hat, kann die Anmeldung erfolgen, indem der /login-Endpunkt mit einem der Wiederherstellungscodes aufgerufen wird, die bei der Aktivierung der 2FA bereitgestellt wurden. Der Anforderungstext sieht wie das folgende Beispiel aus:

{
  "email": "string",
  "password": "string",
  "twoFactorRecoveryCode": "string"
}

Zurücksetzen der Wiederherstellungscodes

Rufen Sie diesen Endpunkt auf, um neue Wiederherstellungscodes zu erhalten, wobei ResetRecoveryCodes auf true festgelegt sein muss. Hier ist ein Anforderungstextbeispiel:

{
  "resetRecoveryCodes": true
}

Zurücksetzen des freigegebenen Schlüssels

Um einen neuen zufälligen freigegebenen Schlüssel abzurufen, rufen Sie diesen Endpunkt auf, wobei ResetSharedKey auf true festgelegt sein muss. Hier ist ein Anforderungstextbeispiel:

{
  "resetSharedKey": true
}

Durch das Zurücksetzen des Schlüssels wird die erforderliche Zwei-Faktor-Authentifizierung für den oder die authentifierende*n Benutzer*in automatisch deaktiviert, bis sie durch eine nachfolgende Anforderung reaktiviert wird.

Vergessen des Computers

Rufen Sie diesen Endpunkt auf, wobei ForgetMachine auf „true“ festgelegt sein muss, um das cookie-Flag „Anmeldedaten speichern“ zu löschen, falls vorhanden. Hier ist ein Anforderungstextbeispiel:

{
  "forgetMachine": true
}

Dieser Endpunkt hat keine Auswirkungen auf die tokenbasierte Authentifizierung.

Verwenden des GET /manage/info-Endpunkts

Dieser ruft die E-Mail-Adresse und den E-Mail-Bestätigungsstatus des oder der angemeldeten Benutzer*in ab. Ansprüche wurden aus Sicherheitsgründen bei diesem Endpunkt weggelassen. Wenn Ansprüche erforderlich sind, verwenden Sie die serverseitigen APIs, um einen Endpunkt für Ansprüche einzurichten. Statt alle Ansprüche der Benutzer*innen freizugeben, können Sie alternativ einen Überprüfungsendpunkt bereitstellen, der einen Anspruch akzeptiert, und antwortet, ob der oder die Benutzer*in über diesen verfügt.

Für die Anforderung sind keine Parameter erforderlich. Der Antworttext enthält die Eigenschaften Email und IsEmailConfirmed, wie im folgenden Beispiel gezeigt:

{
  "email": "string",
  "isEmailConfirmed": true
}

Verwenden des POST /manage/info-Endpunkts

Dieser aktualisiert die E-Mail-Adresse und das Kennwort des oder der angemeldeten Benutzer*in. Übermitteln Sie NewEmail, NewPassword und OldPassword im Anforderungstext, wie im folgenden Beispiel gezeigt:

{
  "newEmail": "string",
  "newPassword": "string",
  "oldPassword": "string"
}

Es folgt ein Beispiel für den Antworttext:

{
  "email": "string",
  "isEmailConfirmed": false
}

Siehe auch

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Auswählen einer identity Verwaltungslösung
• Identity-Verwaltungslösungen für .NET-Web-Apps
• Einfache Autorisierung in ASP.NET Core
• Hinzufügen, Herunterladen und Löschen von Identity-Benutzerdaten in einem ASP.NET Core-Projekt
• Erstellen einer ASP.NET Core-App mit Benutzerdaten, die durch Autorisierung geschützt sind
• Account confirmation and password recovery in ASP.NET Core (Kontobestätigung und Kennwortwiederherstellung in ASP.NET Core)
• Enable QR Code generation for authenticator apps in ASP.NET Core (Aktivieren der QR-Code-Generierung für TOTP-Authentifikator-Apps in ASP.NET Core)
• Exemplarisches Web-API-Back-End für SPAs Die HTTP-Datei zeigt die tokenbasierte Authentifizierung. Beispiel:
  • useCookies wird nicht festgelegt.
  • Das Token wird mithilfe des Autorisierungsheaders übergeben.
  • Zeigt die Verlängerung der Sitzung mittels Aktualisierung, ohne eine erneute Benutzeranmeldung zu erzwingen.
• Exemplarische Angular-App, die Identity verwendet, um ein Web-API-Back-End zu schützen