Autentisering och auktorisering

Dricks

Det här innehållet är ett utdrag från eBook, Enterprise Application Patterns Using .NET MAUI, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

Autentisering är processen för att hämta autentiseringsuppgifter för identifiering, till exempel namn och lösenord från en användare och verifiera dessa autentiseringsuppgifter mot en utfärdare. Entiteten som skickade autentiseringsuppgifterna betraktas som en autentiserad identitet om autentiseringsuppgifterna är giltiga. När en identitet har upprättats avgör en auktoriseringsprocess om identiteten har åtkomst till en viss resurs.

Det finns många metoder för att integrera autentisering och auktorisering i en .NET-app MAUI som kommunicerar med en ASP.NET webbapp, inklusive användning av ASP.NET Core Identity, externa autentiseringsproviders som Microsoft, Google, Facebook eller Twitter och mellanprogram för autentisering. Multiplattformsappen eShopOnContainers utför autentisering och auktorisering med en containerbaserad identitetsmikrotjänst som använder IdentityServer 4. Appen begär säkerhetstoken från IdentityServer för att autentisera en användare eller komma åt en resurs. För att IdentityServer ska kunna utfärda token åt en användare måste användaren logga in på IdentityServer. IdentityServer tillhandahåller dock inte något användargränssnitt eller en databas för autentisering. I referensprogrammet eShopOnContainers används därför ASP.NET Core Identity för detta ändamål.

Autentisering

Autentisering krävs när ett program behöver känna till den aktuella användarens identitet. ASP.NET Cores primära mekanism för att identifiera användare är ASP.NET Core Identity-medlemskapssystemet, som lagrar användarinformation i ett datalager som konfigurerats av utvecklaren. Det här datalagret är vanligtvis ett EntityFramework-lager, men anpassade butiker eller paket från tredje part kan användas för att lagra identitetsinformation i Azure Storage, DocumentDB eller andra platser.

För autentiseringsscenarier som använder ett lokalt användardatalager och bevarar identitetsinformation mellan begäranden via cookies (vilket är vanligt i ASP.NET webbprogram) är ASP.NET Core Identity en lämplig lösning. Cookies är dock inte alltid ett naturligt sätt att bevara och överföra data. Till exempel måste ett ASP.NET Core-webbprogram som exponerar RESTful-slutpunkter som nås från en app vanligtvis använda ägartokenautentisering eftersom cookies inte kan användas i det här scenariot. Ägartoken kan dock enkelt hämtas och inkluderas i auktoriseringshuvudet för webbbegäranden som görs från appen.

Utfärda ägartoken med IdentityServer 4

IdentityServer 4 är ett öppen källkod OpenID-Anslut- och OAuth 2.0-ramverk för ASP.NET Core, som kan användas för många autentiserings- och auktoriseringsscenarier, inklusive utfärdande av säkerhetstoken för lokala ASP.NET Core Identity-användare.

Kommentar

OpenID Anslut och OAuth 2.0 är mycket lika, samtidigt som de har olika ansvarsområden.

OpenID Anslut är ett autentiseringslager ovanpå OAuth 2.0-protokollet. OAuth 2 är ett protokoll som gör att program kan begära åtkomsttoken från en säkerhetstokentjänst och använda dem för att kommunicera med API:er. Den här delegeringen minskar komplexiteten i både klientprogram och API:er eftersom autentisering och auktorisering kan centraliseras.

OpenID Anslut och OAuth 2.0 kombinerar de två grundläggande säkerhetsproblemen för autentisering och API-åtkomst, och IdentityServer 4 är en implementering av dessa protokoll.

I program som använder direkt kommunikation mellan klienter och mikrotjänster, till exempel referensprogrammet eShopOnContainers, kan en dedikerad mikrotjänst för autentisering som fungerar som en säkerhetstokentjänst (STS) användas för att autentisera användare, enligt följande diagram. Mer information om direkt kommunikation mellan klienter och mikrotjänster finns i Mikrotjänster.

Multiplattformsappen eShopOnContainers kommunicerar med identitetsmikrotjänsten, som använder IdentityServer 4 för att utföra autentisering och åtkomstkontroll för API:er. Därför begär flera plattformsappar token från IdentityServer, antingen för att autentisera en användare eller för att få åtkomst till en resurs:

• Att autentisera användare med IdentityServer uppnås genom att multiplattformsappen begär en identitetstoken som representerar resultatet av en autentiseringsprocess. Den innehåller minst en identifierare för användaren och information om hur och när användaren autentiseras. Den kan också innehålla ytterligare identitetsdata.
• Åtkomst till en resurs med IdentityServer uppnås genom att appen för flera plattformar begär en åtkomsttoken , vilket ger åtkomst till en API-resurs. Klienter begär åtkomsttoken och vidarebefordrar dem till API:et. Åtkomsttoken innehåller information om klienten och användaren, om den finns. API:er använder sedan den informationen för att auktorisera åtkomst till sina data.

Kommentar

En klient måste registreras med IdentityServer innan den kan begära token. Mer information om hur du lägger till klienter finns i Definiera klienter.

Lägga till IdentityServer i ett webbprogram

För att ett ASP.NET Core-webbprogram ska kunna använda IdentityServer 4 måste det läggas till i webbprogrammets Visual Studio-lösning. Mer information finns i Installation och översikt i IdentityServer-dokumentationen. När IdentityServer ingår i webbprogrammets Visual Studio-lösning måste den läggas till i pipelinen för HTTP-begärandebearbetning för att hantera begäranden till OpenID-Anslut- och OAuth 2.0-slutpunkter. Detta uppnås i Configure -metoden i webbprogrammets Startup klass, vilket visas i följande kodexempel:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    app.UseIdentity();
}

Beställningen är viktig i webbprogrammets PIPELINE för bearbetning av HTTP-begäranden. Därför måste IdentityServer läggas till i pipelinen innan användargränssnittsramverket som implementerar inloggningsskärmen.

Konfigurera IdentityServer

IdentityServer bör konfigureras i metoden ConfigureServices i webbprogrammets startklass genom att anropa services.AddIdentityServer metoden, vilket visas i följande kodexempel från referensprogrammet eShopOnContainers:

public void ConfigureServices(IServiceCollection services)
{
    services
        .AddIdentityServer(x => x.IssuerUri = "null")
        .AddSigningCredential(Certificate.Get())
        .AddAspNetIdentity<ApplicationUser>()
        .AddConfigurationStore(builder =>
            builder.UseSqlServer(connectionString, options =>
                options.MigrationsAssembly(migrationsAssembly)))
        .AddOperationalStore(builder =>
            builder.UseSqlServer(connectionString, options =>
                options.MigrationsAssembly(migrationsAssembly)))
        .Services.AddTransient<IProfileService, ProfileService>();
}

När du har anropat services.AddIdentityServer metoden anropas ytterligare API:er för fluent för att konfigurera följande:

• Autentiseringsuppgifter som används för signering.
• API- och identitetsresurser som användare kan begära åtkomst till.
• Klienter som ansluter till begärandetoken.
• ASP.NET Core Identity.

Dricks

Läs in IdentityServer 4-konfigurationen dynamiskt. IdentityServer 4:s API:er gör det möjligt att konfigurera IdentityServer från en minnesintern lista över konfigurationsobjekt. I referensprogrammet eShopOnContainers hårdkodas dessa minnesinterna samlingar i programmet. I produktionsscenarier kan de dock läsas in dynamiskt från en konfigurationsfil eller från en databas.

Information om hur du konfigurerar IdentityServer att använda ASP.NET Core Identity finns i Använda ASP.NET Core Identity i IdentityServer-dokumentationen.

Konfigurera API-resurser

När du konfigurerar API-resurser AddInMemoryApiResources förväntar sig metoden en IEnumerable<ApiResource> samling. Följande kodexempel visar metoden som tillhandahåller den GetApis här samlingen i referensprogrammet eShopOnContainers:

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

Den här metoden anger att IdentityServer ska skydda order- och korg-API:erna. Därför krävs IdentityServer-hanterade åtkomsttoken vid anrop till dessa API:er. Mer information om typen finns ApiResource i API-resursen i dokumentationen för IdentityServer 4.

Konfigurera identitetsresurser

När du konfigurerar identitetsresurser AddInMemoryIdentityResources förväntar sig metoden en IEnumerable<IdentityResource> samling. Identitetsresurser är data som användar-ID, namn eller e-postadress. Varje identitetsresurs har ett unikt namn och godtyckliga anspråkstyper kan tilldelas till den, som inkluderas i identitetstoken för användaren. Följande kodexempel visar metoden som tillhandahåller den GetResources här samlingen i referensprogrammet eShopOnContainers:

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

OpenID-Anslut-specifikationen anger vissa standardidentitetsresurser. Minimikravet är att support tillhandahålls för att generera ett unikt ID för användare. Detta uppnås genom att exponera identitetsresursen IdentityResources.OpenId .

Kommentar

Klassen IdentityResources stöder alla omfång som definieras i OpenID Anslut-specifikationen (openid, e-post, profil, telefon och adress).

IdentityServer har också stöd för att definiera anpassade identitetsresurser. Mer information finns i Definiera anpassade identitetsresurser i IdentityServer-dokumentationen. Mer information om typen IdentityResource finns i Identitetsresurs i dokumentationen för IdentityServer 4.

Konfigurera klienter

Klienter är program som kan begära token från IdentityServer. Normalt måste följande inställningar definieras för varje klient som ett minimum:

• Ett unikt klient-ID.
• De tillåtna interaktionerna med tokentjänsten (kallas för beviljandetyp).
• Den plats där identitets- och åtkomsttoken skickas till (kallas för en omdirigerings-URI).
• En lista över resurser som klienten har åtkomst till (kallas omfång).

När du konfigurerar klienter AddInMemoryClients förväntar sig metoden en IEnumerable<Client> samling. I följande kodexempel visas konfigurationen för multiplattformsappen eShopOnContainers i metoden som tillhandahåller den GetClients här samlingen i referensprogrammet eShopOnContainers:

public static IEnumerable<Client> GetClients(Dictionary<string,string> clientsUrl)
{
    return new List<Client>
    {
        // Omitted for brevity
        new Client
        {
            ClientId = "xamarin",
            ClientName = "eShop Xamarin OpenId Client",
            AllowedGrantTypes = GrantTypes.Hybrid,
            ClientSecrets =
            {
                new Secret("secret".Sha256())
            },
            RedirectUris = { clientsUrl["Xamarin"] },
            RequireConsent = false,
            RequirePkce = true,
            PostLogoutRedirectUris = { $"{clientsUrl["Xamarin"]}/Account/Redirecting" },
            AllowedCorsOrigins = { "http://eshopxamarin" },
            AllowedScopes = new List<string>
            {
                IdentityServerConstants.StandardScopes.OpenId,
                IdentityServerConstants.StandardScopes.Profile,
                IdentityServerConstants.StandardScopes.OfflineAccess,
                "orders",
                "basket"
            },
            AllowOfflineAccess = true,
            AllowAccessTokensViaBrowser = true
        },
    };
}

Den här konfigurationen anger data för följande egenskaper:

Property	beskrivning
ClientId	Ett unikt ID för klienten.
ClientName	Klientens visningsnamn, som används för loggning och medgivandeskärmen.
AllowedGrantTypes	Anger hur en klient vill interagera med IdentityServer. Mer information finns i Konfigurera autentiseringsflödet.
ClientSecrets	Anger de autentiseringsuppgifter för klienthemligheter som används när token begärs från tokenslutpunkten.
RedirectUris	Anger de tillåtna URI:er som token eller auktoriseringskoder ska returneras till.
RequireConsent	Anger om en medgivandeskärm krävs.
RequirePkce	Anger om klienter som använder en auktoriseringskod måste skicka en bevisnyckel.
PostLogoutRedirectUris	Anger de tillåtna URI:er som ska omdirigeras till efter utloggning.
AllowedCorsOrigins	Anger klientens ursprung så att IdentityServer kan tillåta korsande anrop från ursprunget.
AllowedScopes	Anger de resurser som klienten har åtkomst till. Som standard har en klient ingen åtkomst till några resurser.
AllowOfflineAccess	Anger om klienten kan begära uppdateringstoken.

Konfigurera autentiseringsflödet

Autentiseringsflödet mellan en klient och IdentityServer kan konfigureras genom att ange beviljandetyperna Client.AllowedGrantTypes i egenskapen. Specifikationerna OpenID Anslut och OAuth 2.0 definierar flera autentiseringsflöden, inklusive:

Autentiseringsflöde	beskrivning
Implicit	Det här flödet är optimerat för webbläsarbaserade program och bör användas antingen för enbart användarautentisering eller autentiserings- och åtkomsttokenbegäranden. Alla token överförs via webbläsaren och därför tillåts inte avancerade funktioner som uppdateringstoken.
Auktoriseringskod	Det här flödet ger möjlighet att hämta token på en bakåtkanal, till skillnad från webbläsarens frontkanal, samtidigt som klientautentisering stöds.
Hybrid	Det här flödet är en kombination av de implicita och auktoriseringskod bevilja typerna. Identitetstoken överförs via webbläsarkanalen och innehåller det signerade protokollsvaret och andra artefakter, till exempel auktoriseringskoden. När svaret har verifierats ska backkanalen användas för att hämta åtkomst- och uppdateringstoken.

Dricks

Överväg att använda hybridautentiseringsflödet. Hybridautentiseringsflödet minimerar ett antal attacker som gäller för webbläsarkanalen och är det rekommenderade flödet för inbyggda program som vill hämta åtkomsttoken (och eventuellt uppdateringstoken).

Mer information om autentiseringsflöden finns i Bevilja typer i IdentityServer 4-dokumentationen.

Utföra autentisering

För att IdentityServer ska kunna utfärda token åt en användare måste användaren logga in på IdentityServer. IdentityServer tillhandahåller dock inte något användargränssnitt eller en databas för autentisering. I referensprogrammet eShopOnContainers används därför ASP.NET Core Identity för detta ändamål.

EShopOnContainers multiplattformsapp autentiserar med IdentityServer med hybridautentiseringsflödet, vilket visas i diagrammet nedan.

En inloggningsbegäran görs till <base endpoint>:5105/connect/authorize. Efter lyckad autentisering returnerar IdentityServer ett autentiseringssvar som innehåller en auktoriseringskod och en identitetstoken. Auktoriseringskoden skickas till <base endpoint>:5105/connect/token, som svarar med åtkomst, identitet och uppdateringstoken.

EShopOnContainers-appen för flera plattformar loggar ut från IdentityServer genom att skicka en begäran till <base endpoint>:5105/connect/endsession med ytterligare parametrar. Efter utloggningen svarar IdentityServer genom att skicka tillbaka en URI efter utloggningen till multiplattformsappen. Diagrammet nedan illustrerar den här processen.

I multiplattformsappen eShopOnContainers utförs kommunikationen med IdentityServer av IdentityService klassen som implementerar IIdentityService gränssnittet. Det här gränssnittet anger att implementeringsklassen måste innehålla CreateAuthorizationRequestmetoderna , CreateLogoutRequestoch GetTokenAsync .

Logga in

När användaren trycker LOGIN på knappen på LoginViewSignInCommand körs i LoginViewModel -klassen, som i sin tur kör SignInAsync metoden. Följande kodexempel visar den här metoden:

private async Task SignInAsync()
{
    await IsBusyFor(
        async () =>
        {
            LoginUrl = _identityService.CreateAuthorizationRequest();

            IsValid = true;
            IsLogin = true;
        });
}

Den här metoden anropar CreateAuthorizationRequest metoden i IdentityService klassen, som du ser i följande kodexempel:

public string CreateAuthorizationRequest()
{
    // Create URI to authorization endpoint
    var authorizeRequest = new AuthorizeRequest(GlobalSetting.Instance.IdentityEndpoint);
    // Dictionary with values for the authorize request
    var dic = new Dictionary<string, string>();
    dic.Add("client_id", GlobalSetting.Instance.ClientId);
    dic.Add("client_secret", GlobalSetting.Instance.ClientSecret); 
    dic.Add("response_type", "code id_token");
    dic.Add("scope", "openid profile basket orders locations marketing offline_access");
    dic.Add("redirect_uri", GlobalSetting.Instance.IdentityCallback);
    dic.Add("nonce", Guid.NewGuid().ToString("N"));
    dic.Add("code_challenge", CreateCodeChallenge());
    dic.Add("code_challenge_method", "S256");
    // Add CSRF token to protect against cross-site request forgery attacks.
    var currentCSRFToken = Guid.NewGuid().ToString("N");
    dic.Add("state", currentCSRFToken);
    
    var authorizeUri = authorizeRequest.Create(dic); 
    return authorizeUri;
}

Den här metoden skapar URI:n för IdentityServers auktoriseringsslutpunkt med nödvändiga parametrar. Auktoriseringsslutpunkten finns på /connect/authorize port 5105 för basslutpunkten som exponeras som en användarinställning. Mer information om användarinställningar finns i Konfigurationshantering.

Kommentar

Angreppsytan för eShopOnContainers multiplattformsapp minskar genom att implementera PKCE-tillägget (Proof Key for Code Exchange) till OAuth. PKCE skyddar auktoriseringskoden från att användas om den fångas upp. Detta uppnås genom att klienten genererar en hemlig kontrollant, vars hash skickas i auktoriseringsbegäran, och som visas ohashed när du löser in auktoriseringskoden. Mer information om PKCE finns i Proof Key for Code Exchange by OAuth Public Clients on the Internet Engineering Task Force web site (Bevisnyckel för kodutbyte av OAuth Public Clients ) på webbplatsen för Internet Engineering Task Force.

Den returnerade URI:n lagras i LoginUrl egenskapen för LoginViewModel klassen. När egenskapen IsLogin blir sann WebView blir in-i-objektet LoginView synligt. Data WebView binder dess Source egenskap till LoginUrl egenskapen LoginViewModel för klassen och en inloggningsbegäran till IdentityServer när LoginUrl egenskapen är inställd på IdentityServers auktoriseringsslutpunkt. När IdentityServer tar emot den här begäran och användaren inte autentiseras omdirigeras den WebView till den konfigurerade inloggningssidan som visas i bilden nedan.

När inloggningen är klar omdirigeras den WebView till en retur-URI. Det här WebView navigeringsfönstret gör NavigateAsync att metoden i LoginViewModel klassen körs, som du ser i följande kodexempel:

private async Task NavigateAsync(string url)
{
    var unescapedUrl = System.Net.WebUtility.UrlDecode(url);

    if (unescapedUrl.Equals(GlobalSetting.Instance.LogoutCallback, StringComparison.OrdinalIgnoreCase))
    {
        _settingsService.AuthAccessToken = string.Empty;
        _settingsService.AuthIdToken = string.Empty;
        IsLogin = false;
        LoginUrl = _identityService.CreateAuthorizationRequest();
    }
    else if (unescapedUrl.Contains(GlobalSetting.Instance.Callback, StringComparison.OrdinalIgnoreCase))
    {
        var authResponse = new AuthorizeResponse(url);
        if (!string.IsNullOrWhiteSpace(authResponse.Code))
        {
            var userToken = await _identityService.GetTokenAsync(authResponse.Code);
            string accessToken = userToken.AccessToken;

            if (!string.IsNullOrWhiteSpace(accessToken))
            {
                _settingsService.AuthAccessToken = accessToken;
                _settingsService.AuthIdToken = authResponse.IdentityToken;
                await NavigationService.NavigateToAsync("//Main/Catalog");
            }
        }
    }
}

Den här metoden parsar autentiseringssvaret i retur-URI:n och förutsatt att en giltig auktoriseringskod finns skickar den en begäran till IdentityServers tokenslutpunkt, skickar auktoriseringskoden, PKCE-hemlighetsverifieraren och andra obligatoriska parametrar. Tokenslutpunkten finns på /connect/token port 5105 för basslutpunkten som exponeras som en användarinställning. Mer information om användarinställningar finns i Konfigurationshantering).

Dricks

Verifiera returnerade URI:er. Även om multiplattformsappen eShopOnContainers inte verifierar retur-URI:n är det bästa sättet att verifiera att retur-URI:n refererar till en känd plats för att förhindra attacker med öppen omdirigering.

Om tokenslutpunkten tar emot en giltig auktoriseringskod och en PKCE-hemlig kontrollant svarar den med en åtkomsttoken, identitetstoken och uppdateringstoken. Åtkomsttoken (som tillåter åtkomst till API-resurser) och identitetstoken lagras som programinställningar och sidnavigering utförs. Därför är den övergripande effekten i eShopOnContainers multiplattformsapp följande: förutsatt att användarna kan autentisera med IdentityServer navigeras de till //Main/Catalog vägen, vilket är en TabbedPage som visar fliken CatalogView som den valda fliken.

Mer information om sidnavigering finns i Navigering. Information om hur WebView-navigering gör att en vymodellmetod körs finns i Anropa navigering med hjälp av beteenden. Information om programinställningar finns i Konfigurationshantering.

Kommentar

eShopOnContainers tillåter också en falsk inloggning när appen har konfigurerats för att använda mock-tjänster i SettingsView. I det här läget kommunicerar appen inte med IdentityServer, utan tillåter i stället att användaren loggar in med autentiseringsuppgifter.

Utloggning

När användaren trycker på LOG OUT knappen i ProfileViewLogoutCommand körs i ProfileViewModel -klassen, som kör LogoutAsync metoden. Den här metoden utför sidnavigering till LoginView sidan och skickar en LogoutParameter instans inställd på true som en parameter.

När en vy skapas och navigeras till InitializeAsync körs metoden för vyns associerade vymodell, som sedan kör Logout -metoden för LoginViewModel klassen, vilket visas i följande kodexempel:

private void Logout()
{
    var authIdToken = Settings.AuthIdToken;
    var logoutRequest = _identityService.CreateLogoutRequest(authIdToken);

    if (!string.IsNullOrEmpty(logoutRequest))
    {
        // Logout
        LoginUrl = logoutRequest;
    }
    
    // Omitted for brevity
}

Den här metoden anropar CreateLogoutRequest metoden i IdentityService klassen och skickar identitetstoken som hämtats från programinställningarna som en parameter. Mer information om programinställningar finns i Konfigurationshantering. Följande kodexempel visar CreateLogoutRequest metoden:

public string CreateLogoutRequest(string token)
{
    // Omitted for brevity

    var (endpoint, callback) =
        (GlobalSetting.Instance.LogoutEndpoint, GlobalSetting.Instance.LogoutCallback);

    return $"{endpoint}?id_token_hint={token}&post_logout_redirect_uri={callback}";
}

Den här metoden skapar URI:n till slutpunkten för IdentityServer-sessionen med nödvändiga parametrar. Slutpunkten för slutsessionen finns på /connect/endsession port 5105 för basslutpunkten som exponeras som en användarinställning.

Den returnerade URI:n lagras i LoginUrl egenskapen för LoginViewModel klassen. IsLogin Egenskapen är sann, WebView men i LoginView är synlig. Data WebView binder dess Source egenskap till LoginUrl egenskapen LoginViewModel för klassen, vilket gör en utloggningsbegäran till IdentityServer när LoginUrl egenskapen är inställd på IdentityServers slutpunkt för slutsessionen. Utloggning sker när IdentityServer tar emot den här begäran, förutsatt att användaren är inloggad. Autentisering spåras med en cookie som hanteras av mellanprogrammet för cookieautentisering från ASP.NET Core. Därför tar utloggning från IdentityServer bort autentiseringscookien och skickar en omdirigerings-URI efter utloggning tillbaka till klienten.

WebView Omdirigeras till omdirigerings-URI:n efter utloggningen i multiplattformsappen. Det här WebView navigeringsfönstret gör NavigateAsync att metoden i LoginViewModel klassen körs, vilket visas i följande kodexempel:

private async Task NavigateAsync(string url)
{
    var unescapedUrl = System.Net.WebUtility.UrlDecode(url);

    if (unescapedUrl.Equals(GlobalSetting.Instance.LogoutCallback, StringComparison.OrdinalIgnoreCase))
    {
        _settingsService.AuthAccessToken = string.Empty;
        _settingsService.AuthIdToken = string.Empty;
        IsLogin = false;
        LoginUrl = _identityService.CreateAuthorizationRequest();
    }
    
    // Omitted for brevity
}

Den här metoden rensar både identitetstoken och åtkomsttoken från programinställningarna. Den anger IsLogin egenskapen till false, vilket gör WebView att på LoginView sidan blir osynlig. Slutligen LoginUrl är egenskapen inställd på URI:n för IdentityServers auktoriseringsslutpunkt, med de obligatoriska parametrarna, som förberedelse för nästa gång användaren initierar en inloggning.

Mer information om sidnavigering finns i Navigering. Information om hur WebView navigering gör att en vymodellmetod körs finns i Anropa navigering med hjälp av beteenden. Information om programinställningar finns i Konfigurationshantering.

Kommentar

eShopOnContainers tillåter också en falsk utloggning när appen har konfigurerats för att använda mock-tjänster i SettingsView. I det här läget kommunicerar appen inte med IdentityServer och rensar i stället alla lagrade token från programinställningarna.

Auktorisering

Efter autentiseringen behöver ASP.NET Core-webb-API:er ofta auktorisera åtkomst, vilket gör att en tjänst kan göra API:er tillgängliga för vissa autentiserade användare men inte för alla.

Du kan begränsa åtkomsten till en ASP.NET Core-väg genom att tillämpa ett auktoriseringsattribut på en kontrollant eller åtgärd, vilket begränsar åtkomsten till kontrollanten eller åtgärden för autentiserade användare, enligt följande kodexempel:

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

Om en obehörig användare försöker komma åt en kontrollant eller åtgärd som har markerats med attributet Auktorisera returnerar API-ramverket en 401 (unauthorized) HTTP-statuskod.

Kommentar

Parametrar kan anges i attributet Auktorisera för att begränsa ett API till specifika användare. Mer information finns i ASP.NET Core Docs: Authorization (Auktorisering).

IdentityServer kan integreras i auktoriseringsarbetsflödet så att åtkomsttoken ger kontrollauktorisering. Den här metoden visas i diagrammet nedan.

Multiplattformsappen eShopOnContainers kommunicerar med identitetsmikrotjänsten och begär en åtkomsttoken som en del av autentiseringsprocessen. Åtkomsttoken vidarebefordras sedan till DE API:er som exponeras av mikrotjänsterna för beställning och korg som en del av åtkomstbegäranden. Åtkomsttoken innehåller information om klienten och användaren. API:er använder sedan den informationen för att auktorisera åtkomst till sina data. Information om hur du konfigurerar IdentityServer för att skydda API:er finns i Konfigurera API-resurser.

Konfigurera IdentityServer för att utföra auktorisering

För att kunna utföra auktorisering med IdentityServer måste dess mellanprogram för auktorisering läggas till i webbprogrammets HTTP-begärandepipeline. Mellanprogrammet läggs till i ConfigureAuth -metoden i webbprogrammets Startup -klass, som anropas från Configure metoden och visas i följande kodexempel från referensprogrammet eShopOnContainers:

protected virtual void ConfigureAuth(IApplicationBuilder app)
{
    var identityUrl = Configuration.GetValue<string>("IdentityUrl");
    app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions
    {
        Authority = identityUrl.ToString(),
        ScopeName = "basket",
        RequireHttpsMetadata = false,
    });
}

Den här metoden säkerställer att API:et endast kan nås med en giltig åtkomsttoken. Mellanprogrammet validerar den inkommande token för att säkerställa att den skickas från en betrodd utfärdare och verifierar att token är giltig för att användas med API:et som tar emot den. Därför returnerar surfning till beställnings- eller korgkontrollanten en 401 (unauthorized) HTTP-statuskod som anger att en åtkomsttoken krävs.

Kommentar

IdentityServers mellanprogram för auktorisering måste läggas till i webbprogrammets HTTP-begärandepipeline innan MVC läggs till med app.UseMvc() eller app.UseMvcWithDefaultRoute().

Göra åtkomstbegäranden till API:er

När du gör begäranden till beställnings- och varukorgsmikrotjänster måste åtkomsttoken som hämtades från IdentityServer under autentiseringsprocessen inkluderas i begäran, enligt följande kodexempel:

var authToken = Settings.AuthAccessToken;
Order = await _ordersService.GetOrderAsync(order.OrderNumber, authToken);

Åtkomsttoken lagras som en programinställning och hämtas från plattformsspecifik lagring och ingår i anropet till GetOrderAsync -metoden i OrderService klassen.

På samma sätt måste åtkomsttoken inkluderas när data skickas till ett IdentityServer-skyddat API, enligt följande kodexempel:

var authToken = Settings.AuthAccessToken;
await _basketService.UpdateBasketAsync(
    new CustomerBasket
    {
        BuyerId = userInfo.UserId, 
        Items = BasketItems.ToList()
    }, 
    authToken);

Åtkomsttoken hämtas från inställningarna och ingår i anropet till UpdateBasketAsync -metoden i BasketService klassen.

Klassen RequestProvider i multiplattformsappen eShopOnContainers använder HttpClient klassen för att göra begäranden till RESTful-API:erna som exponeras av referensprogrammet eShopOnContainers. När du gör begäranden till order- och korg-API:erna, som kräver auktorisering, måste en giltig åtkomsttoken inkluderas i begäran. Detta uppnås genom att lägga till åtkomsttoken i huvudena i HttpClient-instansen, vilket visas i följande kodexempel:

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

Egenskapen DefaultRequestHeadersHttpClient för klassen exponerar rubrikerna som skickas med varje begäran och åtkomsttoken läggs till i Authorization huvudet prefixet med strängen Bearer. När begäran skickas till ett RESTful-API extraheras och verifieras värdet Authorization för huvudet för att säkerställa att det skickas från en betrodd utfärdare och används för att avgöra om användaren har behörighet att anropa API:et som tar emot den.

Mer information om hur multiplattformsappen eShopOnContainers gör webbbegäranden finns i Komma åt fjärrdata.

Sammanfattning

Det finns många sätt att integrera autentisering och auktorisering i en .NET-app MAUI som kommunicerar med en ASP.NET webbapp. Multiplattformsappen eShopOnContainers utför autentisering och auktorisering med en containerbaserad identitetsmikrotjänst som använder IdentityServer 4. IdentityServer är ett öppen källkod OpenID-Anslut- och OAuth 2.0-ramverk för ASP.NET Core som integreras med ASP.NET Core Identity för att utföra ägartokenautentisering.

Multiplattformsappen begär säkerhetstoken från IdentityServer för att autentisera en användare eller komma åt en resurs. Vid åtkomst till en resurs måste en åtkomsttoken inkluderas i begäran till API:er som kräver auktorisering. IdentityServers mellanprogram validerar inkommande åtkomsttoken för att säkerställa att de skickas från en betrodd utfärdare och att de är giltiga för att användas med API:et som tar emot dem.