Een web-API-back-end voor SPA's beveiligen met Identity

ASP.NET Core Identity biedt API's die verificatie, autorisatie en identiteitsbeheer verwerken. De API's maken het mogelijk om eindpunten van een web-API-back-end te beveiligen met cookie-gebaseerde verificatie. Er is een optie op basis van tokens beschikbaar voor clients die geen cookies kunnen gebruiken, maar in het gebruik hiervan bent u verantwoordelijk voor het beveiligen van de tokens. We raden u aan cookies te gebruiken voor browsertoepassingen, omdat de browser deze standaard automatisch verwerkt zonder ze beschikbaar te maken voor JavaScript.

In dit artikel wordt beschreven hoe u Identity gebruikt om een web-API-back-end te beveiligen voor SPA's, zoals Angular-, React- en Vue-apps. Dezelfde back-end-API's kunnen worden gebruikt om Blazor WebAssembly appste beveiligen.

Voorwaarden

De stappen in dit artikel voegen verificatie en autorisatie toe aan een ASP.NET Core Web API-app die:

• Is nog niet geconfigureerd voor verificatie.
• Doelen vanaf net8.0 en hoger.
• Dit kan een minimale API of controller-API zijn.

In sommige testinstructies in dit artikel wordt gebruikgemaakt van de Swagger UI die is opgenomen in de projectsjabloon. De Swagger-gebruikersinterface is niet vereist voor het gebruik van Identity met een web-API-back-end.

NuGet-pakketten installeren

Installeer de volgende NuGet-pakketten:

• Microsoft.AspNetCore.Identity.EntityFrameworkCore : hiermee kunt Identity werken met Entity Framework Core (EF Core).
• Een die EF Core in staat stelt om met een database te werken, zoals een van de volgende pakketten:
  • Microsoft.EntityFrameworkCore.SqlServer of
  • Microsoft.EntityFrameworkCore.Sqlite of
  • Microsoft.EntityFrameworkCore.InMemory.

Gebruik de in-memory database voor de snelste manier om aan de slag te gaan.

Wijzig de database later in SQLite of SQL Server om gebruikersgegevens op te slaan tussen sessies tijdens het testen of voor productiegebruik. Dit introduceert bepaalde complexiteit vergeleken met in-werkgeheugen, omdat de database moet worden aangemaakt via migraties, zoals te zien is in de EF Core beginnershandleiding.

Installeer deze pakketten met behulp van de NuGet-pakketbeheer in Visual Studio of de dotnet-pakket toevoegen CLI-opdracht.

Een IdentityDbContext maken

Voeg een klasse toe met de naam ApplicationDbContext die wordt overgenomen van 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)
    { }
}

De weergegeven code biedt een speciale constructor waarmee de database voor verschillende omgevingen kan worden geconfigureerd.

Voeg indien nodig een of meer van de volgende using instructies toe bij het toevoegen van de code die in deze stappen wordt weergegeven.

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

De EF Core-context configureren

Zoals eerder vermeld, is de eenvoudigste manier om aan de slag te gaan met het gebruik van de in-memory database. Met in-memory begint elke uitvoering met een nieuwe database en hoeft u geen migraties te gebruiken. Voeg na de aanroep van WebApplication.CreateBuilder(args)de volgende code toe om Identity te configureren voor het gebruik van een in-memory database:

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

Als u gebruikersgegevens tussen sessies wilt opslaan tijdens het testen of voor productiegebruik, wijzigt u de database later in SQLite of SQL Server.

Identity-services toevoegen aan de container

Nadat de aanroep naar WebApplication.CreateBuilder(args), roept u AddAuthorization aan om services toe te voegen aan de container voor afhankelijkheidsinjectie (DI):

builder.Services.AddAuthorization();

Identity API's activeren

Na het gesprek naar WebApplication.CreateBuilder(args), roept u AddIdentityApiEndpoints<TUser>(IServiceCollection) en AddEntityFrameworkStores<TContext>(IdentityBuilder)aan.

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

Cookies en eigen tokens worden standaard geactiveerd. Cookies en tokens worden uitgegeven bij inloggen als de querystringparameter useCookies in het inlogendpoint trueis.

Kaart Identity routes

Voer na de oproep naar builder.Build(), een oproep uit naar MapIdentityApi<TUser>(IEndpointRouteBuilder) om de Identity-eindpunten in kaart te brengen:

app.MapIdentityApi<IdentityUser>();

Geselecteerde eindpunten beveiligen

Als u een eindpunt wilt beveiligen, gebruikt u de RequireAuthorization-extensiemethode in de Map{Method} aanroep waarmee de route wordt gedefinieerd. Bijvoorbeeld:

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

De methode RequireAuthorization kan ook worden gebruikt voor het volgende:

• Beveiligde Swagger UI-eindpunten, zoals wordt weergegeven in het volgende voorbeeld:

  app.MapSwagger().RequireAuthorization();
  

• Beveiligen met een specifieke claim of machtiging, zoals wordt weergegeven in het volgende voorbeeld:

  .RequireAuthorization("Admin");
  

Beveilig eindpunten in een web-API-project op basis van een controller door de [Authorize] toe te passen kenmerk op een controller of actie.

De API testen

Een snelle manier om verificatie te testen is door gebruik te maken van de in-memory database en de Swagger-gebruikersinterface die is opgenomen in de projectsjabloon. De volgende stappen laten zien hoe u de API test met de Swagger-gebruikersinterface. Zorg ervoor dat de Swagger UI-eindpunten niet zijn beveiligd.

Toegang proberen te krijgen tot een beveiligd eindpunt

• Voer de app uit en navigeer naar de Swagger-gebruikersinterface.
• Vouw een beveiligd eindpunt uit, zoals /weatherforecast in een project dat is gemaakt met de web-API-sjabloon.
• Selecteer Probeer het.
• Selecteer Voer uit. Het antwoord is 401 - not authorized.

Testregistratie

• Breid /register uit en selecteer Uitproberen.

• In de sectie Parameters van de gebruikersinterface wordt een voorbeeld van de aanvraagbody weergegeven:

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

• Vervang 'tekenreeks' door een geldig e-mailadres en wachtwoord en selecteer vervolgens uitvoeren.

  Als u wilt voldoen aan de standaardregels voor wachtwoordvalidatie, moet het wachtwoord ten minste zes tekens lang zijn en ten minste één van de volgende tekens bevatten:

  • Hoofdletter
  • Kleine letter
  • Cijfer
  • Niet-phanumerisch teken

  Als u een ongeldig e-mailadres of een ongeldig wachtwoord invoert, bevat het resultaat de validatiefouten. Hier volgt een voorbeeld van een antwoordtekst met validatiefouten:

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

  De fouten worden geretourneerd in de ProblemDetails-indeling, zodat de client deze kan parseren en validatiefouten indien nodig kan weergeven.

  Een geslaagde registratie resulteert in een 200 - OK antwoord.

Aanmelding testen

• Vouw /login uit en selecteer Uitproberen. In de voorbeeldtekst van de aanvraag ziet u twee extra parameters:

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

  De extra JSON-eigenschappen zijn niet nodig voor dit voorbeeld en kunnen worden verwijderd. Stel useCookies in op true.

• Vervang 'tekenreeks' door het e-mailadres en wachtwoord dat u hebt gebruikt om te registreren en selecteer vervolgens uitvoeren.

  Een geslaagde aanmelding resulteert in een 200 - OK antwoord met een cookie in de antwoordheader.

Het beveiligde eindpunt opnieuw testen

Voer na een geslaagde aanmelding het beveiligde eindpunt opnieuw uit. De verificatie cookie wordt automatisch verzonden met de aanvraag en het eindpunt is geautoriseerd. Cookie-gebaseerde authenticatie is veilig geïntegreerd in de browser en werkt gewoon.

Testen met niet-browserclients

Sommige webclients bevatten mogelijk niet standaard cookies in de header:

• Als u een hulpprogramma gebruikt voor het testen van API's, moet u mogelijk cookies inschakelen in de instellingen.

• De JavaScript fetch-API bevat standaard geen cookies. Schakel ze in door credentials in te stellen op de waarde include in de opties.

• Voor een HttpClient die in een Blazor WebAssembly-app draait, moet de HttpRequestMessage referenties bevatten zoals het volgende voorbeeld:

  request.SetBrowserRequestCredential(BrowserRequestCredentials.Include);
  

Verificatie op basis van tokens gebruiken

We raden u aan cookies te gebruiken in browsertoepassingen, omdat de browser deze standaard automatisch verwerkt zonder ze beschikbaar te maken voor JavaScript.

Er wordt een aangepast token (een token dat eigendom is van het ASP.NET Core Identity Platform) uitgegeven dat kan worden gebruikt om volgende aanvragen te verifiëren. Het token wordt doorgegeven in de Authorization-header als bearer-token. Er wordt ook een verversingstoken opgegeven. Met dit token kan de toepassing een nieuw token aanvragen wanneer het oude token verloopt zonder dat de gebruiker zich opnieuw hoeft aan te melden.

De tokens zijn geen standaard JSON-webtokens (JWT's). Het gebruik van aangepaste tokens is opzettelijk, omdat de ingebouwde Identity-API voornamelijk bedoeld is voor eenvoudige scenario's. De tokenoptie is niet bedoeld als een volledig functionele id-serviceprovider of tokenserver, maar in plaats daarvan een alternatief voor de cookie optie voor clients die geen cookies kunnen gebruiken.

Als u verificatie op basis van tokens wilt gebruiken, stelt u de useCookies querytekenreeksparameter in op false bij het aanroepen van het /login-eindpunt. Tokens gebruiken het bearer verificatieschema. Als u het token gebruikt dat wordt geretourneerd door de aanroep naar /login, moeten volgende aanroepen naar beveiligde eindpunten de header toevoegen Authorization: Bearer <token> waar <token> het toegangstoken is. Zie Het POST /login-eindpunt gebruiken verderop in dit artikel voor meer informatie.

Uitloggen

Als u een manier wilt bieden om de gebruiker af te melden, definieert u een /logout-eindpunt, zoals in het volgende voorbeeld:

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

Geef een leeg JSON-object ({}) op in de hoofdtekst van de aanvraag bij het aanroepen van dit eindpunt. De volgende code is een voorbeeld van een aanroep naar het afmeldingseindpunt:

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

De MapIdentityApi<TUser>-eindpunten

De aanroep van MapIdentityApi<TUser> voegt de volgende eindpunten toe aan de app:

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

Het POST /register-eindpunt gebruiken

De hoofdtekst van de aanvraag moet Email- en Password eigenschappen hebben:

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

Zie voor meer informatie:

• Testregistratie eerder in dit artikel.
• RegisterRequest.

Het POST /login-eindpunt gebruiken

In de aanvraagbody zijn Email en Password vereist. Als tweeledige verificatie (2FA) is ingeschakeld, is TwoFactorCode of TwoFactorRecoveryCode vereist. Als 2FA niet is ingeschakeld, laat u zowel twoFactorCode als twoFactorRecoveryCodeweg. Voor meer informatie, zie Gebruik de POST /manage/2fa-eindpunt verderop in dit artikel.

Hier volgt een voorbeeld van de aanvraagtekst waarbij 2FA niet is ingeschakeld:

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

Hier volgen voorbeelden van aanvraagteksten waarvoor 2FA is ingeschakeld:

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

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

Het eindpunt verwacht een queryreeksparameter:

• useCookies : ingesteld op true voor verificatie op basis van cookie. Ingesteld op false of weglaten voor verificatie op basis van tokens.

Voor meer informatie over op cookiegebaseerde verificatie, zie Test login eerder in dit artikel.

Verificatie op basis van tokens

Als useCookiesfalse is of wordt weggelaten, is authenticatie op basis van tokens ingeschakeld. De hoofdtekst van het antwoord bevat de volgende eigenschappen:

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

Zie AccessTokenResponsevoor meer informatie over deze eigenschappen.

Plaats het toegangstoken in een header om geverifieerde aanvragen te maken, zoals wordt weergegeven in het volgende voorbeeld

Authorization: Bearer {access token}

Wanneer het toegangstoken bijna verloopt, roept u het /refresh-eindpunt aan.

Het POST /refresh-eindpunt gebruiken

Alleen voor gebruik met verificatie op basis van tokens. Hiermee haalt u een nieuw toegangstoken op zonder dat de gebruiker zich opnieuw moet aanmelden. Roep dit API-eindpunt aan wanneer het toegangstoken op het punt staat te verlopen.

De hoofdtekst van de aanvraag bevat alleen de RefreshToken. Hier volgt een voorbeeld van de aanvraagtekst:

{
  "refreshToken": "string"
}

Als de aanroep succesvol is, is de antwoordtekst een nieuwe AccessTokenResponse, zoals in het volgende voorbeeld wordt getoond.

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

Het GET /confirmEmail-eindpunt gebruiken

Als Identity is ingesteld voor e-mailbevestiging, stuurt een geslaagde aanroep naar het /register-eindpunt een e-mail met een koppeling naar het /confirmEmail-eindpunt. De koppeling bevat de volgende queryreeksparameters:

• userId
• code
• changedEmail - Alleen opgenomen als de gebruiker het e-mailadres tijdens de registratie heeft gewijzigd.

Identity bevat standaardtekst voor de bevestigingsmail. Het onderwerp van het e-mailbericht is standaard 'Bevestig uw e-mail' en de hoofdtekst van de e-mail ziet er als volgt uit:

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

Als de eigenschap RequireConfirmedEmail is ingesteld op true, kan de gebruiker zich pas aanmelden nadat het e-mailadres is bevestigd door op de koppeling in het e-mailbericht te klikken. Het /confirmEmail-eindpunt:

• Bevestigt het e-mailadres en stelt de gebruiker in staat zich aan te melden.
• Retourneert de tekst 'Bedankt voor het bevestigen van uw e-mail'. In de hoofdtekst van het antwoord.

Als u Identity wilt instellen voor e-mailbevestiging, voegt u code toe in Program.cs om RequireConfirmedEmail in te stellen op true en voegt u een klasse toe waarmee IEmailSender wordt geïmplementeerd in de DI-container. Bijvoorbeeld:

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

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

Zie accountbevestiging en wachtwoordherstel in ASP.NET Corevoor meer informatie.

Identity bevat standaardtekst voor de andere e-mailberichten die ook moeten worden verzonden, zoals voor 2FA en wachtwoordherstel. Als u deze e-mailberichten wilt aanpassen, geeft u een aangepaste implementatie van de IEmailSender-interface op. In het voorgaande voorbeeld is EmailSender een klasse die IEmailSenderimplementeert. Zie voor meer informatie, waaronder een voorbeeld van een klasse die IEmailSenderimplementeert, accountbevestiging en wachtwoordherstel in ASP.NET Core.

Het POST /resendConfirmationEmail-eindpunt gebruiken

Hiermee wordt alleen een e-mailbericht verzonden als het adres geldig is voor een geregistreerde gebruiker.

De hoofdtekst van de aanvraag bevat alleen de Email. Hier volgt een voorbeeld van de aanvraagtekst:

{
  "email": "string"
}

Voor meer informatie, zie Gebruik het GET /confirmEmail-eindpunt eerder in dit artikel.

Het POST /forgotPassword-eindpunt gebruiken

Hiermee wordt een e-mailbericht gegenereerd dat een code voor het opnieuw instellen van een wachtwoord bevat. Verzend die code naar /resetPassword met een nieuw wachtwoord.

De hoofdtekst van de aanvraag bevat alleen de Email. Hier volgt een voorbeeld:

{
  "email": "string"
}

Voor informatie over het inschakelen van Identity om e-mailberichten te verzenden, zie Het GET /confirmEmail-eindpunt gebruiken.

Het POST /resetPassword-eindpunt gebruiken

Roep dit eindpunt aan na het ophalen van een resetcode door het /forgotPassword-eindpunt aan te roepen.

De aanvraagbody vereist Email, ResetCodeen NewPassword. Hier volgt een voorbeeld:

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

Het POST /manage/2fa-eindpunt gebruiken

Hiermee configureert u tweeledige verificatie (2FA) voor de gebruiker. Wanneer 2FA is ingeschakeld, is voor geslaagde aanmelding een code vereist die wordt geproduceerd door een authenticator-app, naast het e-mailadres en wachtwoord.

2FA inschakelen

2FA inschakelen voor de momenteel geverifieerde gebruiker:

• Roep het /manage/2fa-eindpunt aan en verzend een leeg JSON-object ({}) in de hoofdtekst van de aanvraag.

• De hoofdtekst van het antwoord bevat de SharedKey samen met een aantal andere eigenschappen die op dit moment niet nodig zijn. De gedeelde sleutel wordt gebruikt om de authenticator-app in te stellen. Voorbeeld van antwoordtekst:

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

• Gebruik de gedeelde sleutel om een tijdgebonden eenmalig wachtwoord (TOTP) op te halen. Zie Het genereren van QR-code inschakelen voor TOTP authenticator-apps in ASP.NET Corevoor meer informatie.

• Roep het /manage/2fa-eindpunt aan en verzend de TOTP en "enable": true in de body van het verzoek. Bijvoorbeeld:

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

• De hoofdtekst van het antwoord bevestigt dat IsTwoFactorEnabled waar is en bevat de RecoveryCodes. De herstelcodes worden gebruikt om u aan te melden wanneer de authenticator-app niet beschikbaar is. Voorbeeld van antwoordtekst na het inschakelen van 2FA:

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

Aanmelden met 2FA

Benader het /login-eindpunt door het e-mailadres, wachtwoord en TOTP mee te sturen in de aanvraagbody. Bijvoorbeeld:

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

Als de gebruiker geen toegang heeft tot de authenticator-app, meldt u zich aan door het /login eindpunt aan te roepen met een van de herstelcodes die zijn opgegeven toen 2FA werd ingeschakeld. De hoofdtekst van de aanvraag ziet er als volgt uit:

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

Herstelcodes opnieuw instellen

Als u een nieuwe verzameling herstelcodes wilt ophalen, roept u dit eindpunt aan met ResetRecoveryCodes ingesteld op true. Hier volgt een voorbeeld van de aanvraagtekst:

{
  "resetRecoveryCodes": true
}

De gedeelde sleutel opnieuw instellen

Als u een nieuwe willekeurige gedeelde sleutel wilt ophalen, roept u dit eindpunt aan met ResetSharedKey ingesteld op true. Hier volgt een voorbeeld van de aanvraagtekst:

{
  "resetSharedKey": true
}

Als u de sleutel opnieuw wilt instellen, wordt de tweeledige aanmeldingsvereiste voor de geverifieerde gebruiker automatisch uitgeschakeld totdat deze opnieuw wordt ingeschakeld door een latere aanvraag.

Vergeet de machine

Als u de cookie 'onthoud-mij-vlag' wilt wissen als deze aanwezig is, roept u dit eindpunt aan met ForgetMachine ingesteld op true. Hier volgt een voorbeeld van de aanvraagtekst:

{
  "forgetMachine": true
}

Dit eindpunt heeft geen invloed op verificatie op basis van tokens.

Het GET /manage/info-eindpunt gebruiken

Hiermee haalt u het e-mailadres en de e-mailbevestigingsstatus van de aangemelde gebruiker op. Claims zijn om veiligheidsredenen weggelaten vanuit dit eindpunt. Als claims nodig zijn, gebruikt u de API's aan de serverzijde om een eindpunt voor claims in te stellen. Of in plaats van alle claims van de gebruikers te delen, geeft u een validatie-eindpunt op dat een claim accepteert en reageert of de gebruiker deze heeft.

Voor de aanvraag zijn geen parameters vereist. De hoofdtekst van het antwoord bevat de eigenschappen Email en IsEmailConfirmed, zoals in het volgende voorbeeld:

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

Het POST /manage/info-eindpunt gebruiken

Hiermee werkt u het e-mailadres en wachtwoord van de aangemelde gebruiker bij. Verzend NewEmail, NewPassworden OldPassword in de aanvraagbody, zoals wordt weergegeven in het volgende voorbeeld:

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

Hier volgt een voorbeeld van de hoofdtekst van het antwoord:

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

Zie ook

Zie de volgende bronnen voor meer informatie:

• Een oplossing voor identiteitsbeheer kiezen
• Identity beheeroplossingen voor .NET-web-apps
• Eenvoudige autorisatie in ASP.NET Core
• gebruikersgegevens toevoegen, downloaden en verwijderen uit Identity in een ASP.NET Core-project
• Een ASP.NET Core-app maken met gebruikersgegevens die worden beveiligd door autorisatie-
• Accountbevestiging en Wachtwoordherstel in ASP.NET Core
• het genereren van QR-code inschakelen voor TOTP Authenticator-apps in ASP.NET Core
• voorbeeldweb-API-back-end voor SPA's Het HTTP-bestand toont verificatie op basis van tokens. Bijvoorbeeld:
  • Er wordt geen useCookies ingesteld
  • Gebruikt de autorisatieheader om het token door te geven
  • Toont vernieuwen om de sessie uit te breiden zonder dat de gebruiker zich opnieuw hoeft aan te melden
• voorbeeld-Angular-app die gebruikmaakt van Identity voor het beveiligen van een web-API-back-end