Uwierzytelnianie i autoryzacja

Uwierzytelnianie to proces uzyskiwania poświadczeń identyfikacji, takich jak nazwa i hasło od użytkownika oraz weryfikowanie tych poświadczeń względem urzędu. Jednostka, która przesłała poświadczenia, jest traktowana jako uwierzytelniona tożsamość, jeśli poświadczenia są prawidłowe. Po ustanowieniu tożsamości proces autoryzacji określa, czy ta tożsamość ma dostęp do danego zasobu.

Istnieje wiele metod integrowania uwierzytelniania i autoryzacji z aplikacją .NET MAUI , która komunikuje się z aplikacją internetową ASP.NET, w tym przy użyciu ASP.NET Core Identity, zewnętrznych dostawców uwierzytelniania, takich jak Microsoft, Google, Facebook lub Twitter, oraz oprogramowanie pośredniczące uwierzytelniania. Wieloplatformowa aplikacja eShop wykonuje uwierzytelnianie i autoryzację za pomocą konteneryzowanej mikrousługi tożsamości korzystającej z maszyny wirtualnej IdentityServer. Aplikacja żąda tokenów zabezpieczających z serwera IdentityServer w celu uwierzytelnienia użytkownika lub uzyskania dostępu do zasobu. Aby maszyna wirtualna IdentityServer wystawiała tokeny w imieniu użytkownika, użytkownik musi zalogować się do serwera IdentityServer. Jednak usługa IdentityServer nie udostępnia interfejsu użytkownika ani bazy danych na potrzeby uwierzytelniania. W związku z tym w aplikacji referencyjnej eShop ASP.NET Core Identity jest używana w tym celu.

Uwierzytelnianie

Uwierzytelnianie jest wymagane, gdy aplikacja musi znać tożsamość bieżącego użytkownika. Podstawowym mechanizmem identyfikacji użytkowników ASP.NET Core jest system członkostwa w ASP.NET Core Identity, który przechowuje informacje o użytkowniku w magazynie danych skonfigurowanym przez dewelopera. Zazwyczaj ten magazyn danych będzie magazynem EntityFramework, chociaż magazyny niestandardowe lub pakiety innych firm mogą służyć do przechowywania informacji o tożsamości w usłudze Azure Storage, DocumentDB lub w innych lokalizacjach.

W przypadku scenariuszy uwierzytelniania korzystających z magazynu danych użytkownika lokalnego i utrwalania informacji o tożsamości między żądaniami za pośrednictwem plików cookie (co jest typowe w aplikacjach internetowych ASP.NET), ASP.NET Core Identity jest odpowiednim rozwiązaniem. Jednak pliki cookie nie zawsze są naturalnym sposobem utrwalania i przesyłania danych. Na przykład aplikacja internetowa ASP.NET Core, która uwidacznia punkty końcowe RESTful, do których uzyskuje się dostęp z aplikacji, zwykle musi używać uwierzytelniania tokenu elementu nośnego, ponieważ pliki cookie nie mogą być używane w tym scenariuszu. Tokeny elementu nośnego można jednak łatwo pobrać i dołączyć do nagłówka autoryzacji żądań internetowych wysyłanych z aplikacji.

Wystawianie tokenów elementu nośnego przy użyciu serwera IdentityServer

IdentityServer to platforma open source OpenID Connect i OAuth 2.0 dla platformy ASP.NET Core, która może być używana w wielu scenariuszach uwierzytelniania i autoryzacji, w tym wystawiania tokenów zabezpieczających dla lokalnych użytkowników tożsamości podstawowej ASP.NET.

OpenID Connect to warstwa uwierzytelniania oparta na protokole OAuth 2.0. OAuth 2 to protokół, który umożliwia aplikacjom żądanie tokenów dostępu z usługi tokenu zabezpieczającego i używanie ich do komunikowania się z interfejsami API. Delegowanie zmniejsza złożoność zarówno aplikacji klienckich, jak i interfejsów API, ponieważ uwierzytelnianie i autoryzacja mogą być scentralizowane.

OpenID Connect i OAuth 2.0 łączą dwa podstawowe problemy z zabezpieczeniami uwierzytelniania i dostępu do interfejsu API, a IdentityServer jest implementacją tych protokołów.

W aplikacjach korzystających z bezpośredniej komunikacji typu klient-mikrousług, takiej jak aplikacja referencyjna eShop, można użyć dedykowanej mikrousługi uwierzytelniania działającej jako usługa tokenu zabezpieczającego (STS) do uwierzytelniania użytkowników, jak pokazano na poniższym diagramie. Aby uzyskać więcej informacji na temat bezpośredniej komunikacji między klientami i mikrousługami, zobacz Mikrousługi.

Wieloplatformowa aplikacja eShop komunikuje się z mikrousługą tożsamości, która używa klasy IdentityServer do przeprowadzania uwierzytelniania i kontroli dostępu dla interfejsów API. W związku z tym aplikacja wieloplatformowa żąda tokenów z serwera IdentityServer na potrzeby uwierzytelniania użytkownika lub uzyskiwania dostępu do zasobu:

• Uwierzytelnianie użytkowników za pomocą usługi IdentityServer jest osiągane przez wieloplatformową aplikację żądającą tokenu tożsamości reprezentującego wynik procesu uwierzytelniania. Co najmniej zawiera identyfikator użytkownika oraz informacje o tym, jak i kiedy użytkownik jest uwierzytelniony. Może również zawierać dodatkowe dane tożsamości.
• Uzyskiwanie dostępu do zasobu za pomocą klasy IdentityServer jest osiągane przez wieloplatformową aplikację żądającą tokenu dostępu , który umożliwia dostęp do zasobu interfejsu API. Klienci żądają tokenów dostępu i przekazują je do interfejsu API. Tokeny dostępu zawierają informacje o kliencie i użytkowniku, jeśli istnieje. Następnie interfejsy API używają tych informacji do autoryzowania dostępu do danych.

Dodawanie maszyny wirtualnej IdentityServer do aplikacji internetowej

Aby aplikacja internetowa ASP.NET Core mogła używać serwera IdentityServer, należy ją dodać do rozwiązania programu Visual Studio aplikacji internetowej. Aby uzyskać więcej informacji, zobacz Setup and Overview (Instalacja i omówienie ) w dokumentacji IdentityServer. Po dołączeniu serwera IdentityServer do rozwiązania programu Visual Studio aplikacji internetowej należy ją dodać do potoku przetwarzania żądań HTTP, aby obsługiwać żądania do punktów końcowych OpenID Connect i OAuth 2.0. Jest to skonfigurowane w Identity.API Program.cs projektu, jak pokazano w poniższym przykładzie kodu:

...

app.UseIdentityServer();

Kolejność ma znaczenie w potoku przetwarzania żądań HTTP aplikacji internetowej. W związku z tym należy dodać serwer IdentityServer do potoku przed strukturą interfejsu użytkownika, która implementuje ekran logowania.

Konfigurowanie maszyny wirtualnej IdentityServer

Serwer IdentityServer jest skonfigurowany w Identity.API Program.cs projektu przez wywołanie AddIdentityServer metody , jak pokazano w poniższym przykładzie kodu z aplikacji referencyjnej eShop:

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

Po wywołaniu services.AddIdentityServer metody wywoływane są dodatkowe płynne interfejsy API w celu skonfigurowania następujących elementów:

• Poświadczenia używane do podpisywania.
• Zasoby interfejsu API i tożsamości, do których użytkownicy mogą żądać dostępu.
• Klienci, którzy będą łączyć się z tokenami żądań.
• ASP.NET tożsamość podstawowa.

Aby uzyskać informacje na temat konfigurowania maszyny wirtualnej IdentityServer do używania ASP.NET Core Identity, zobacz Using ASP.NET Core Identity (Używanie tożsamości podstawowej ASP.NET) w dokumentacji IdentityServer.

Konfigurowanie zasobów interfejsu API

Podczas konfigurowania zasobów AddInMemoryApiResources interfejsu API metoda oczekuje IEnumerable<ApiResource> kolekcji. Poniższy przykład kodu przedstawia metodę GetApis , która udostępnia tę kolekcję w aplikacji referencyjnej eShop:

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"),
    };
}

Ta metoda określa, że usługa IdentityServer powinna chronić interfejsy API zamówień i koszyka. W związku z tym tokeny dostępu zarządzane przez serwer IdentityServer będą wymagane podczas wykonywania wywołań do tych interfejsów API. Aby uzyskać więcej informacji na temat typu, zobacz ApiResource interfejsu API w dokumentacji IdentityServer.

Konfigurowanie zasobów tożsamości

Podczas konfigurowania zasobów AddInMemoryIdentityResources tożsamości metoda oczekuje IEnumerable<IdentityResource> kolekcji. Zasoby tożsamości to dane, takie jak identyfikator użytkownika, nazwa lub adres e-mail. Każdy zasób tożsamości ma unikatową nazwę i do niego można przypisać dowolne typy oświadczeń, które zostaną uwzględnione w tokenie tożsamości użytkownika. Poniższy przykład kodu przedstawia metodę GetResources , która udostępnia tę kolekcję w aplikacji referencyjnej eShop:

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

Specyfikacja openID Connect określa niektóre standardowe zasoby tożsamości. Minimalnym wymaganiem jest zapewnienie obsługi emitowania unikatowego identyfikatora dla użytkowników. Jest to osiągane przez uwidacznianie IdentityResources.OpenId zasobu tożsamości.

Usługa IdentityServer obsługuje również definiowanie niestandardowych zasobów tożsamości. Aby uzyskać więcej informacji, zobacz Definiowanie niestandardowych zasobów tożsamości w dokumentacji identityServer. Aby uzyskać więcej informacji na temat typu IdentityResource, zobacz Identity Resource (Zasób tożsamości) w dokumentacji IdentityServer.

Konfigurowanie klientów

Klienci to aplikacje, które mogą żądać tokenów z maszyny wirtualnej IdentityServer. Zazwyczaj dla każdego klienta należy zdefiniować następujące ustawienia co najmniej:

• Unikatowy identyfikator klienta.
• Dozwolone interakcje z usługą tokenu (nazywane typem przyznawania).
• Lokalizacja, w której są wysyłane tożsamości i tokeny dostępu (nazywane identyfikatorem URI przekierowania).
• Lista zasobów, do których klient ma dostęp (znany jako zakresy).

Podczas konfigurowania klientów AddInMemoryClients metoda oczekuje IEnumerable<Client> kolekcji. Poniższy przykład kodu przedstawia konfigurację aplikacji wieloplatformowej eShop w GetClients metodzie, która udostępnia tę kolekcję w aplikacji referencyjnej eShop:

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
        }
    };
}

Ta konfiguracja określa dane dla następujących właściwości:

Konfigurowanie przepływu uwierzytelniania

Przepływ uwierzytelniania między klientem a serwerem IdentityServer można skonfigurować, określając typy dotacji we Client.AllowedGrantTypes właściwości . Specyfikacje openID Connect i OAuth 2.0 definiują kilka przepływów uwierzytelniania, w tym:

Aby uzyskać więcej informacji na temat przepływów uwierzytelniania, zobacz Grant Types (Udzielanie typów ) w dokumentacji IdentityServer.

Przeprowadzanie uwierzytelniania

Aby maszyna wirtualna IdentityServer wystawiała tokeny w imieniu użytkownika, użytkownik musi zalogować się do serwera IdentityServer. Jednak usługa IdentityServer nie udostępnia interfejsu użytkownika ani bazy danych na potrzeby uwierzytelniania. W związku z tym w aplikacji referencyjnej eShop ASP.NET Core Identity jest używana w tym celu.

Wieloplatformowa aplikacja eShop uwierzytelnia się za pomocą maszyny wirtualnej IdentityServer przy użyciu przepływu uwierzytelniania hybrydowego, który przedstawiono na poniższym diagramie.

Żądanie logowania jest wykonywane na adres <base endpoint>:5105/connect/authorize. Po pomyślnym uwierzytelnieniu usługa IdentityServer zwraca odpowiedź uwierzytelniania zawierającą kod autoryzacji i token tożsamości. Kod autoryzacji jest wysyłany do <base endpoint>:5105/connect/tokenprogramu , który odpowiada za pomocą tokenów dostępu, tożsamości i odświeżania.

Wieloplatformowa aplikacja eShop wy loguje się z maszyny wirtualnej IdentityServer, wysyłając żądanie do <base endpoint>:5105/connect/endsession z dodatkowymi parametrami. Po wylogowaniu usługa IdentityServer odpowiada, wysyłając identyfikator URI przekierowania po wylogowaniu z powrotem do aplikacji wieloplatformowej. Na poniższym diagramie przedstawiono ten proces.

W aplikacji wieloplatformowej eShop komunikacja z usługą IdentityServer jest wykonywana przez klasę IdentityService , która implementuje IIdentityService interfejs. Ten interfejs określa, że klasa implementowania musi dostarczać SignInAsyncmetody , SignOutAsynci GetUserInfoAsyncGetAuthTokenAsync .

Logowanie

Gdy użytkownik naciągnie LOGIN przycisk w LoginViewklasie , SignInCommand zostanie wykonany element w LoginViewModel klasie , który z kolei wykonuje metodę SignInAsync . Poniższy przykład kodu przedstawia tę metodę:

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

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

Ta metoda wywołuje metodę SignInAsync w IdentityService klasie, jak pokazano w poniższym przykładzie kodu:

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;
}

Narzędzie IdentityService korzysta z dostarczonego OidcClientIdentityModel.OidcClient pakietu NuGet. Ten klient wyświetla widok sieci Web uwierzytelniania użytkownikowi w aplikacji i przechwytuje wynik uwierzytelniania. Klient łączy się z identyfikatorem URI punktu końcowego autoryzacji IdentityServer z wymaganymi parametrami. Punkt końcowy autoryzacji znajduje się na /connect/authorize porcie 5105 podstawowego punktu końcowego uwidocznionego jako ustawienie użytkownika. Aby uzyskać więcej informacji na temat ustawień użytkownika, zobacz Zarządzanie konfiguracją.

Jeśli punkt końcowy tokenu otrzymuje prawidłowe informacje o uwierzytelnianiu, kodzie autoryzacji i weryfikatorze wpisów tajnych PKCE, odpowiada za pomocą tokenu dostępu, tokenu tożsamości i tokenu odświeżania. Token dostępu (który umożliwia dostęp do zasobów interfejsu API) i token tożsamości są przechowywane jako ustawienia aplikacji, a nawigacja po stronie jest wykonywana. W związku z tym ogólny efekt w aplikacji wieloplatformowej eShop jest następujący: pod warunkiem, że użytkownicy mogą pomyślnie uwierzytelnić się za pomocą identityServer, są one kierowane do //Main/Catalog trasy, która jest TabbedPage wyświetlana CatalogView jako wybrana karta.

Aby uzyskać informacje na temat nawigacji między stronami, zobacz Nawigacja. Aby uzyskać informacje o tym, jak nawigacja w usłudze WebView powoduje wykonanie metody modelu widoku, zobacz Wywoływanie nawigacji przy użyciu zachowań. Aby uzyskać informacje o ustawieniach aplikacji, zobacz Zarządzanie konfiguracją.

Wylogowywanie

Gdy użytkownik naciągnie LOG OUT przycisk w ProfileViewklasie , LogoutCommand zostanie wykonany element w ProfileViewModel klasie , który wykonuje metodę LogoutAsync . Ta metoda wykonuje nawigację między stronami na LoginView stronie, przekazując Logout parametr zapytania ustawiony na truewartość .

Ten parametr jest obliczany w metodzie ApplyQueryAttributes . Logout Jeśli parametr jest obecny z wartościątrue, PerformLogoutAsync metoda LoginViewModel klasy jest wykonywana, co jest pokazane w poniższym przykładzie kodu:

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

    _settingsService.UseFakeLocation = false;

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

Ta metoda wywołuje metodę SignOutAsync w IdentityService klasie , która wywołuje OidcClient metodę na końcu sesji użytkownika i czyści wszystkie zapisane tokeny użytkownika. Aby uzyskać więcej informacji na temat ustawień aplikacji, zobacz Zarządzanie konfiguracją. Poniższy przykład kodu przedstawia metodę SignOutAsync :

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;
}

Ta metoda używa OidcClient klasy , aby wywołać identyfikator URI do punktu końcowego sesji serwera IdentityServer z wymaganymi parametrami. Punkt końcowy sesji znajduje się na /connect/endsession porcie 5105 podstawowego punktu końcowego uwidocznionego jako ustawienie użytkownika. Po pomyślnym wylogowaniu LoginView użytkownika zostanie wyświetlony użytkownikowi, a wszystkie zapisane informacje o użytkowniku zostaną wyczyszczone.

Aby uzyskać informacje na temat nawigacji między stronami, zobacz Nawigacja. Aby uzyskać informacje o tym, jak WebView nawigacja powoduje wykonanie metody modelu widoku, zobacz Wywoływanie nawigacji przy użyciu zachowań. Aby uzyskać informacje o ustawieniach aplikacji, zobacz Zarządzanie konfiguracją.

Autoryzacja

Po uwierzytelnieniu ASP.NET Core internetowych interfejsów API często muszą autoryzować dostęp, co umożliwia usłudze udostępnianie interfejsów API niektórym uwierzytelnionymi użytkownikom, ale nie wszystkim.

Ograniczenie dostępu do trasy ASP.NET Core można osiągnąć, stosując atrybut Authorize do kontrolera lub akcji, co ogranicza dostęp do kontrolera lub akcji dla uwierzytelnionych użytkowników, jak pokazano w poniższym przykładzie kodu:

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

Jeśli nieautoryzowany użytkownik próbuje uzyskać dostęp do kontrolera lub akcji oznaczonej atrybutem Autoryzuj, platforma interfejsu API zwraca 401 (unauthorized) kod stanu HTTP.

Serwer IdentityServer można zintegrować z przepływem pracy autoryzacji, aby tokeny dostępu zapewniały autoryzację kontroli. To podejście jest pokazane na poniższym diagramie.

Wieloplatformowa aplikacja eShop komunikuje się z mikrousługą tożsamości i żąda tokenu dostępu w ramach procesu uwierzytelniania. Token dostępu jest następnie przekazywany do interfejsów API udostępnianych przez mikrousługi zamawiania i koszyka w ramach żądań dostępu. Tokeny dostępu zawierają informacje o kliencie i użytkowniku. Następnie interfejsy API używają tych informacji do autoryzowania dostępu do danych. Aby uzyskać informacje o sposobie konfigurowania serwera IdentityServer w celu ochrony interfejsów API, zobacz Konfigurowanie zasobów interfejsu API.

Konfigurowanie serwera IdentityServer w celu wykonania autoryzacji

Aby wykonać autoryzację za pomocą serwera IdentityServer, jego oprogramowanie pośredniczące autoryzacji musi zostać dodane do potoku żądania HTTP aplikacji internetowej. Oprogramowanie pośredniczące jest dodawane w AddDefaultAuthentication metodzie rozszerzenia, która jest wywoływana z AddApplicationServices metody w Program klasie i jest pokazana w poniższym przykładzie kodu z aplikacji referencyjnej eShop:

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;
}

Ta metoda zapewnia dostęp do interfejsu API tylko przy użyciu prawidłowego tokenu dostępu. Oprogramowanie pośredniczące weryfikuje token przychodzący, aby upewnić się, że jest wysyłany z zaufanego wystawcy i sprawdza, czy token jest prawidłowy do użycia z interfejsem API, który go odbiera. W związku z tym przejście do kontrolera zamówienia lub koszyka zwróci 401 (unauthorized) kod stanu HTTP wskazujący, że token dostępu jest wymagany.

Wykonywanie żądań dostępu do interfejsów API

Podczas wprowadzania żądań do mikrousług zamówień i koszyka token dostępu uzyskany z serwera IdentityServer podczas procesu uwierzytelniania musi zostać uwzględniony w żądaniu, jak pokazano w poniższym przykładzie kodu:

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

Token dostępu jest przechowywany wraz z implementacją IIdentityService i można go pobrać przy użyciu GetAuthTokenAsync metody .

Podobnie token dostępu musi zostać uwzględniony podczas wysyłania danych do chronionego interfejsu API IdentityServer, jak pokazano w poniższym przykładzie kodu:

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

Token dostępu jest pobierany z IIdentityService elementu i dołączony do wywołania ClearBasketAsync metody w BasketService klasie .

Klasa RequestProvider w aplikacji wieloplatformowej eShop używa HttpClient klasy , aby wysyłać żądania do interfejsów API RESTful uwidocznionych przez aplikację referencyjną eShop. Podczas wprowadzania żądań do interfejsów API zamawiania i koszyka, które wymagają autoryzacji, należy dołączyć prawidłowy token dostępu do żądania. Jest to osiągane przez dodanie tokenu dostępu do nagłówków wystąpienia httpClient, jak pokazano w poniższym przykładzie kodu:

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

Właściwość DefaultRequestHeadersHttpClient klasy uwidacznia nagłówki wysyłane za pomocą każdego żądania, a token dostępu jest dodawany do Authorization nagłówka poprzedzonego ciągiem Bearer. Po wysłaniu żądania do interfejsu API RESTful wartość Authorization nagłówka jest wyodrębniona i weryfikowana, aby upewnić się, że jest wysyłana z zaufanego wystawcy i używana do określenia, czy użytkownik ma uprawnienia do wywoływania interfejsu API, który go odbiera.

Aby uzyskać więcej informacji na temat sposobu, w jaki aplikacja wieloplatformowa eShop wysyła żądania internetowe, zobacz Uzyskiwanie dostępu do danych zdalnych.

Podsumowanie

Istnieje wiele metod integrowania uwierzytelniania i autoryzacji z aplikacją platformy .NET MAUI , która komunikuje się z aplikacją internetową ASP.NET. Wieloplatformowa aplikacja eShop wykonuje uwierzytelnianie i autoryzację za pomocą konteneryzowanej mikrousługi tożsamości korzystającej z maszyny wirtualnej IdentityServer. IdentityServer to platforma open source OpenID Connect i OAuth 2.0 dla platformy ASP.NET Core, która integruje się z tożsamością ASP.NET Core w celu przeprowadzania uwierzytelniania tokenu elementu nośnego.

Aplikacja wieloplatformowa żąda tokenów zabezpieczających z serwera IdentityServer w celu uwierzytelnienia użytkownika lub uzyskania dostępu do zasobu. Podczas uzyskiwania dostępu do zasobu token dostępu musi być uwzględniony w żądaniu do interfejsów API, które wymagają autoryzacji. Oprogramowanie pośredniczące identityServer weryfikuje przychodzące tokeny dostępu, aby upewnić się, że są wysyłane z zaufanego wystawcy i że są prawidłowe do użycia z interfejsem API, który je odbiera.