Verificatie en autorisatie

Tip

Deze inhoud is een fragment uit het eBook, Enterprise Application Patterns Using .NET MAUI, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Verificatie is het proces van het verkrijgen van identificatiereferenties, zoals naam en wachtwoord van een gebruiker en het valideren van deze referenties tegen een autoriteit. De entiteit die de referenties heeft ingediend, wordt beschouwd als een geverifieerde identiteit als de referenties geldig zijn. Zodra een identiteit tot stand is gebracht, bepaalt een autorisatieproces of die identiteit toegang heeft tot een bepaalde resource.

Er zijn veel benaderingen voor het integreren van verificatie en autorisatie in een .NET-app MAUI die communiceert met een ASP.NET-webtoepassing, waaronder het gebruik van ASP.NET Core Identity, externe verificatieproviders, zoals Microsoft, Google, Facebook of Twitter, en middleware voor verificatie. De eShop-app voor meerdere platforms voert verificatie en autorisatie uit met een microservice voor een containeridentiteit die gebruikmaakt van IdentityServer. De app vraagt beveiligingstokens van IdentityServer aan om een gebruiker te verifiëren of toegang te krijgen tot een resource. Als IdentityServer tokens namens een gebruiker moet uitgeven, moet de gebruiker zich aanmelden bij IdentityServer. IdentityServer biedt echter geen gebruikersinterface of database voor verificatie. Daarom wordt in de eShop-referentietoepassing ASP.NET Core Identity voor dit doel gebruikt.

Verificatie

Verificatie is vereist wanneer een toepassing de identiteit van de huidige gebruiker moet kennen. ASP.NET Core's primaire mechanisme voor het identificeren van gebruikers is het ASP.NET Core Identity-lidmaatschapssysteem, waarin gebruikersgegevens worden opgeslagen in een gegevensarchief dat is geconfigureerd door de ontwikkelaar. Dit gegevensarchief is doorgaans een EntityFramework-archief, hoewel aangepaste archieven of pakketten van derden kunnen worden gebruikt om identiteitsgegevens op te slaan in Azure Storage, DocumentDB of andere locaties.

Voor verificatiescenario's die gebruikmaken van een lokaal gebruikersgegevensarchief en identiteitsgegevens tussen aanvragen via cookies behouden (zoals gebruikelijk in ASP.NET webtoepassingen), is ASP.NET Core Identity een geschikte oplossing. Cookies zijn echter niet altijd een natuurlijke methode voor het persistent maken en verzenden van gegevens. Een ASP.NET Core-webtoepassing die RESTful-eindpunten beschikbaar maakt die toegankelijk zijn vanuit een app, moet doorgaans bearer-tokenverificatie gebruiken omdat cookies in dit scenario niet kunnen worden gebruikt. Bearer-tokens kunnen echter eenvoudig worden opgehaald en opgenomen in de autorisatieheader van webaanvragen die zijn gedaan vanuit de app.

Bearer-tokens uitgeven met behulp van IdentityServer

IdentityServer is een opensource OpenID Connect- en OAuth 2.0-framework voor ASP.NET Core, dat kan worden gebruikt voor veel verificatie- en autorisatiescenario's, waaronder het uitgeven van beveiligingstokens voor lokale ASP.NET Core Identity-gebruikers.

Notitie

OpenID Connect en OAuth 2.0 zijn vergelijkbaar, terwijl ze verschillende verantwoordelijkheden hebben.

OpenID Connect is een verificatielaag boven op het OAuth 2.0-protocol. OAuth 2 is een protocol waarmee toepassingen toegangstokens kunnen aanvragen bij een beveiligingstokenservice en deze kunnen gebruiken om te communiceren met API's. Deze delegatie vermindert de complexiteit in zowel clienttoepassingen als API's, omdat verificatie en autorisatie kunnen worden gecentraliseerd.

OpenID Connect en OAuth 2.0 combineren de twee fundamentele beveiligingsproblemen van verificatie en API-toegang en IdentityServer is een implementatie van deze protocollen.

In toepassingen die gebruikmaken van directe client-naar-microservicecommunicatie, zoals de eShop-referentietoepassing, kan een speciale verificatiemicroservice die fungeert als een Security Token Service (STS) worden gebruikt om gebruikers te verifiëren, zoals wordt weergegeven in het volgende diagram. Zie Microservices voor meer informatie over directe communicatie tussen clients en microservices.

De eShop-app met meerdere platforms communiceert met de identiteitsmicroservice, die gebruikmaakt van IdentityServer om verificatie uit te voeren en toegangsbeheer voor API's. Daarom vraagt de app met meerdere platforms tokens aan bij IdentityServer, voor verificatie van een gebruiker of voor toegang tot een resource:

• Het verifiëren van gebruikers met IdentityServer wordt bereikt door de app met meerdere platforms die een identiteitstoken aanvraagt, wat het resultaat van een verificatieproces vertegenwoordigt. Het bevat minimaal een id voor de gebruiker en informatie over hoe en wanneer de gebruiker wordt geverifieerd. Het kan ook aanvullende identiteitsgegevens bevatten.
• Toegang tot een resource met IdentityServer wordt bereikt door de app met meerdere platforms die een toegangstoken aanvraagt, waardoor toegang tot een API-resource mogelijk is. Clients vragen toegangstokens aan en sturen ze door naar de API. Toegangstokens bevatten informatie over de client en de gebruiker, indien aanwezig. API's gebruiken die informatie vervolgens om toegang tot hun gegevens te autoriseren.

Notitie

Een client moet worden geregistreerd bij IdentityServer voordat deze tokens kan aanvragen. Zie Clients definiëren voor meer informatie over het toevoegen van clients.

IdentityServer toevoegen aan een webtoepassing

Als u wilt dat een ASP.NET Core-webtoepassing IdentityServer gebruikt, moet deze worden toegevoegd aan de Visual Studio-oplossing van de webtoepassing. Zie Setup en Overzicht in de documentatie over IdentityServer voor meer informatie. Zodra IdentityServer is opgenomen in de Visual Studio-oplossing van de webtoepassing, moet deze worden toegevoegd aan de pijplijn voor het verwerken van HTTP-aanvragen om aanvragen te verwerken voor OpenID Connect- en OAuth 2.0-eindpunten. Dit is geconfigureerd in de Program.cs van het Identity.API project, zoals wordt weergegeven in het volgende codevoorbeeld:

...

app.UseIdentityServer();

Volgorde is van belang in de HTTP-aanvraagverwerkingspijplijn van de webtoepassing. Daarom moet IdentityServer worden toegevoegd aan de pijplijn voordat het UI-framework waarmee het aanmeldingsscherm wordt geïmplementeerd.

IdentityServer configureren

IdentityServer is geconfigureerd in de Program.cs van het Identity.API project door de AddIdentityServer methode aan te roepen, zoals wordt weergegeven in het volgende codevoorbeeld van de eShop-referentietoepassing:

builder.Services.AddIdentityServer(options =>
    {
        options.Authentication.CookieLifetime = TimeSpan.FromHours(2);
    
        options.Events.RaiseErrorEvents = true;
        options.Events.RaiseInformationEvents = true;
        options.Events.RaiseFailureEvents = true;
        options.Events.RaiseSuccessEvents = true;
    
        // TODO: Remove this line in production.
        options.KeyManagement.Enabled = false;
    })
    .AddInMemoryIdentityResources(Config.GetResources())
    .AddInMemoryApiScopes(Config.GetApiScopes())
    .AddInMemoryApiResources(Config.GetApis())
    .AddInMemoryClients(Config.GetClients(builder.Configuration))
    .AddAspNetIdentity<ApplicationUser>()
    // TODO: Not recommended for production - you need to store your key material somewhere secure
    .AddDeveloperSigningCredential();

Nadat u de methode hebt services.AddIdentityServer aangeroepen, worden aanvullende Fluent API's aangeroepen om het volgende te configureren:

• Referenties die worden gebruikt voor ondertekening.
• API- en identiteitsbronnen waartoe gebruikers toegang kunnen aanvragen.
• Clients die verbinding maken met aanvraagtokens.
• ASP.NET Kernidentiteit.

Tip

Laad de IdentityServer-configuratie dynamisch. Met de API's van IdentityServer kan IdentityServer worden geconfigureerd vanuit een in-memory lijst met configuratieobjecten. In de eShop-referentietoepassing zijn deze in-memory verzamelingen vastgelegd in de toepassing. In productiescenario's kunnen ze echter dynamisch worden geladen vanuit een configuratiebestand of vanuit een database.

Zie ASP.NET Core Identity gebruiken in de documentatie van IdentityServer voor informatie over het configureren van IdentityServer voor het gebruik van ASP.NET Core Identity.

API-resources configureren

Bij het configureren van API-resources verwacht de AddInMemoryApiResources methode een IEnumerable<ApiResource> verzameling. In het volgende codevoorbeeld ziet u de GetApis methode die deze verzameling in de eShop-referentietoepassing biedt:

public static IEnumerable<ApiResource> GetApis()
{
    return new List<ApiResource>
    {
        new ApiScope("orders", "Orders Service"),
        new ApiScope("basket", "Basket Service"),
        new ApiScope("webhooks", "Webhooks registration Service"),
    };
}

Deze methode geeft aan dat IdentityServer de orders en basket-API's moet beveiligen. Daarom zijn door IdentityServer beheerde toegangstokens vereist bij het maken van aanroepen naar deze API's. Zie DE API-resource in de documentatie van IdentityServer voor meer informatie over het ApiResource type.

Identiteitsbronnen configureren

Bij het configureren van identiteitsbronnen verwacht de AddInMemoryIdentityResources methode een IEnumerable<IdentityResource> verzameling. Identiteitsbronnen zijn gegevens zoals gebruikers-id, naam of e-mailadres. Elke identiteitsresource heeft een unieke naam en willekeurige claimtypen kunnen eraan worden toegewezen, die worden opgenomen in het identiteitstoken voor de gebruiker. In het volgende codevoorbeeld ziet u de GetResources methode die deze verzameling in de eShop-referentietoepassing biedt:

public static IEnumerable<IdentityResource> GetResources()
{
    return new List<IdentityResource>
    {
        new IdentityResources.OpenId(),
        new IdentityResources.Profile()
    };
}

De OpenID Connect-specificatie specificeert enkele standaardidentiteitsbronnen. De minimale vereiste is dat ondersteuning wordt geboden voor het verzenden van een unieke id voor gebruikers. Dit wordt bereikt door de IdentityResources.OpenId identiteitsresource beschikbaar te maken.

Notitie

De klasse IdentityResources ondersteunt alle bereiken die zijn gedefinieerd in de OpenID Connect-specificatie (openid, e-mail, profiel, telefoon en adres).

IdentityServer ondersteunt ook het definiëren van aangepaste identiteitsresources. Zie Aangepaste identiteitsresources definiëren in de documentatie over IdentityServer voor meer informatie. Zie Identity Resource in de documentatie van IdentityServer voor meer informatie over het type IdentityResource.

Clients configureren

Clients zijn toepassingen die tokens kunnen aanvragen bij IdentityServer. Normaal gesproken moeten de volgende instellingen voor elke client als minimum worden gedefinieerd:

• Een unieke client-id.
• De toegestane interacties met de tokenservice (ook wel het toekenningstype genoemd).
• De locatie waar identiteit- en toegangstokens worden verzonden (ook wel een omleidings-URI genoemd).
• Een lijst met resources waartoe de client toegang heeft (ook wel bereiken genoemd).

Bij het configureren van clients verwacht de AddInMemoryClients methode een IEnumerable<Client> verzameling. In het volgende codevoorbeeld ziet u de configuratie voor de eShop-app met meerdere platforms in de GetClients methode die deze verzameling in de eShop-referentietoepassing biedt:

public static IEnumerable<Client> GetClients(Dictionary<string,string> clientsUrl)
{
    return new List<Client>
    {
        // Omitted for brevity
        new Client
        {
            ClientId = "maui",
            ClientName = "eShop MAUI OpenId Client",
            AllowedGrantTypes = GrantTypes.Code,                    
            //Used to retrieve the access token on the back channel.
            ClientSecrets =
            {
                new Secret("secret".Sha256())
            },
            RedirectUris = { configuration["MauiCallback"] },
            RequireConsent = false,
            RequirePkce = true,
            PostLogoutRedirectUris = { $"{configuration["MauiCallback"]}/Account/Redirecting" },
            AllowedScopes = new List<string>
            {
                IdentityServerConstants.StandardScopes.OpenId,
                IdentityServerConstants.StandardScopes.Profile,
                IdentityServerConstants.StandardScopes.OfflineAccess,
                "orders",
                "basket",
                "mobileshoppingagg",
                "webhooks"
            },
            //Allow requesting refresh tokens for long lived API access
            AllowOfflineAccess = true,
            AllowAccessTokensViaBrowser = true,
            AlwaysIncludeUserClaimsInIdToken = true,
            AccessTokenLifetime = 60 * 60 * 2, // 2 hours
            IdentityTokenLifetime = 60 * 60 * 2 // 2 hours
        }
    };
}

Deze configuratie geeft gegevens op voor de volgende eigenschappen:

Eigenschappen	Beschrijving
ClientId	Een unieke id voor de client.
ClientName	De weergavenaam van de client, die wordt gebruikt voor logboekregistratie en het toestemmingsscherm.
AllowedGrantTypes	Hiermee geeft u op hoe een client wil communiceren met IdentityServer. Zie De verificatiestroom configureren voor meer informatie.
ClientSecrets	Hiermee geeft u de clientgeheimreferenties op die worden gebruikt bij het aanvragen van tokens vanaf het tokeneindpunt.
RedirectUris	Hiermee geeft u de toegestane URI's op waarnaar tokens of autorisatiecodes moeten worden geretourneerd.
RequireConsent	Hiermee geeft u op of een toestemmingsscherm vereist is.
RequirePkce	Hiermee geeft u op of clients die een autorisatiecode gebruiken, een proof-sleutel moeten verzenden.
PostLogoutRedirectUris	Hiermee geeft u de toegestane URI's om te leiden naar na afmelding.
AllowedCorsOrigins	Hiermee geeft u de oorsprong van de client op, zodat IdentityServer cross-origin-aanroepen van de oorsprong kan toestaan.
AllowedScopes	Hiermee geeft u de resources op waarmee de client toegang heeft. Een client heeft standaard geen toegang tot resources.
AllowOfflineAccess	Hiermee geeft u op of de client vernieuwingstokens kan aanvragen.
AllowAccessTokensViaBrowser	Hiermee geeft u op of de client toegangstokens kan ontvangen vanuit een browservenster.
AlwaysIncludeUserClaimsInIdToken	Hiermee geeft u op dat de gebruikersclaims altijd worden toegevoegd aan het id-token. Deze moeten standaard worden opgehaald met behulp van het userinfo eindpunt.
AccessTokenLifetime	Hiermee geeft u de levensduur van het toegangstoken in seconden.
IdentityTokenLifetime	Hiermee geeft u de levensduur van het identiteitstoken in seconden.

De verificatiestroom configureren

De verificatiestroom tussen een client en IdentityServer kan worden geconfigureerd door de toekenningstypen in de Client.AllowedGrantTypes eigenschap op te geven. De specificaties van OpenID Connect en OAuth 2.0 definiëren verschillende verificatiestromen, waaronder:

Verificatiestroom	Beschrijving
Impliciet	Deze stroom is geoptimaliseerd voor browsertoepassingen en moet worden gebruikt voor gebruikersverificatie- of verificatie- en toegangstokenaanvragen. Alle tokens worden verzonden via de browser en daarom zijn geavanceerde functies zoals vernieuwingstokens niet toegestaan.
Autorisatiecode	Deze stroom biedt de mogelijkheid om tokens op te halen in een back-kanaal, in plaats van het browserfrontkanaal, terwijl ook clientverificatie wordt ondersteund.
Hybride	Deze stroom is een combinatie van de typen impliciete en autorisatiecodetoestemming. Het identiteitstoken wordt verzonden via het browserkanaal en bevat het ondertekende protocolantwoord en andere artefacten, zoals de autorisatiecode. Nadat het antwoord is gevalideerd, moet het back-kanaal worden gebruikt om het toegangs- en vernieuwingstoken op te halen.

Tip

Overweeg het gebruik van de hybride verificatiestroom. De hybride verificatiestroom beperkt een aantal aanvallen die van toepassing zijn op het browserkanaal en is de aanbevolen stroom voor systeemeigen toepassingen die toegangstokens willen ophalen (en mogelijk tokens vernieuwen).

Zie Grant Types in de documentatie over IdentityServer voor meer informatie over verificatiestromen.

Verificatie uitvoeren

Als IdentityServer tokens namens een gebruiker moet uitgeven, moet de gebruiker zich aanmelden bij IdentityServer. IdentityServer biedt echter geen gebruikersinterface of database voor verificatie. Daarom wordt in de eShop-referentietoepassing ASP.NET Core Identity voor dit doel gebruikt.

De eShop-app met meerdere platformen wordt geverifieerd met IdentityServer met de hybride verificatiestroom, die wordt geïllustreerd in het onderstaande diagram.

Er wordt een aanmeldingsaanvraag ingediend bij <base endpoint>:5105/connect/authorize. Na geslaagde verificatie retourneert IdentityServer een verificatieantwoord met een autorisatiecode en een identiteitstoken. De autorisatiecode wordt verzonden naar <base endpoint>:5105/connect/token, die reageert met toegangs-, identiteits- en vernieuwingstokens.

De eShop-app voor meerdere platforms meldt zich af bij IdentityServer door een aanvraag te verzenden naar <base endpoint>:5105/connect/endsession met aanvullende parameters. Nadat u zich hebt afgemeld, reageert IdentityServer door een URI na afmelding terug te sturen naar de app met meerdere platforms. In het onderstaande diagram ziet u dit proces.

In de eShop-app met meerdere platformen wordt communicatie met IdentityServer uitgevoerd door de IdentityService klasse, waarmee de IIdentityService interface wordt geïmplementeerd. Deze interface geeft aan dat de implementatieklasse moet biedenSignInAsync, GetUserInfoAsync SignOutAsyncen GetAuthTokenAsync methoden.

Aanmelden

Wanneer de gebruiker op de knop op de LOGIN LoginViewknop tikt, wordt de SignInCommand in de LoginViewModel klasse uitgevoerd, die vervolgens de SignInAsync methode uitvoert. In het volgende codevoorbeeld ziet u deze methode:

[RelayCommand]
private async Task SignInAsync()
{
    await IsBusyFor(
        async () =>
        {
            var loginSuccess = await _appEnvironmentService.IdentityService.SignInAsync();

            if (loginSuccess)
            {
                await NavigationService.NavigateToAsync("//Main/Catalog");
            }
        });
}

Met deze methode wordt de SignInAsync methode in de IdentityService klasse aangeroepen, zoals wordt weergegeven in het volgende codevoorbeeld:

public async Task<bool> SignInAsync()
{
    var response = await GetClient().LoginAsync(new LoginRequest()).ConfigureAwait(false);

    if (response.IsError)
    {
        return false;
    }

    await _settingsService
        .SetUserTokenAsync(
            new UserToken
            {
                AccessToken = response.AccessToken,
                IdToken = response.IdentityToken,
                RefreshToken = response.RefreshToken,
                ExpiresAt = response.AccessTokenExpiration
            })
        .ConfigureAwait(false);

    return !response.IsError;
}

Het IdentityService maakt gebruik van het OidcClient meegeleverde IdentityModel.OidcClient NuGet-pakket. Deze client geeft de verificatiewebweergave weer voor de gebruiker in de toepassing en legt het verificatieresultaat vast. De client maakt verbinding met de URI voor het autorisatie-eindpunt van IdentityServer met de vereiste parameters. Het autorisatie-eindpunt bevindt zich op /connect/authorize poort 5105 van het basiseindpunt dat wordt weergegeven als een gebruikersinstelling. Zie Configuration Management voor meer informatie over gebruikersinstellingen.

Notitie

De kwetsbaarheid voor aanvallen van de eShop-app voor meerdere platforms wordt verminderd door de PKCE-extensie (Proof Key for Code Exchange) te implementeren in OAuth. PKCE beschermt de autorisatiecode tegen gebruik als deze wordt onderschept. Dit wordt bereikt door de client die een geheime verificator genereert, waarvan een hash wordt doorgegeven in de autorisatieaanvraag en die onbehasht wordt weergegeven bij het inwisselen van de autorisatiecode. Zie Proof Key for Code Exchange by OAuth Public Clients on the Internet Engineering Task Force website voor meer informatie over PKCE.

Als het tokeneindpunt geldige verificatiegegevens, autorisatiecode en PKCE-geheimverificatie ontvangt, reageert het met een toegangstoken, identiteitstoken en vernieuwingstoken. Het toegangstoken (waarmee toegang tot API-resources mogelijk is) en het identiteitstoken worden opgeslagen als toepassingsinstellingen en paginanavigatie wordt uitgevoerd. Daarom is het algehele effect in de eShop-app voor meerdere platforms dit: op voorwaarde dat gebruikers zich kunnen verifiëren met IdentityServer, worden ze naar de //Main/Catalog route genavigeerd. Dit is een TabbedPage route die het CatalogView geselecteerde tabblad weergeeft.

Zie Navigatie voor meer informatie over paginanavigatie. Zie Navigatie aanroepen met behulp van gedrag voor informatie over hoe webweergavenavigatie ervoor zorgt dat een weergavemodelmethode wordt uitgevoerd. Zie Configuratiebeheer voor meer informatie over toepassingsinstellingen.

Notitie

De eShop staat ook een mock-aanmelding toe wanneer de app is geconfigureerd voor het gebruik van mock-services in de SettingsView. In deze modus communiceert de app niet met IdentityServer, maar kan de gebruiker zich aanmelden met behulp van referenties.

Afmelden

Wanneer de gebruiker op de LOG OUT knop in de ProfileViewklasse tikt, wordt de LogoutCommand in de ProfileViewModel klasse uitgevoerd, waarmee de LogoutAsync methode wordt uitgevoerd. Met deze methode wordt paginanavigatie uitgevoerd naar de LoginView pagina, waarbij een Logout queryparameter wordt doorgegeven aan true.

Deze parameter wordt geëvalueerd in de ApplyQueryAttributes methode. Als de Logout parameter aanwezig is met een true waarde, wordt de PerformLogoutAsync methode van de LoginViewModel klasse uitgevoerd. Deze wordt weergegeven in het volgende codevoorbeeld:

private async Task PerformLogoutAsync()
{
    await _appEnvironmentService.IdentityService.SignOutAsync();

    _settingsService.UseFakeLocation = false;

    UserName.Value = string.Empty;
    Password.Value = string.Empty;
}

Met deze methode wordt de SignOutAsync methode in de IdentityService klasse aangeroepen, die de OidcClient sessie van de gebruiker aanroept en alle opgeslagen gebruikerstokens wist. Zie Configuratiebeheer voor meer informatie over toepassingsinstellingen. In het volgende codevoorbeeld ziet u de SignOutAsync methode:

public async Task<bool> SignOutAsync()
{
    var response = await GetClient().LogoutAsync(new LogoutRequest()).ConfigureAwait(false);

    if (response.IsError)
    {
        return false;
    }

    await _settingsService.SetUserTokenAsync(default);

    return !response.IsError;
}

Deze methode gebruikt de OidcClient methode om de URI aan te roepen naar het eindpunt van de endsessie van IdentityServer met de vereiste parameters. Het eindpunt van de eindsessie bevindt zich op /connect/endsession poort 5105 van het basiseindpunt dat wordt weergegeven als een gebruikersinstelling. Zodra de gebruiker is afgemeld, LoginView wordt deze aan de gebruiker gepresenteerd en worden alle opgeslagen gebruikersgegevens gewist.

Zie Navigatie voor meer informatie over paginanavigatie. Zie Navigatie aanroepen met behulp van gedrag voor informatie over hoe navigatie ervoor zorgt dat WebView een weergavemodelmethode wordt uitgevoerd. Zie Configuratiebeheer voor meer informatie over toepassingsinstellingen.

Notitie

De eShop staat ook een mock-afmelding toe wanneer de app is geconfigureerd voor het gebruik van mock-services in de SettingsView. In deze modus communiceert de app niet met IdentityServer en wist in plaats daarvan eventuele opgeslagen tokens uit toepassingsinstellingen.

Autorisatie

Na verificatie moeten ASP.NET Core-web-API's vaak toegang verlenen, waardoor een service API's beschikbaar kan maken voor sommige geverifieerde gebruikers, maar niet voor iedereen.

Het beperken van de toegang tot een ASP.NET Core-route kan worden bereikt door een kenmerk Autoriseren toe te passen op een controller of actie, waardoor de toegang tot de controller of actie wordt beperkt tot geverifieerde gebruikers, zoals wordt weergegeven in het volgende codevoorbeeld:

[Authorize]
public sealed class BasketController : Controller
{
    // Omitted for brevity
}

Als een onbevoegde gebruiker probeert toegang te krijgen tot een controller of actie die is gemarkeerd met het kenmerk Autoriseren, retourneert het API-framework een 401 (unauthorized) HTTP-statuscode.

Notitie

Parameters kunnen worden opgegeven op het kenmerk Autoriseren om een API te beperken tot specifieke gebruikers. Zie ASP.NET Core Docs: Authorization voor meer informatie.

IdentityServer kan worden geïntegreerd in de autorisatiewerkstroom, zodat de toegangstokens controleautorisatie bieden. Deze benadering wordt weergegeven in het onderstaande diagram.

De eShop-app met meerdere platforms communiceert met de identiteitsmicroservice en vraagt een toegangstoken aan als onderdeel van het verificatieproces. Het toegangstoken wordt vervolgens doorgestuurd naar de API's die beschikbaar worden gesteld door de bestellen en mandmicroservices als onderdeel van de toegangsaanvragen. Toegangstokens bevatten informatie over de client en de gebruiker. API's gebruiken die informatie vervolgens om toegang tot hun gegevens te autoriseren. Zie API-resources configureren voor meer informatie over het configureren van IdentityServer voor het beveiligen van API's.

IdentityServer configureren om autorisatie uit te voeren

Als u autorisatie wilt uitvoeren met IdentityServer, moet de middleware voor autorisatie worden toegevoegd aan de HTTP-aanvraagpijplijn van de webtoepassing. De middleware wordt toegevoegd in de AddDefaultAuthentication extensiemethode, die wordt aangeroepen vanuit de AddApplicationServices methode in de Program klasse en wordt gedemonstreerd in het volgende codevoorbeeld van de eShop-referentietoepassing:

public static IServiceCollection AddDefaultAuthentication(this IHostApplicationBuilder builder)
{
    var services = builder.Services;
    var configuration = builder.Configuration;

    var identitySection = configuration.GetSection("Identity");

    if (!identitySection.Exists())
    {
        // No identity section, so no authentication
        return services;
    }

    // prevent from mapping "sub" claim to nameidentifier.
    JsonWebTokenHandler.DefaultInboundClaimTypeMap.Remove("sub");

    services.AddAuthentication().AddJwtBearer(options =>
    {
        var identityUrl = identitySection.GetRequiredValue("Url");
        var audience = identitySection.GetRequiredValue("Audience");

        options.Authority = identityUrl;
        options.RequireHttpsMetadata = false;
        options.Audience = audience;
        options.TokenValidationParameters.ValidIssuers = [identityUrl];
        options.TokenValidationParameters.ValidateAudience = false;
    });

    services.AddAuthorization();

    return services;
}

Deze methode zorgt ervoor dat de API alleen kan worden geopend met een geldig toegangstoken. De middleware valideert het binnenkomende token om ervoor te zorgen dat het wordt verzonden van een vertrouwde verlener en valideert dat het token geldig is voor gebruik met de API die het ontvangt. Als u bladert naar de order- of basketcontroller, wordt er een 401 (unauthorized) HTTP-statuscode geretourneerd die aangeeft dat een toegangstoken vereist is.

Toegangsaanvragen maken voor API's

Wanneer u aanvragen indient voor de order- en mandmicroservices, moet het toegangstoken dat tijdens het verificatieproces bij IdentityServer is verkregen, worden opgenomen in de aanvraag, zoals wordt weergegeven in het volgende codevoorbeeld:

public async Task CreateOrderAsync(Models.Orders.Order newOrder)
{
    var authToken = await _identityService.GetAuthTokenAsync().ConfigureAwait(false);

    if (string.IsNullOrEmpty(authToken))
    {
        return;
    }

    var uri = $"{UriHelper.CombineUri(_settingsService.GatewayOrdersEndpointBase, ApiUrlBase)}?api-version=1.0";

    var success = await _requestProvider.PostAsync(uri, newOrder, authToken, "x-requestid").ConfigureAwait(false);
}

Het toegangstoken wordt opgeslagen met de IIdentityService implementatie en kan worden opgehaald met behulp van de GetAuthTokenAsync methode.

Op dezelfde manier moet het toegangstoken worden opgenomen bij het verzenden van gegevens naar een met IdentityServer beveiligde API, zoals wordt weergegeven in het volgende codevoorbeeld:

public async Task ClearBasketAsync()
{
    var authToken = await _identityService.GetAuthTokenAsync().ConfigureAwait(false);

    if (string.IsNullOrEmpty(authToken))
    {
        return;
    }

    await GetBasketClient().DeleteBasketAsync(new DeleteBasketRequest(), CreateAuthenticationHeaders(authToken))
        .ConfigureAwait(false);
}

Het toegangstoken wordt opgehaald uit de IIdentityService en opgenomen in de aanroep van de ClearBasketAsync methode in de BasketService klasse.

De RequestProvider klasse in de eShop-app voor meerdere platforms gebruikt de HttpClient klasse om aanvragen te doen voor de RESTful-API's die beschikbaar worden gesteld door de eShop-referentietoepassing. Wanneer u aanvragen indient bij de order- en mand-API's waarvoor autorisatie is vereist, moet er een geldig toegangstoken worden opgenomen in de aanvraag. Dit wordt bereikt door het toegangstoken toe te voegen aan de headers van het HttpClient-exemplaar, zoals wordt weergegeven in het volgende codevoorbeeld:

httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);

Met DefaultRequestHeaders de eigenschap van de HttpClient klasse worden de headers weergegeven die met elke aanvraag worden verzonden en wordt het toegangstoken toegevoegd aan de Authorization koptekst met het voorvoegsel van de tekenreeks Bearer. Wanneer de aanvraag wordt verzonden naar een RESTful-API, wordt de waarde van de Authorization header geëxtraheerd en gevalideerd om ervoor te zorgen dat deze wordt verzonden vanaf een vertrouwde verlener en wordt gebruikt om te bepalen of de gebruiker gemachtigd is om de API aan te roepen die deze ontvangt.

Zie Toegang tot externe gegevens voor meer informatie over hoe de eShop-app met meerdere platforms webaanvragen doet.

Samenvatting

Er zijn veel benaderingen voor het integreren van verificatie en autorisatie in een .NET-app MAUI die communiceert met een ASP.NET-webtoepassing. De eShop-app voor meerdere platforms voert verificatie en autorisatie uit met een microservice voor een containeridentiteit die gebruikmaakt van IdentityServer. IdentityServer is een opensource OpenID Connect- en OAuth 2.0-framework voor ASP.NET Core dat kan worden geïntegreerd met ASP.NET Core Identity om bearer-tokenverificatie uit te voeren.

De app met meerdere platforms vraagt beveiligingstokens van IdentityServer aan om een gebruiker te verifiëren of toegang te krijgen tot een resource. Bij het openen van een resource moet een toegangstoken worden opgenomen in de aanvraag voor API's waarvoor autorisatie is vereist. De middleware van IdentityServer valideert binnenkomende toegangstokens om ervoor te zorgen dat ze worden verzonden van een vertrouwde verlener en dat ze geldig zijn om te worden gebruikt met de API die ze ontvangt.