Jak zabezpieczyć Identity zaplecze internetowego interfejsu API dla spA

ASP.NET Core Identity udostępnia interfejsy API obsługujące uwierzytelnianie, autoryzację i identity zarządzanie. Interfejsy API umożliwiają zabezpieczanie punktów końcowych zaplecza internetowego interfejsu API przy użyciu cookieuwierzytelniania opartego na protokole . 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 przedstawiono sposób zabezpieczania Identity zaplecza internetowego interfejsu API dla spA, takich jak aplikacje Angular, React i Vue. Te same interfejsy API zaplecza mogą służyć do zabezpieczania Blazor WebAssembly aplikacji.

Wymagania wstępne

Kroki przedstawione w tym artykule dodają uwierzytelnianie i autoryzację do aplikacji internetowego interfejsu API platformy ASP.NET Core, która:

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

Niektóre instrukcje testowania w tym artykule używają interfejsu użytkownika struktury Swagger dołączonego do szablonu projektu. Interfejs użytkownika struktury Swagger nie jest wymagany do użycia Identity z zapleczem internetowego interfejsu 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ą, ponieważ wymaga utworzenia bazy danych za pośrednictwem migracji, jak pokazano w samouczku EF Corewprowadzającym.

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

Tworzenie elementu 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 co najmniej jedną z poniższych using dyrektyw zgodnie z potrzebami podczas dodawania kodu pokazanego w tych krokach.

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

EF Core Konfigurowanie kontekstu

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 używanie 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 metody wywołaj metodę WebApplication.CreateBuilder(args), wywołaj metodę AddAuthorization , aby dodać usługi do kontenera wstrzykiwania zależności (DI):

builder.Services.AddAuthorization();

Aktywowanie Identity interfejsów API

Po wywołaniu metody wywołania wywołaj metodę WebApplication.CreateBuilder(args)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. Pliki cookie i tokeny są wystawiane podczas logowania, jeśli useCookies parametr ciągu zapytania w punkcie końcowym logowania to true.

Mapuj Identity trasy

Po wywołaniu metody builder.Build()wywołania metody wywołaj metodę MapIdentityApi<TUser>(IEndpointRouteBuilder) , aby zamapować Identity punkty końcowe:

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 punktów końcowych interfejsu użytkownika struktury 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 zabezpieczanie punktów końcowych przez zastosowanie atrybutu [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ć interfejs API za pomocą interfejsu użytkownika struktury Swagger. Upewnij się, że punkty końcowe interfejsu użytkownika struktury Swagger 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 przez szablon internetowego interfejsu API.
• Wybierz pozycję Wypróbuj.
• Wybierz polecenie Wykonaj. Odpowiedź to 401 - not authorized.

Testowanie rejestracji

• 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 niefanumeryczny

  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 ciąg adresem e-mail i hasłem użytym do zarejestrowania, a następnie wybierz pozycję Wykonaj.

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

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. CookieUwierzytelnianie oparte na protokole jest bezpiecznie wbudowane w przeglądarkę i "działa".

Testowanie przy użyciu klientów innych niżbrowser

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 credentials wartość include w opcjach.

• Uruchomienie HttpClient w Blazor WebAssembly aplikacji 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.

Wystawiony jest token niestandardowy (zastrzeżony dla platformy ASP.NET Core identity ), który może służyć do uwierzytelniania kolejnych żądań. Token jest przekazywany w nagłówku Authorization jako token elementu nośnego. Dostępny 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 identity dostawcą usług lub serwerem tokenów, ale zamiast tego alternatywą dla cookie klientów, którzy nie mogą używać plików cookie.

Aby użyć uwierzytelniania opartego useCookies na tokenach, ustaw parametr ciągu zapytania na false wartość podczas wywoływania punktu końcowego /login . Tokeny używają schematu uwierzytelniania elementu nośnego. Użycie tokenu zwróconego z wywołania metody do /loginmetody , 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 metody w celu MapIdentityApi<TUser> dodawania następujących punktów końcowych 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

Korzystanie z punktu końcowego POST /register

Treść żądania musi mieć Email właściwości i Password :

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

Aby uzyskać więcej informacji, zobacz:

• Przetestuj rejestrację wcześniej w tym artykule.
• RegisterRequest.

Korzystanie z punktu końcowego POST /login

W treści Email żądania i Password są wymagane. Jeśli włączono uwierzytelnianie dwuskładnikowe (2FA), TwoFactorCode TwoFactorRecoveryCode albo jest wymagane. Jeśli uwierzytelnianie 2FA nie jest włączone, pomiń zarówno uwierzytelnianie, jak twoFactorCode 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 nie włączoną uwierzytelnianiem 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 wartość lub false pomiń uwierzytelnianie oparte 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 zostanie false pominięte lub 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 token dostępu wkrótce wygaśnie, wywołaj punkt końcowy /refresh .

Korzystanie z 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"
}

Korzystanie z punktu końcowego GET /confirmEmail

Jeśli Identity skonfigurowana jest opcja potwierdzenia wiadomości e-mail, pomyślne wywołanie /register punktu końcowego 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 potwierdzenie wiadomości e-mail, dodaj kod , Program.cs aby ustawić RequireConfirmedEmail wartość i true dodać klasę implementającą IEmailSender do kontenera DI. 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 jest to klasa, EmailSender która implementuje IEmailSenderelement . Aby uzyskać więcej informacji, w tym przykład klasy, która implementuje IEmailSenderprogram , zobacz Potwierdzanie konta i odzyskiwanie hasła w programie ASP.NET Core.

Korzystanie z 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 Używanie punktu końcowego GET /confirmEmail wcześniej w tym artykule.

Korzystanie z 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 na temat włączania Identity wysyłania wiadomości e-mail, zobacz Korzystanie z punktu końcowegoGET /confirmEmail.

Korzystanie z punktu końcowego POST /resetPassword

Wywołaj ten punkt końcowy po otrzymaniu kodu resetowania /forgotPassword , wywołując punkt końcowy.

Treść żądania wymaga , EmailResetCodei NewPassword. Oto przykład:

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

Korzystanie z 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ę wystawcy uwierzytelniania oprócz adresu e-mail i hasła.

Włączanie uwierzytelniania 2FA

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

• Wywołaj /manage/2fa punkt końcowy, wysył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ą w tym momencie 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 /manage/2fa punkt końcowy, wysyłając element 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 wystawcy uwierzytelniania 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 /login punkt końcowy, wysył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 wystawcy uwierzytelniania, zaloguj się, wywołując /login punkt końcowy przy użyciu jednego z kodów odzyskiwania podanych po włączeniu uwierzytelniania 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, wywołaj ten punkt końcowy z ustawionym 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 wyczyścić flagę cookie "zapamiętaj mnie", jeśli jest obecna, wywołaj ten punkt końcowy z ustawionym wartością ForgetMachine true. Oto przykład treści żądania:

{
  "forgetMachine": true
}

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

Korzystanie z 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 z tego punktu końcowego 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 Email właściwości i IsEmailConfirmed , jak w poniższym przykładzie:

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

Korzystanie z punktu końcowego POST /manage/info

Aktualizuje adres e-mail i hasło zalogowanego użytkownika. Wyślij NewEmailelement , NewPasswordi 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:

• identity Wybieranie rozwiązania do zarządzania
• 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łączanie generowania kodu QR dla aplikacji uwierzytelniającego TOTP w usłudze ASP.NET Core
• Przykładowe zaplecze internetowego interfejsu API dla spAs Plik HTTP pokazuje uwierzytelnianie oparte na tokenach. Na przykład: .
  • Nie ustawia useCookies
  • Używa nagłówka autoryzacji do przekazania tokenu
  • Pokazuje odświeżanie w celu rozszerzenia sesji bez wymuszania ponownego logowania użytkownika
• Przykładowa aplikacja Angular używana Identity do zabezpieczania zaplecza internetowego interfejsu API