A Identity használata az SLA-khoz készült webes API-háttérrendszer védelméhez

ASP.NET Core Identity hitelesítést, engedélyezést és identitáskezelést kezelő API-kat biztosít. Az API-k lehetővé teszik egy webes API-háttérrendszer végpontjainak védelmét cookie-alapú hitelesítéssel. A jogkivonat-alapú beállítás olyan ügyfelek számára érhető el, akik nem tudnak cookie-kat használni, de ennek használatakor Ön felelős a jogkivonatok biztonságának biztosításáért. Azt javasoljuk, hogy böngészőalapú alkalmazásokhoz használjon cookie-kat, mert alapértelmezés szerint a böngésző automatikusan kezeli őket anélkül, hogy a JavaScriptbe irányítja őket.

Ez a cikk bemutatja, hogyan használható a Identity egy webes API-háttérrendszer védelmére olyan SLA-khoz, mint az Angular, a React és a Vue alkalmazások. Ugyanezekkel a háttérbeli API-kkal védhetők Blazor WebAssembly alkalmazások.

Előfeltételek

Az ebben a cikkben ismertetett lépések hitelesítést és engedélyezést adnak hozzá egy ASP.NET Core Web API-alkalmazáshoz, amely:

• Még nincs konfigurálva hitelesítésre.
• Cél net8.0 vagy újabb.
• Lehet minimális API vagy vezérlőalapú API.

A cikkben szereplő tesztelési utasítások némelyike a projektsablonban található Swagger felhasználói felületet használja. A Swagger felhasználói felülete nem szükséges a Identity webes API-háttérrendszerrel való használatához.

NuGet-csomagok telepítése

Telepítse a következő NuGet-csomagokat:

• Microsoft.AspNetCore.Identity.EntityFrameworkCore – Lehetővé teszi Identity számára az Entity Framework Core (EF Core) használatát.
• Az egyik, amely lehetővé teszi, hogy EF Core egy adatbázissal dolgozzon, például az alábbi csomagok egyikével:
  • Microsoft.EntityFrameworkCore.SqlServer vagy
  • Microsoft.EntityFrameworkCore.Sqlite vagy
  • Microsoft.EntityFrameworkCore.InMemory.

Az első lépések leggyorsabb módja a memórián belüli adatbázis használata.

Később módosítsa az adatbázist SQLite-ra vagy SQL Serverre a felhasználói adatok munkamenetek közötti mentéséhez tesztelés vagy éles használat esetén. Ez némi összetettséget okoz a memória alapú megoldáshoz képest, mivel az adatbázist a migrációkáltal kell létrehozni, ahogyan az a EF Core bevezető oktatóanyagbanlátható.

Telepítse ezeket a csomagokat a NuGet csomagkezelővel a Visual Studio-ban, vagy a dotnet add package CLI paranccsal.

IdentityDbContext létrehozása

Adjon hozzá egy ApplicationDbContext nevű osztályt, amely örököl a IdentityDbContext<TUser>-ből.

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

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

A megjelenő kód egy speciális konstruktort biztosít, amely lehetővé teszi az adatbázis konfigurálását különböző környezetekhez.

Az alábbi using irányelvek közül szükség szerint vegyen fel egy vagy több utasítást az ezekben a lépésekben látható kód hozzáadásakor.

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

A EF Core környezet konfigurálása

Ahogy korábban már említettük, az első lépések legegyszerűbb módja a memórián belüli adatbázis használata. A memórián belül minden futtatás egy friss adatbázissal kezdődik, és nincs szükség migrálásra. A WebApplication.CreateBuilder(args)hívása után adja hozzá a következő kódot, amely konfigurálja a Identity memórián belüli adatbázis használatára:

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

Ha felhasználói adatokat szeretne menteni a munkamenetek között tesztelés vagy éles használat esetén, módosítsa az adatbázist később SQLite vagy SQL Serverre.

Szolgáltatások hozzáadása a Identity tárolóhoz

A WebApplication.CreateBuilder(args)hívás után hívja meg a AddAuthorization-et a szolgáltatások hozzáadásához a függőséginjektáló (DI) tárolóhoz.

builder.Services.AddAuthorization();

Identity API-k aktiválása

A WebApplication.CreateBuilder(args)hívása után hívja meg AddIdentityApiEndpoints<TUser>(IServiceCollection) és AddEntityFrameworkStores<TContext>(IdentityBuilder).

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

Alapértelmezés szerint a cookie-k és a saját fejlesztésű tokenek is aktiválódnak. A cookie-k és jogkivonatok akkor kerülnek kiadásra bejelentkezéskor, ha a bejelentkezési végpont useCookies lekérdezési sztring paramétere true.

A(z) Identity útvonalak megjelenítése

A builder.Build()hívása után hívja meg a MapIdentityApi<TUser>(IEndpointRouteBuilder) a Identity végpontok leképezéséhez:

app.MapIdentityApi<IdentityUser>();

Kijelölt végpontok biztonságossá tétele

Egy végpont védelméhez használja az útvonalat meghatározó RequireAuthorization hívás Map{Method} bővítménymetódusát. Például:

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

A RequireAuthorization metódus a következőket is lehetővé teszi:

• Biztonságos Swagger felhasználói felületi végpontok, az alábbi példában látható módon:

  app.MapSwagger().RequireAuthorization();
  

• Az alábbi példa bemutatja, hogyan lehet egy bizonyos igény vagy engedély révén biztosítani valamit.

  .RequireAuthorization("Admin");
  

Egy vezérlőalapú webes API-projektben a végpontok biztonságossá tételéhez alkalmazza a [Authorize] attribútumot egy vezérlőre vagy műveletre.

Az API tesztelése

A hitelesítés tesztelésének gyors módja a memóriabeli adatbázis és a projektsablonban található Swagger felhasználói felület használata. Az alábbi lépések bemutatják, hogyan tesztelheti az API-t a Swagger felhasználói felületén. Győződjön meg arról, hogy a Swagger felhasználói felületi végpontjai nincsenek biztonságban.

Biztonságos végpont elérésének kísérlete

• Futtassa az alkalmazást, és lépjen a Swagger felhasználói felületére.
• Bontsa ki a biztonságos végpontot, például /weatherforecast a webes API-sablon által létrehozott projektben.
• Válassza Próbálja kilehetőséget.
• Válassza ki a elemet, hajtsa végre aműveletet. A válasz 401 - not authorized.

Tesztregisztráció

• Bontsa ki /register, és válassza a Próbálja kilehetőséget.

• A felhasználói felület Paraméterek szakaszában megjelenik egy mintakérés törzse:

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

• Cserélje le a "karakterláncot" érvényes e-mail-címre és jelszóra, majd válassza a Végrehajtáslehetőséget.

  Az alapértelmezett jelszóérvényesítési szabályok betartásához a jelszónak legalább hat karakter hosszúságúnak kell lennie, és tartalmaznia kell a következő karakterek legalább egyikét:

  • Nagybetű
  • Kisbetű
  • Numerikus számjegy
  • Nem alfanumerikus karakter

  Ha érvénytelen e-mail-címet vagy rossz jelszót ad meg, az eredmény tartalmazza az érvényesítési hibákat. Íme egy példa egy ellenőrzési hibákkal rendelkező választörzsre:

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

  A hibák ProblemDetails formátumban jelennek meg, hogy az ügyfél elemezhesse őket, és szükség szerint megjeleníthesse az érvényesítési hibákat.

  A sikeres regisztráció 200 - OK választ eredményez.

Bejelentkezés tesztelése

• Bontsa ki /login, és válassza a Próbálja kilehetőséget. A példakérés törzse két további paramétert jelenít meg:

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

  Ehhez a példához nincs szükség további JSON-tulajdonságokra, ezért törölhetők. Állítsa useCookiestrueértékre.

• Cserélje le a "karakterláncot" a regisztrációhoz használt e-mail címre és jelszóra, majd válassza a Végrehajtásgombot.

  A sikeres bejelentkezés 200 - OK választ eredményez, a válasz fejlécében pedig egy cookie.

A biztonságos végpont újratesztelése

A sikeres bejelentkezés után futtassa újra a biztonságos végpontot. A cookie hitelesítési információt a rendszer automatikusan elküldi a kéréssel együtt, és a végpont engedélyezve van. Cookie-alapú hitelesítés biztonságosan be van építve a böngészőbe, és "csak működik".

Tesztelés nem böngésző ügyfelekkel

Egyes webes ügyfelek alapértelmezés szerint nem tartalmaznak cookie-kat a fejlécben:

• Ha api-k teszteléséhez használ eszközt, előfordulhat, hogy engedélyeznie kell a cookie-kat a beállítások között.

• A JavaScript fetch API alapértelmezés szerint nem tartalmaz cookie-kat. Engedélyezze őket úgy, hogy a beállításokban credentials értéket include-re állítja.

• Egy HttpClient, amely egy Blazor WebAssembly alkalmazásban fut, a HttpRequestMessage-nek hitelesítő adatokat kell tartalmaznia, például:

  request.SetBrowserRequestCredential(BrowserRequestCredentials.Include);
  

Token-alapú hitelesítés használata

Azt javasoljuk, hogy böngészőalapú alkalmazásokban használjon cookie-kat, mert alapértelmezés szerint a böngésző automatikusan kezeli őket anélkül, hogy a JavaScriptbe helyeznénk őket.

A rendszer kibocsát egy egyéni tokent (amely az ASP.NET Core identitásplatform sajátja), amely a későbbi kérések hitelesítésére szolgál. A token a Authorization fejlécben "bearer token"-ként kerül átadásra. Egy frissítési token is biztosítva van. Ez a jogkivonat lehetővé teszi, hogy az alkalmazás új jogkivonatot kérjen, amikor a régi lejár anélkül, hogy a felhasználót újra be kell jelentkeznie.

A tokenek nem szabványos JSON webes tokenek (JWT-k). Az egyéni tokenek használata szándékos, mivel a beépített Identity API elsősorban egyszerű helyzetekhez készült. A jogkivonat lehetőség nem egy teljes funkcionalitású identitáskezelő vagy jogkivonat-kiszolgáló, hanem alternatíva a cookie lehetőség helyett azon ügyfelek számára, akik nem tudják használni a cookie-kat.

A token alapú hitelesítés használatához állítsa be a useCookies lekérdezési lánc paramétert false értékre a /login végpont meghívásakor. A jogkivonatok a hordozó hitelesítési sémát használják. A /loginhívásából visszaadott jogkivonat használatával a védett végpontokra irányuló későbbi hívásoknak hozzá kell adniuk a fejlécet Authorization: Bearer <token>, ahol <token> a hozzáférési jogkivonat. További információ: A POST /login végpont használata a cikk későbbi részében.

Kijelentkezés

Ha módot szeretne adni a felhasználónak a kijelentkezéshez, definiáljon egy /logout végpontot az alábbi példához hasonlóan:

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

Adjon meg egy üres JSON-objektumot ({}) a kérelem törzsében a végpont meghívásakor. Az alábbi kód egy példa a kijelentkezés végpontjára irányuló hívásra:

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

A MapIdentityApi<TUser> végpontok

A MapIdentityApi<TUser> hívása a következő végpontokat adja hozzá az alkalmazáshoz:

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

A POST /register végpont használata

A kérelemtörzsnek Email és Password tulajdonságokkal kell rendelkeznie:

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

További információ:

• Tesztregisztráció a jelen cikk korábbi részében.
• RegisterRequest.

A POST /login végpont használata

A kérelem törzsében Email és Password szükséges. Ha engedélyezve van a kéttényezős hitelesítés (2FA), TwoFactorCode vagy TwoFactorRecoveryCode van szükség. Ha a 2FA nincs engedélyezve, hagyja ki twoFactorCode és twoFactorRecoveryCode. További információ: A POST /manage/2fa végpont használata a cikk későbbi részében.

Íme egy példa a kérelem törzsére, amelynél a 2FA nincs engedélyezve:

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

Íme néhány példa a kérelem törzsére a 2FA engedélyezésével:

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

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

A végpont egy lekérdezési sztringparamétert vár:

• Állítsa useCookies-t true-re cookie-alapú hitelesítéshez. Állítsa be false-ra, vagy hagyja ki token-alapú hitelesítéshez.

A cookie-alapú hitelesítésről további információt a cikk korábbi részében, a Bejelentkezési tesztelése című szakaszban talál.

Tokenalapú hitelesítés

Ha useCookiesfalse vagy nincs megadva, a jogkivonatalapú hitelesítés engedélyezve van. A válasz törzse a következő tulajdonságokat tartalmazza:

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

További információ ezekről a tulajdonságokról: AccessTokenResponse.

A hozzáférési jogkivonatot egy fejlécbe helyezve hitelesíthet kérelmeket, ahogyan az alábbi példában is látható

Authorization: Bearer {access token}

Amikor a hozzáférési jogkivonat hamarosan lejár, hívja meg a /frissítés végpontot.

A POST /refresh végpont használata

Csak tokenalapú hitelesítéssel használható. Új hozzáférési jogkivonatot kér le anélkül, hogy a felhasználót újra be kell jelentkeznie. Hívja meg ezt a végpontot, amikor a hozzáférési jogkivonat hamarosan lejár.

A kérelem törzse csak a RefreshToken-t tartalmazza. Íme egy példa a kérelem törzsére:

{
  "refreshToken": "string"
}

Ha a hívás sikeres, a válasz törzse egy új AccessTokenResponse, ahogyan az a következő példában látható:

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

A GET /confirmEmail végpont használata

Ha Identity be van állítva az e-mail-megerősítéshez, a /register végpontra irányuló sikeres hívás egy e-mailt küld, amely a /confirmEmail végpontra mutató hivatkozást tartalmaz. A hivatkozás a következő lekérdezési sztringparamétereket tartalmazza:

• userId
• code
• changedEmail – Csak akkor tartalmazza, ha a felhasználó módosította az e-mail-címet a regisztráció során.

Identity a megerősítő e-mail alapértelmezett szövegét adja meg. Alapértelmezés szerint az e-mail tárgya "Az e-mail megerősítése", és az e-mail törzse a következő példához hasonlóan néz ki:

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

Ha a RequireConfirmedEmail tulajdonság értéke true, a felhasználó csak akkor tud bejelentkezni, ha az e-mail-cím megerősítéséhez kattintson az e-mailben található hivatkozásra. A /confirmEmail végpont:

• Megerősíti az e-mail-címet, és engedélyezi a felhasználónak a bejelentkezést.
• A válasz törzsében a "Köszönjük, hogy megerősítette az e-mail-címét" szöveget adja vissza.

Ha az e-mail-megerősítéshez szeretné beállítani a(z) Identity-t, adjon hozzá kódot a(z) Program.cs-hez, hogy beállítsa a(z) RequireConfirmedEmail értékét true-ra, és adjon hozzá egy osztályt, amely megvalósítja a IEmailSender-et a DI konténerbe. Például:

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

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

További információ: Fiók megerősítése és jelszó helyreállítása az ASP.NET Core-ban.

Identity a többi elküldendő e-mailhez is alapértelmezett szöveget biztosít, például a 2FA-t és a jelszó-visszaállítást. Az e-mailek testreszabásához adja meg a IEmailSender felület egyéni implementációját. Az előző példában EmailSender egy olyan osztály, amely IEmailSenderimplementál. További információkért, beleértve egy IEmailSendermegvalósító osztály példáját, tekintse meg a ASP.NET Corefiók megerősítéséről és jelszó-helyreállításról szóló dokumentációt.

A POST /resendConfirmationEmail végpont használata

Csak akkor küld e-mailt, ha a cím érvényes egy regisztrált felhasználóra.

A kérelem törzse csak a Email-t tartalmazza. Íme egy példa a kérelem törzsére:

{
  "email": "string"
}

További információért lásd a GET /confirmEmail végpont használatát a cikk korábbi részében.

A POST /forgotPassword végpont használata

Létrehoz egy új jelszó-visszaállítási kódot tartalmazó e-mailt. Küldje el a kódot egy új jelszóval /resetPassword.

A kérelem törzse csak a Email-t tartalmazza. Íme egy példa:

{
  "email": "string"
}

A Identity e-mailek küldésének engedélyezéséről további információt A GET /confirmEmail végpont használatacímű témakörben talál.

A POST /resetPassword végpont használata

Hívja meg ezt a végpontot az alaphelyzetbe állítási kód lekérése után a /forgotPassword végpont meghívásával.

A kérelem törzséhez Email, ResetCodeés NewPasswordszükséges. Íme egy példa:

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

A POST /manage/2fa végpont használata

Kéttényezős hitelesítést (2FA) konfigurál a felhasználó számára. Ha a 2FA engedélyezve van, a sikeres bejelentkezéshez az e-mail-cím és a jelszó mellett egy hitelesítő alkalmazás által létrehozott kódra van szükség.

2FA engedélyezése

A 2FA engedélyezése az aktuálisan hitelesített felhasználó számára:

• Hívja meg a /manage/2fa végpontot, és küldjön egy üres JSON-objektumot ({}) a kérelem törzsében.

• A válasz törzse biztosítja a SharedKey, valamint néhány olyan tulajdonságot, amelyre jelenleg nincs szükség. A megosztott kulccsal állíthatja be a hitelesítő alkalmazást. Példa a válasz törzsére:

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

• A megosztott kulccsal időalapú egyszeri jelszót (TOTP) kaphat. További információ: QR-kódlétrehozás engedélyezése TOTP-hitelesítő alkalmazásokhoz ASP.NET Core.

• Hívja meg a /manage/2fa végpontot, és küldje el a TOTP-t és a "enable": true-et a kérés törzsében. Például:

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

• A válasz törzse megerősíti, hogy IsTwoFactorEnabled igaz, és megadja a RecoveryCodes. A helyreállítási kódokat a bejelentkezéshez használják, amikor a hitelesítő alkalmazás nem érhető el. Példa a válasz törzsére a 2FA sikeres engedélyezése után.

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

Bejelentkezés 2FA-val

Hívja meg a /login végpontot, és küldje el az e-mail-címet, a jelszót és a TOTP-t a kérelem törzsében. Például:

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

Ha a felhasználó nem fér hozzá a hitelesítő alkalmazáshoz, jelentkezzen be úgy, hogy meghívja a /login végpontot a 2FA engedélyezésekor megadott helyreállítási kódok egyikével. A kérelem törzse a következő példához hasonlóan néz ki:

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

A helyreállítási kódok alaphelyzetbe állítása

A helyreállítási kódok új gyűjteményének lekéréséhez hívja meg ezt a végpontot úgy, hogy ResetRecoveryCodestrueértékre van állítva. Íme egy példa a kérelem törzsére:

{
  "resetRecoveryCodes": true
}

A megosztott kulcs alaphelyzetbe állítása

Új véletlenszerű megosztott kulcs lekéréséhez hívja meg ezt a végpontot úgy, hogy ResetSharedKeytrueértékre van állítva. Íme egy példa a kérelem törzsére:

{
  "resetSharedKey": true
}

A kulcs alaphelyzetbe állítása automatikusan letiltja a hitelesített felhasználó kétfaktoros bejelentkezési követelményét, amíg egy későbbi kérés nem engedélyezi újra.

Felejtsd el a gépet

Ha a cookie "emlékezzen rám" jelző jelen van, törölje úgy, hogy ezt a végpontot hívja meg, és állítsa be a ForgetMachine értékét igazra. Íme egy példa a kérelem törzsére:

{
  "forgetMachine": true
}

Ez a végpont nincs hatással a jogkivonat-alapú hitelesítésre.

A GET /manage/info végpont használata

Lekéri a bejelentkezett felhasználó e-mail-címét és e-mail-visszaigazolási állapotát. Az igények biztonsági okokból lettek kihagyva ebből a végpontból. Ha jogcímekre van szükség, a kiszolgálóoldali API-k használatával állítson be végpontot a jogcímekhez. Vagy ahelyett, hogy megosztaná az összes felhasználói jogcímet, adjon meg egy érvényesítési végpontot, amely elfogadja a jogcímet, és válaszol arra, hogy a felhasználó rendelkezik-e vele.

A kéréshez nincs szükség paraméterekre. A válasz törzse tartalmazza a Email és IsEmailConfirmed tulajdonságokat, ahogyan az alábbi példában is látható:

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

A POST /manage/info végpont használata

Frissíti a bejelentkezett felhasználó e-mail-címét és jelszavát. Küldje a NewEmail, NewPasswordés OldPassword elemeket a kérelem törzsében, az alábbi példának megfelelően:

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

Íme egy példa a válasz tartalmára:

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

Lásd még:

További információ:

• Identitáskezelési megoldás kiválasztása
• Identity felügyeleti megoldások .NET-webalkalmazásokhoz
• Egyszerű autentikáció ASP.NET Core
• Felhasználói adatok hozzáadása, letöltése és törlése Identity ASP.NET Core-projektben
• ASP.NET Core-alkalmazás létrehozása engedélyezési által védett felhasználói adatokkal
• Fiók megerősítése és jelszó visszaállítása az ASP.NET Core-ban
• QR-kódlétrehozás engedélyezése TOTP-hitelesítő alkalmazásokhoz a ASP.NET Core
• Minta webes API-háttérrendszer SPA-khoz A .http fájl tokenalapú hitelesítést jelenít meg. Például:
  • Nincs beállítva useCookies
  • A Hitelesítési fejléc használatával adja át a tokent
  • A munkamenet meghosszabbításához szükséges frissítést jeleníti meg anélkül, hogy a felhasználó ismételt bejelentkezésre kényszeríti
• Minta Angular-alkalmazás, amely Identity segítségével biztosít egy webes API-hátteret