Jak użyć Identity do zabezpieczenia zaplecza internetowego interfejsu API dla SPA

ASP.NET Core Identity udostępnia interfejsy API obsługujące uwierzytelnianie, autoryzację i zarządzanie tożsamościami. Interfejsy API umożliwiają zabezpieczanie punktów końcowych zaplecza interfejsu internetowego API przy użyciu uwierzytelniania opartego na cookie. Opcja oparta na tokenach jest dostępna dla klientów, którzy nie mogą używać plików cookie, ale w tym celu ponosisz odpowiedzialność za zapewnienie bezpieczeństwa tokenów. Zalecamy używanie plików cookie dla aplikacji opartych na przeglądarce, ponieważ domyślnie przeglądarka automatycznie obsługuje je bez uwidaczniania ich w języku JavaScript.

W tym artykule pokazano, jak używać Identity do zabezpieczania zaplecza internetowego interfejsu API dla aplikacji typu SPA, takich jak Angular, React i Vue. Te same interfejsy API zaplecza mogą służyć do zabezpieczania Blazor WebAssembly aplikacji.

Wymagania wstępne

W tym artykule przedstawiono kroki, które umożliwiają dodanie uwierzytelniania i autoryzacji dla aplikacji ASP.NET Core Web API, która:

• Nie jest jeszcze skonfigurowany do uwierzytelniania.
• Obiekty docelowe net8.0 lub nowsze.
• Może to być API minimalne lub oparte na kontrolerze.

Niektóre instrukcje testowe w tym artykule korzystają z Swagger UI zawartego w szablonie projektu. Nie jest wymagany interfejs użytkownika Swagger do użycia Identity z backendem Web API.

Instalowanie pakietów NuGet

Zainstaluj następujące pakiety NuGet:

• Microsoft.AspNetCore.Identity.EntityFrameworkCore — Umożliwia Identity pracę z programem Entity Framework Core (EF Core).
• Taki, który umożliwia EF Core pracę z bazą danych, taką jak jeden z następujących pakietów:
  • Microsoft.EntityFrameworkCore.SqlServer lub
  • Microsoft.EntityFrameworkCore.Sqlite lub
  • Microsoft.EntityFrameworkCore.InMemory.

Aby uzyskać najszybszy sposób rozpoczęcia pracy, użyj bazy danych w pamięci.

Zmień bazę danych później na SQLite lub SQL Server, aby zapisać dane użytkownika między sesjami podczas testowania lub użycia produkcyjnego. Wprowadza to pewną złożoność w porównaniu z pamięcią w RAM, ponieważ wymaga utworzenia bazy danych za pośrednictwem migracji, jak pokazano w samouczku EF Core dla początkujących.

Zainstaluj te pakiety przy użyciu menedżera pakietów NuGet w programie Visual Studio lub polecenia dotnet add package CLI.

Utwórz IdentityDbContext

Dodaj klasę o nazwie ApplicationDbContext , która dziedziczy z klasy IdentityDbContext<TUser>:

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

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

Pokazany kod udostępnia specjalny konstruktor, który umożliwia skonfigurowanie bazy danych dla różnych środowisk.

Dodaj jedną lub więcej z poniższych dyrektyw using zgodnie z potrzebami podczas dodawania kodu pokazanego w poniższych krokach.

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

Skonfiguruj EF Core kontekst

Jak wspomniano wcześniej, najprostszym sposobem rozpoczęcia pracy jest użycie bazy danych w pamięci. W przypadku uruchamiania w pamięci każde uruchomienie rozpoczyna się od nowej bazy danych i nie ma potrzeby używania migracji. Po wywołaniu metody WebApplication.CreateBuilder(args), dodaj następujący kod, aby skonfigurować Identity do używania bazy danych w pamięci:

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

Aby zapisać dane użytkownika między sesjami podczas testowania lub użycia produkcyjnego, zmień bazę danych później na SQLite lub SQL Server.

Dodawanie Identity usług do kontenera

Po wywołaniu WebApplication.CreateBuilder(args) wywołaj AddAuthorization, aby dodać usługi do kontenera wstrzykiwania zależności (DI).

builder.Services.AddAuthorization();

Aktywuj Identity interfejsy API

Po wywołaniu WebApplication.CreateBuilder(args), wywołaj AddIdentityApiEndpoints<TUser>(IServiceCollection) i AddEntityFrameworkStores<TContext>(IdentityBuilder).

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

Domyślnie zarówno pliki cookie, jak i zastrzeżone tokeny są aktywowane. Jeśli w punkcie końcowym logowania parametr ciągu zapytania useCookies jest true, pliki cookie i tokeny są wystawiane podczas logowania.

Mapuj Identity trasy

Po wywołaniu builder.Build(), wywołaj MapIdentityApi<TUser>(IEndpointRouteBuilder), aby zmapować punkty końcowe Identity.

app.MapIdentityApi<IdentityUser>();

Zabezpieczanie wybranych punktów końcowych

Aby zabezpieczyć punkt końcowy, użyj RequireAuthorization metody rozszerzenia w wywołaniu Map{Method} definiującym trasę. Na przykład:

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();

Metody RequireAuthorization można również użyć do:

• Zabezpieczanie endpointów interfejsu użytkownika Swagger, jak pokazano w poniższym przykładzie:

  app.MapSwagger().RequireAuthorization();
  

• Zabezpiecz się przy użyciu określonego oświadczenia lub uprawnienia, jak pokazano w poniższym przykładzie:

  .RequireAuthorization("Admin");
  

W projekcie internetowego interfejsu API opartego na kontrolerze zabezpiecz punkty końcowe, stosując atrybut [Authorize] do kontrolera lub akcji.

Testowanie interfejsu API

Szybkim sposobem testowania uwierzytelniania jest użycie bazy danych w pamięci i interfejsu użytkownika programu Swagger dołączonego do szablonu projektu. W poniższych krokach pokazano, jak przetestować API za pomocą Swagger UI. Upewnij się, że punkty końcowe Swagger UI nie są zabezpieczone.

Próba uzyskania dostępu do zabezpieczonego punktu końcowego

• Uruchom aplikację i przejdź do interfejsu użytkownika programu Swagger.
• Rozwiń zabezpieczony punkt końcowy, taki jak /weatherforecast w projekcie utworzonym z szablonu web API.
• Wybierz pozycję Wypróbuj.
• Wybierz polecenie Wykonaj. Odpowiedź to 401 - not authorized.

Rejestracja na test

• Rozwiń /register i wybierz pozycję Wypróbuj.

• W sekcji Parametry interfejsu użytkownika jest wyświetlana przykładowa treść żądania:

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

• Zastąp ciąg prawidłowym adresem e-mail i hasłem, a następnie wybierz pozycję Wykonaj.

  Aby zachować zgodność z domyślnymi regułami sprawdzania poprawności haseł, hasło musi mieć długość co najmniej sześciu znaków i zawierać co najmniej jeden z następujących znaków:

  • Wielka litera
  • Mała litera
  • Cyfra liczbowa
  • Znak niealfanumeryczny

  Jeśli wprowadzisz nieprawidłowy adres e-mail lub nieprawidłowe hasło, wynik zawiera błędy walidacji. Oto przykład treści odpowiedzi z błędami walidacji:

  {
    "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')."
      ]
    }
  }
  

  Błędy są zwracane w formacie ProblemDetails , aby klient mógł je analizować i wyświetlać błędy walidacji zgodnie z potrzebami.

  Pomyślna rejestracja powoduje 200 - OK odpowiedź.

Testowanie logowania

• Rozwiń /login i wybierz pozycję Wypróbuj. Przykładowa treść żądania zawiera dwa dodatkowe parametry:

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

  Dodatkowe właściwości JSON nie są potrzebne w tym przykładzie i można je usunąć. Ustaw wartość opcji useCookies na true.

• Zastąp ciąg adresem e-mail i hasłem, których użyłeś podczas rejestracji, a następnie wybierz pozycję Wykonaj.

  Pomyślne zalogowanie powoduje otrzymanie 200 - OK odpowiedzi z nagłówkiem odpowiedzi cookie.

Ponowne testowanie zabezpieczonego punktu końcowego

Po pomyślnym zalogowaniu uruchom ponownie zabezpieczony punkt końcowy. Uwierzytelnianie cookie jest wysyłane automatycznie z żądaniem, a punkt końcowy jest autoryzowany. Cookie-oparte uwierzytelnianie jest bezpiecznie wbudowane w przeglądarkę i działa bez problemu.

Testowanie z użyciem klientów nieprzeglądarkowych

Niektórzy klienci sieci Web mogą domyślnie nie dołączać plików cookie do nagłówka:

• Jeśli używasz narzędzia do testowania interfejsów API, może być konieczne włączenie plików cookie w ustawieniach.

• Interfejs API języka JavaScript fetch domyślnie nie zawiera plików cookie. Włącz je, ustawiając w opcjach credentials na wartość include.

• Uruchomienie HttpClient aplikacji Blazor WebAssembly wymaga HttpRequestMessage uwzględnienia poświadczeń, takich jak w poniższym przykładzie:

  request.SetBrowserRequestCredential(BrowserRequestCredentials.Include);
  

Korzystanie z uwierzytelniania opartego na tokenach

Zalecamy używanie plików cookie w aplikacjach opartych na przeglądarce, ponieważ domyślnie przeglądarka automatycznie obsługuje je bez ujawniania ich w języku JavaScript.

Wystawiono token niestandardowy (zastrzeżony dla platformy tożsamości ASP.NET Core), który może służyć do uwierzytelniania kolejnych żądań. Token jest przekazywany w nagłówku Authorization jako token elementu nośnego. Dostarczany jest również token odświeżania. Ten token umożliwia aplikacji żądanie nowego tokenu po wygaśnięciu starego tokenu bez wymuszania ponownego zalogowania się użytkownika.

Tokeny nie są standardowymi tokenami internetowymi JSON (JWTs). Użycie tokenów niestandardowych jest zamierzone, ponieważ wbudowany Identity interfejs API jest przeznaczony głównie dla prostych scenariuszy. Opcja tokenu nie ma być w pełni funkcjonalnym dostawcą usług tożsamości lub serwerem tokenów, ale zamiast tego alternatywą dla cookie opcji dla klientów, którzy nie mogą używać plików cookie.

Aby użyć uwierzytelniania opartego na tokenach, ustaw parametr ciągu zapytania useCookies na false podczas wywoływania punktu końcowego /login. Tokeny używają schematu uwierzytelniania bearer. Użycie tokenu zwróconego z wywołania do /login, kolejne wywołania chronionych punktów końcowych powinny dodać nagłówek Authorization: Bearer <token>, w którym <token> znajduje się token dostępu. Aby uzyskać więcej informacji, zobacz Używanie punktu końcowego POST /login w dalszej części tego artykułu.

Wyloguj się

Aby umożliwić użytkownikowi wylogowanie się, zdefiniuj /logout punkt końcowy podobny do następującego przykładu:

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

Podaj pusty obiekt JSON ({}) w treści żądania podczas wywoływania tego punktu końcowego. Poniższy kod to przykład wywołania punktu końcowego wylogowania:

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

Punkty MapIdentityApi<TUser> końcowe

Wywołanie MapIdentityApi<TUser> dodaje następujące punkty końcowe do aplikacji:

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

Użyj punktu końcowego POST /register

Treść żądania musi zawierać właściwości Email i Password.

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

Aby uzyskać więcej informacji, zobacz:

• Rejestracja testowa wcześniej w tym artykule.
• RegisterRequest.

Użyj punktu końcowego POST /login

W treści żądania, Email i Password są wymagane. Jeśli włączono uwierzytelnianie dwuskładnikowe (2FA), wymagane jest albo TwoFactorCode, albo TwoFactorRecoveryCode. Jeśli 2FA nie jest włączone, pomiń zarówno twoFactorCode, jak i twoFactorRecoveryCode. Aby uzyskać więcej informacji, zobacz Używanie punktu końcowego POST /manage/2fa w dalszej części tego artykułu.

Oto przykład treści żądania z wyłączonym uwierzytelnianiem dwuetapowym 2FA:

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

Oto przykłady treści żądań z włączoną usługą 2FA:

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

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

Punkt końcowy oczekuje parametru ciągu zapytania:

• useCookies - Ustaw na true wartość dla uwierzytelniania opartego na cookie. Ustaw na false lub pomiń dla uwierzytelniania opartego na tokenach.

Aby uzyskać więcej informacji na temat uwierzytelniania opartego na cookieprotokole, zobacz Testowanie logowania we wcześniejszej sekcji tego artykułu.

Uwierzytelnianie oparte na tokenach

Jeśli useCookies pasuje do false lub zostanie pominięte, jest włączone uwierzytelnianie oparte na tokenach. Treść odpowiedzi zawiera następujące właściwości:

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

Aby uzyskać więcej informacji na temat tych właściwości, zobacz AccessTokenResponse.

Umieść token dostępu w nagłówku, aby wysyłać uwierzytelnione żądania, jak pokazano w poniższym przykładzie

Authorization: Bearer {access token}

Gdy ten token dostępu ma wkrótce wygasnąć, wywołaj interfejs /refresh.

Użyj punktu końcowego POST /refresh

Do użycia tylko w przypadku uwierzytelniania opartego na tokenach. Pobiera nowy token dostępu bez wymuszania ponownego logowania użytkownika. Wywołaj ten punkt końcowy, gdy token dostępu wkrótce wygaśnie.

Treść żądania zawiera tylko element RefreshToken. Oto przykład treści żądania:

{
  "refreshToken": "string"
}

Jeśli wywołanie zakończy się pomyślnie, treść odpowiedzi to nowy AccessTokenResponseelement, jak pokazano w poniższym przykładzie.

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

Użyj punktu końcowego GET /confirmEmail

Jeśli Identity jest skonfigurowany do potwierdzenia wiadomości e-mail, pomyślne wywołanie punktu końcowego /register spowoduje wysłanie wiadomości e-mail zawierającej link do punktu końcowego /confirmEmail. Link zawiera następujące parametry ciągu zapytania:

• userId
• code
• changedEmail - Uwzględnione tylko wtedy, gdy użytkownik zmienił adres e-mail podczas rejestracji.

Identity Zawiera domyślny tekst wiadomości e-mail z potwierdzeniem. Domyślnie temat wiadomości e-mail to "Potwierdź wiadomość e-mail", a treść wiadomości e-mail wygląda następująco:

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

RequireConfirmedEmail Jeśli właściwość jest ustawiona na true, użytkownik nie może się zalogować, dopóki adres e-mail nie zostanie potwierdzony, klikając link w wiadomości e-mail. Punkt /confirmEmail końcowy:

• Potwierdza adres e-mail i umożliwia użytkownikowi logowanie się.
• Zwraca tekst "Dziękujemy za potwierdzenie wiadomości e-mail" w treści odpowiedzi.

Aby skonfigurować Identity do potwierdzania wiadomości e-mail, dodaj kod w Program.cs, aby ustawić RequireConfirmedEmail na true i dodaj klasę, która implementuje IEmailSender do kontenera Iniekcji Zależności. Na przykład:

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

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

Aby uzyskać więcej informacji, zobacz Potwierdzanie konta i odzyskiwanie hasła w usłudze ASP.NET Core.

Identity Udostępnia domyślny tekst dla innych wiadomości e-mail, które należy również wysłać, na przykład w przypadku uwierzytelniania 2FA i resetowania hasła. Aby dostosować te wiadomości e-mail, podaj niestandardową implementację interfejsu IEmailSender . W poprzednim przykładzie EmailSender jest klasą, która implementuje IEmailSender. Aby uzyskać więcej informacji, w tym przykład klasy, która implementuje IEmailSender, zobacz Potwierdzanie konta i odzyskiwanie hasła w ASP.NET Core.

Użyj punktu końcowego POST /resendConfirmationEmail

Wysyła wiadomość e-mail tylko wtedy, gdy adres jest prawidłowy dla zarejestrowanego użytkownika.

Treść żądania zawiera tylko element Email. Oto przykład treści żądania:

{
  "email": "string"
}

Aby uzyskać więcej informacji, zobacz sekcję Używanie punktu końcowego GET /confirmEmail wcześniej w tym artykule.

Użyj punktu końcowego POST /forgotPassword

Generuje wiadomość e-mail zawierającą kod resetowania hasła. Wyślij ten kod na /resetPassword adres przy użyciu nowego hasła.

Treść żądania zawiera tylko element Email. Oto przykład:

{
  "email": "string"
}

Aby uzyskać informacje o tym, jak włączyć Identity do wysyłania wiadomości e-mail, zobacz Jak korzystać z punktu końcowegoGET /confirmEmail.

Użyj punktu końcowego POST /resetPassword

Wywołaj ten punkt końcowy po wywołaniu punktu końcowego /forgotPassword i otrzymaniu kodu resetowania.

Treść żądania wymaga Email, ResetCode oraz NewPassword. Oto przykład:

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

Użyj punktu końcowego POST /manage/2fa

Konfiguruje uwierzytelnianie dwuskładnikowe (2FA) dla użytkownika. Po włączeniu uwierzytelniania 2FA, pomyślne logowanie wymaga kodu wygenerowanego przez aplikację uwierzytelniającą, oprócz adresu e-mail i hasła.

Włącz 2FA

Aby włączyć uwierzytelnianie 2FA dla aktualnie uwierzytelnioowanego użytkownika:

• Wywołaj endpoint /manage/2fa, przesyłając pusty obiekt JSON ({}) w treści żądania.

• Treść odpowiedzi udostępnia SharedKey wraz z innymi właściwościami, które nie są obecnie potrzebne. Klucz wspólny służy do konfigurowania aplikacji authenticator. Przykład treści odpowiedzi:

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

• Użyj klucza współużytkowanego, aby uzyskać jednorazowe hasło oparte na czasie (TOTP). Aby uzyskać więcej informacji, zobacz Enable QR code generation for TOTP authenticator apps in ASP.NET Core (Włączanie generowania kodu QR dla aplikacji uwierzytelniania TOTP w usłudze ASP.NET Core).

• Wywołaj punkt dostępu /manage/2fa, wysyłając kod TOTP i "enable": true w treści żądania. Na przykład:

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

• Treść odpowiedzi potwierdza, że IsTwoFactorEnabled ma wartość true i udostępnia element RecoveryCodes. Kody odzyskiwania są używane do logowania się, gdy aplikacja uwierzytelniająca nie jest dostępna. Przykład treści odpowiedzi po pomyślnym włączeniu uwierzytelniania 2FA:

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

Logowanie przy użyciu uwierzytelniania 2FA

Wywołaj punkt końcowy /login, przesyłając adres e-mail, hasło i TOTP w treści żądania. Na przykład:

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

Jeśli użytkownik nie ma dostępu do aplikacji uwierzytelniającej, zaloguj się, korzystając z punktu końcowego /login przy użyciu jednego z kodów odzyskiwania dostarczonych w momencie aktywacji 2FA. Treść żądania wygląda podobnie do następującego przykładu:

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

Resetowanie kodów odzyskiwania

Aby uzyskać nową kolekcję kodów odzyskiwania, wywołaj ten punkt końcowy z ustawieniem ResetRecoveryCodes na true. Oto przykład treści żądania:

{
  "resetRecoveryCodes": true
}

Resetowanie klucza współużytkowanego

Aby uzyskać nowy losowy klucz współużytkowany, skorzystaj z tego punktu końcowego, ustawiając ResetSharedKey na true. Oto przykład treści żądania:

{
  "resetSharedKey": true
}

Zresetowanie klucza powoduje automatyczne wyłączenie wymagania logowania dwuskładnikowego dla uwierzytelnionego użytkownika do momentu ponownego włączenia go przez późniejsze żądanie.

Zapomnij o maszynie

Aby usunąć flagę cookie "zapamiętaj mnie", jeśli jest obecna, wywołaj ten endpoint z wartością ForgetMachine ustawioną na true. Oto przykład treści żądania:

{
  "forgetMachine": true
}

Ten punkt końcowy nie ma wpływu na uwierzytelnianie oparte na tokenach.

Użyj punktu końcowego GET /manage/info

Pobiera adres e-mail i stan potwierdzenia wiadomości e-mail zalogowanego użytkownika. Oświadczenia zostały pominięte w tym punkcie końcowym ze względów bezpieczeństwa. Jeśli są potrzebne oświadczenia, użyj interfejsów API po stronie serwera, aby skonfigurować punkt końcowy dla oświadczeń. Lub zamiast udostępniać wszystkie oświadczenia użytkowników, podaj punkt końcowy weryfikacji, który akceptuje oświadczenie i odpowiada, czy użytkownik ma je.

Żądanie nie wymaga żadnych parametrów. Treść odpowiedzi zawiera właściwości Email i IsEmailConfirmed, jak w poniższym przykładzie.

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

Użyj punktu końcowego POST /manage/info

Aktualizuje adres e-mail i hasło zalogowanego użytkownika. Wyślij NewEmail, NewPassword i OldPassword w treści żądania, jak pokazano w poniższym przykładzie:

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

Oto przykład treści odpowiedzi:

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

Zobacz też

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• wybierz rozwiązanie do zarządzania tożsamościami
• Identity rozwiązania do zarządzania dla aplikacji internetowych platformy .NET
• Prosta autoryzacja w ASP.NET Core
• Dodawanie, pobieranie i usuwanie danych użytkownika w Identity projekcie ASP.NET Core
• Tworzenie aplikacji platformy ASP.NET Core przy użyciu danych użytkowników chronionych przez autoryzację
• Potwierdzenie konta i odzyskiwanie hasła w usłudze ASP.NET Core
• Włącz generowanie kodu QR dla aplikacji uwierzytelniających TOTP w ASP.NET Core
• Przykładowe zaplecze Web API dla SPA Plik .http pokazuje uwierzytelnianie oparte na tokenach. Na przykład:
  • Nie ustawia useCookies
  • Używa nagłówka Authorization do przekazania tokenu
  • Pokazuje odświeżanie w celu rozszerzenia sesji bez wymuszania ponownego logowania użytkownika
• Przykładowa aplikacja Angular, która używa Identity do zabezpieczania backendu interfejsu API