Aracılığıyla paylaş


Kimlik Doğrulama ve Yetkilendirme

Not

Bu e-Kitap 2017 baharında yayımlanmıştır ve o zamandan beri güncelleştirilmemiştir. Kitapta değerli kalan çok şey var, ancak bazı malzemeler güncelliğini yitirmiş.

Kimlik doğrulaması, bir kullanıcıdan ad ve parola gibi kimlik bilgilerini alma ve bu kimlik bilgilerini bir yetkiliye karşı doğrulama işlemidir. Kimlik bilgileri geçerliyse, kimlik bilgilerini gönderen varlık kimliği doğrulanmış kimlik olarak kabul edilir. Kimlik doğrulandıktan sonra, yetkilendirme işlemi bu kimliğin belirli bir kaynağa erişimi olup olmadığını belirler.

ASP.NET Core Identity, Microsoft, Google, Facebook veya Twitter gibi dış kimlik doğrulama sağlayıcıları ve kimlik doğrulama ara yazılımı gibi ASP.NET MVC web uygulamasıyla iletişim kuran bir uygulamayla kimlik doğrulaması ve yetkilendirmeyi Xamarin.Forms tümleştirmeye yönelik birçok yaklaşım vardır. eShopOnContainers mobil uygulaması, IdentityServer 4 kullanan kapsayıcılı kimlik mikro hizmetiyle kimlik doğrulaması ve yetkilendirme gerçekleştirir. Mobil uygulama, bir kullanıcının kimliğini doğrulamak veya bir kaynağa erişmek için IdentityServer'dan güvenlik belirteçleri ister. IdentityServer'ın bir kullanıcı adına belirteçler vermesi için kullanıcının IdentityServer'da oturum açması gerekir. Ancak, IdentityServer kimlik doğrulaması için bir kullanıcı arabirimi veya veritabanı sağlamaz. Bu nedenle, eShopOnContainers başvuru uygulamasında ASP.NET Core Identity bu amaçla kullanılır.

Kimlik Doğrulaması

Bir uygulamanın geçerli kullanıcının kimliğini bilmesi gerektiğinde kimlik doğrulaması gerekir. ASP.NET Core'un kullanıcıları tanımlamaya yönelik birincil mekanizması, kullanıcı bilgilerini geliştirici tarafından yapılandırılan bir veri deposunda depolayan ASP.NET Core Identity üyelik sistemidir. Genellikle bu veri deposu bir EntityFramework deposu olur, ancak özel depolar veya üçüncü taraf paketler Kimlik bilgilerini Azure depolama, Azure Cosmos DB veya diğer konumlarda depolamak için kullanılabilir.

Yerel kullanıcı veri deposu kullanan ve tanımlama bilgileri aracılığıyla istekler arasında kimlik bilgilerini kalıcı hale getiren (ASP.NET MVC web uygulamalarında olduğu gibi) kimlik doğrulama senaryoları için ASP.NET Temel Kimlik uygun bir çözümdür. Ancak tanımlama bilgileri her zaman verileri kalıcı hale ve iletim için doğal bir araç değildir. Örneğin, bir mobil uygulamadan erişilen RESTful uç noktalarını kullanıma sunan bir ASP.NET Core web uygulamasının genellikle taşıyıcı belirteç kimlik doğrulamasını kullanması gerekir çünkü tanımlama bilgileri bu senaryoda kullanılamaz. Ancak taşıyıcı belirteçler kolayca alınabilir ve mobil uygulamadan yapılan web isteklerinin yetkilendirme üst bilgisine eklenebilir.

IdentityServer 4 kullanarak Taşıyıcı Belirteçleri Verme

IdentityServer 4, ASP.NET Core için açık kaynak bir OpenID Bağlan ve OAuth 2.0 çerçevesidir ve yerel ASP.NET Core Identity kullanıcıları için güvenlik belirteçleri verme gibi birçok kimlik doğrulama ve yetkilendirme senaryosu için kullanılabilir.

Not

OpenID Bağlan ve OAuth 2.0 çok benzerdir ve farklı sorumluluklara sahiptir.

OpenID Bağlan, OAuth 2.0 protokolünün üzerindeki bir kimlik doğrulama katmanıdır. OAuth 2, uygulamaların bir güvenlik belirteci hizmetinden erişim belirteçleri istemesine ve bunları API'lerle iletişim kurmak için kullanmasına olanak tanıyan bir protokoldür. Kimlik doğrulaması ve yetkilendirme merkezileştirilebildiği için bu temsilci seçme hem istemci uygulamalarında hem de API'lerde karmaşıklığı azaltır.

OpenID Bağlan ve OAuth 2.0 birleşimi, kimlik doğrulaması ve API erişimiyle ilgili iki temel güvenlik kaygısını birleştirir ve IdentityServer 4 bu protokollerin bir uygulamasıdır.

eShopOnContainers başvuru uygulaması gibi doğrudan istemciden mikro hizmete iletişimi kullanan uygulamalarda, Şekil 9-1'de gösterildiği gibi, kullanıcıların kimliğini doğrulamak için Güvenlik Belirteci Hizmeti (STS) olarak hareket eden ayrılmış bir kimlik doğrulama mikro hizmeti kullanılabilir. Doğrudan istemciden mikro hizmete iletişim hakkında daha fazla bilgi için bkz . İstemci ve Mikro Hizmetler Arasındaki İletişim.

Authentication by a dedicated authentication microservice

Şekil 9-1: Ayrılmış bir kimlik doğrulama mikro hizmeti tarafından kimlik doğrulaması

eShopOnContainers mobil uygulaması kimlik doğrulaması gerçekleştirmek için IdentityServer 4'i ve API'ler için erişim denetimini kullanan kimlik mikro hizmetiyle iletişim kurar. Bu nedenle, mobil uygulama bir kullanıcının kimliğini doğrulamak veya bir kaynağa erişmek için IdentityServer'dan belirteçler ister:

  • IdentityServer ile kullanıcıların kimlik doğrulaması, kimlik doğrulama işleminin sonucunu temsil eden bir kimlik belirteci isteyen mobil uygulama tarafından gerçekleştirilir. En azından, kullanıcı için bir tanımlayıcı ve kullanıcının kimliğinin nasıl ve ne zaman doğrulanmış olduğu hakkında bilgi içerir. Ayrıca ek kimlik verileri de içerebilir.
  • IdentityServer ile bir kaynağa erişim, bir API kaynağına erişim sağlayan erişim belirteci isteyen mobil uygulama tarafından sağlanır. İstemciler erişim belirteçleri talep eder ve bunları API'ye iletir. Erişim belirteçleri, istemci ve kullanıcı (varsa) hakkında bilgi içerir. API'ler daha sonra verilerine erişim yetkisi vermek için bu bilgileri kullanır.

Not

İstemcinin belirteç istemeden önce IdentityServer'a kaydedilmesi gerekir.

Web Uygulamasına IdentityServer Ekleme

ASP.NET Core web uygulamasının IdentityServer 4 kullanabilmesi için web uygulamasının Visual Studio çözümüne eklenmesi gerekir. Daha fazla bilgi için IdentityServer belgelerinde Genel Bakış'a bakın.

IdentityServer web uygulamasının Visual Studio çözümüne eklendikten sonra, OpenID Bağlan ve OAuth 2.0 uç noktalarına istek sunabilmesi için web uygulamasının HTTP isteği işleme işlem hattına eklenmelidir. Bu, aşağıdaki kod örneğinde Configure gösterildiği gibi web uygulamasının Startup sınıfındaki yönteminde elde edilir:

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

Sipariş, web uygulamasının HTTP isteği işleme işlem hattında önemlidir. Bu nedenle, identityserver oturum açma ekranını uygulayan ui çerçevesi önce işlem hattına eklenmelidir.

IdentityServer'ın Yapılandırılması

IdentityServer, eShopOnContainers başvuru uygulamasından aşağıdaki kod örneğinde gösterildiği gibi yöntemini çağırarak services.AddIdentityServer web uygulamasının Startup sınıfında yönteminde yapılandırılmalıdırConfigureServices:

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

yöntemi çağrıldıktan services.AddIdentityServer sonra, aşağıdakileri yapılandırmak için ek akıcı API'ler çağrılır:

  • İmzalama için kullanılan kimlik bilgileri.
  • Kullanıcıların erişim isteyebileceği API ve kimlik kaynakları.
  • İstek belirteçlerine bağlanacak istemciler.
  • ASP.NET Çekirdek Kimliği.

İpucu

IdentityServer 4 yapılandırmasını dinamik olarak yükleyin. IdentityServer 4'ün API'leri, yapılandırma nesnelerinin bellek içi listesinden IdentityServer'ın yapılandırılmasına olanak tanır. eShopOnContainers başvuru uygulamasında, bu bellek içi koleksiyonlar uygulamaya sabit kodlanmıştır. Ancak üretim senaryolarında bunlar bir yapılandırma dosyasından veya veritabanından dinamik olarak yüklenebilir.

IdentityServer'ı ASP.NET Çekirdek Kimliği kullanacak şekilde yapılandırma hakkında bilgi için, IdentityServer belgelerindeki ASP.NET Çekirdek Kimliği Kullanma bölümüne bakın.

API Kaynaklarını Yapılandırma

API kaynaklarını AddInMemoryApiResources yapılandırırken yöntemi bir IEnumerable<ApiResource> koleksiyon bekler. Aşağıdaki kod örneği, eShopOnContainers başvuru uygulamasında bu koleksiyonu sağlayan yöntemi gösterir GetApis :

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

Bu yöntem, IdentityServer'ın siparişleri ve sepet API'lerini koruması gerektiğini belirtir. Bu nedenle, bu API'lere çağrı yapılırken IdentityServer yönetilen erişim belirteçleri gerekir. Türü hakkında ApiResource daha fazla bilgi için IdentityServer 4 belgelerindeki API Kaynağı'na bakın.

Kimlik Kaynaklarını Yapılandırma

Kimlik kaynaklarını AddInMemoryIdentityResources yapılandırırken yöntemi bir IEnumerable<IdentityResource> koleksiyon bekler. Kimlik kaynakları kullanıcı kimliği, ad veya e-posta adresi gibi verilerdir. Her kimlik kaynağının benzersiz bir adı vardır ve bu kaynağa rastgele talep türleri atanabilir ve bu türler kullanıcının kimlik belirtecine eklenir. Aşağıdaki kod örneği, eShopOnContainers başvuru uygulamasında bu koleksiyonu sağlayan yöntemi gösterir GetResources :

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

OpenID Bağlan belirtimi bazı standart kimlik kaynaklarını belirtir. Minimum gereksinim, kullanıcılar için benzersiz bir kimlik yayma desteği sağlanmasıdır. Bu, kimlik kaynağının açığa çıkartılmasıyla IdentityResources.OpenId elde edilir.

Not

sınıfı OpenID IdentityResources Bağlan belirtiminde (openid, e-posta, profil, telefon ve adres) tanımlanan tüm kapsamları destekler.

IdentityServer ayrıca özel kimlik kaynaklarının tanımlanmasını da destekler. Tür hakkında IdentityResource daha fazla bilgi için IdentityServer 4 belgelerindeki Kimlik Kaynağı'na bakın.

İstemcileri Yapılandırma

İstemciler, IdentityServer'dan belirteç isteyebilen uygulamalardır. Genellikle, her istemci için aşağıdaki ayarların en az olarak tanımlanması gerekir:

  • Benzersiz bir istemci kimliği.
  • Belirteç hizmetiyle izin verilen etkileşimler (verme türü olarak bilinir).
  • Kimlik ve erişim belirteçlerinin gönderildiği konum (yeniden yönlendirme URI'si olarak bilinir).
  • İstemcinin erişimine izin verilen kaynakların listesi (kapsamlar olarak bilinir).

İstemcileri AddInMemoryClients yapılandırırken yöntemi bir IEnumerable<Client> koleksiyon bekler. Aşağıdaki kod örneği, eShopOnContainers başvuru uygulamasında bu koleksiyonu sağlayan yöntemde eShopOnContainers mobil uygulamasının GetClients yapılandırmasını gösterir:

public static IEnumerable<Client> GetClients(Dictionary<string,string> clientsUrl)
{
    return new List<Client>
    {
        ...
        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
        },
        ...
    };
}

Bu yapılandırma aşağıdaki özellikler için verileri belirtir:

  • ClientId: İstemci için benzersiz bir kimlik.
  • ClientName: Günlüğe kaydetme ve onay ekranı için kullanılan istemci görünen adı.
  • AllowedGrantTypes: İstemcinin IdentityServer ile nasıl etkileşime geçmek istediğini belirtir. Daha fazla bilgi için bkz . Kimlik Doğrulama Akışını Yapılandırma.
  • ClientSecrets: Belirteç uç noktasından belirteç istenirken kullanılan istemci gizli kimlik bilgilerini belirtir.
  • RedirectUris: Belirteçlerin veya yetkilendirme kodlarının döndürüleceği izin verilen URI'leri belirtir.
  • RequireConsent: Onay ekranının gerekli olup olmadığını belirtir.
  • RequirePkce: Yetkilendirme kodu kullanan istemcilerin bir yazım denetleme anahtarı göndermesi gerekip gerekmediğini belirtir.
  • PostLogoutRedirectUris: Oturumu kapatıldıktan sonra yeniden yönlendirilecek izin verilen URI'leri belirtir.
  • AllowedCorsOrigins: IdentityServer'ın kaynaktan gelen çıkış noktaları arası çağrılara izin verebilmesi için istemcinin kaynağını belirtir.
  • AllowedScopes: İstemcinin erişimi olan kaynakları belirtir. Varsayılan olarak, istemcinin hiçbir kaynağa erişimi yoktur.
  • AllowOfflineAccess: İstemcinin yenileme belirteçleri isteyip isteyemeyeceğini belirtir.

Kimlik Doğrulama Akışını Yapılandırma

İstemci ile IdentityServer arasındaki kimlik doğrulama akışı, özelliğindeki Client.AllowedGrantTypes izin türleri belirtilerek yapılandırılabilir. OpenID Bağlan ve OAuth 2.0 belirtimleri, aşağıdakiler gibi bir dizi kimlik doğrulama akışını tanımlar:

  • Örtülü. Bu akış tarayıcı tabanlı uygulamalar için iyileştirilmiştir ve yalnızca kullanıcı kimlik doğrulaması veya kimlik doğrulaması ve erişim belirteci istekleri için kullanılmalıdır. Tüm belirteçler tarayıcı üzerinden iletilir ve bu nedenle yenileme belirteçleri gibi gelişmiş özelliklere izin verilmez.
  • Yetkilendirme kodu. Bu akış, tarayıcı ön kanalı yerine arka kanaldaki belirteçleri alma olanağı sağlarken istemci kimlik doğrulamasını da destekler.
  • Karma. Bu akış, örtük ve yetkilendirme kodu verme türlerinin bir bileşimidir. Kimlik belirteci tarayıcı kanalı üzerinden iletilir ve yetkilendirme kodu gibi diğer yapıtlarla birlikte imzalı protokol yanıtını içerir. Yanıt başarıyla doğruladıktan sonra, erişim ve yenileme belirtecini almak için arka kanal kullanılmalıdır.

İpucu

Karma kimlik doğrulama akışını kullanın. Karma kimlik doğrulama akışı, tarayıcı kanalına uygulanan bir dizi saldırıyı azaltır ve erişim belirteçlerini (ve muhtemelen belirteçleri yenilemek) isteyen yerel uygulamalar için önerilen akıştır.

Kimlik doğrulama akışları hakkında daha fazla bilgi için IdentityServer 4 belgelerindeki Tür Verme bölümüne bakın.

Kimlik Doğrulaması Gerçekleştirme

IdentityServer'ın bir kullanıcı adına belirteçler vermesi için kullanıcının IdentityServer'da oturum açması gerekir. Ancak, IdentityServer kimlik doğrulaması için bir kullanıcı arabirimi veya veritabanı sağlamaz. Bu nedenle, eShopOnContainers başvuru uygulamasında ASP.NET Core Identity bu amaçla kullanılır.

eShopOnContainers mobil uygulaması, Şekil 9-2'de gösterilen karma kimlik doğrulama akışıyla IdentityServer ile kimlik doğrulaması yapar.

High-level overview of the sign-in process

Şekil 9-2: Oturum açma işlemine üst düzey genel bakış

adresine bir oturum açma isteği yapılır <base endpoint>:5105/connect/authorize. Kimlik doğrulaması başarılı bir şekilde tamamlandıktan sonra IdentityServer, yetkilendirme kodu ve kimlik belirteci içeren bir kimlik doğrulama yanıtı döndürür. Yetkilendirme kodu daha sonra erişim, kimlik ve yenileme belirteçleriyle yanıt veren öğesine gönderilir <base endpoint>:5105/connect/token.

eShopOnContainers mobil uygulaması, adresine ek parametrelerle bir istek <base endpoint>:5105/connect/endsessiongöndererek IdentityServer oturumunu kapatıyor. Oturum kapatma gerçekleştikten sonra IdentityServer, oturumu kapatma sonrası yeniden yönlendirme URI'sini mobil uygulamaya geri göndererek yanıt verir. Şekil 9-3'de bu işlem gösterilmektedir.

High-level overview of the sign-out process

Şekil 9-3: Oturumu kapatma işlemine üst düzey genel bakış

eShopOnContainers mobil uygulamasında IdentityServer ile iletişim, arabirimini uygulayan IIdentityService sınıf tarafından IdentityService gerçekleştirilir. Bu arabirim, uygulayan sınıfın , CreateLogoutRequestve GetTokenAsync yöntemleri sağlaması CreateAuthorizationRequestgerektiğini belirtir.

Oturum açma

Kullanıcı üzerindeki LoginViewLOGIN düğmesine dokunduğunda LoginViewModel sınıfı yürütülür ve bu da yöntemini yürütürSignInAsync.SignInCommand Aşağıdaki kod örneği bu yöntemi gösterir:

private async Task SignInAsync()  
{  
    ...  
    LoginUrl = _identityService.CreateAuthorizationRequest();  
    IsLogin = true;  
    ...  
}

Bu yöntem, aşağıdaki kod örneğinde IdentityService gösterilen sınıfında yöntemini çağırırCreateAuthorizationRequest:

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

Bu yöntem, gerekli parametrelerle IdentityServer yetkilendirme uç noktası için URI'yi oluşturur. Yetkilendirme uç noktası, kullanıcı ayarı olarak kullanıma sunulan temel uç noktanın 5105 numaralı bağlantı noktasındadır /connect/authorize . Kullanıcı ayarları hakkında daha fazla bilgi için bkz . Yapılandırma Yönetimi.

Not

eShopOnContainers mobil uygulamasının saldırı yüzeyi, OAuth'a Kod Değişimi için Proof Key (PKCE) uzantısı uygulanarak azaltılır. PKCE, ele geçirilirse yetkilendirme kodunun kullanılmasını engeller. Bu, istemcinin bir gizli dizi doğrulayıcı oluşturması, bir karması yetkilendirme isteğinde geçirilir ve yetkilendirme kodu kullanıldığında bu karmanın karşılanmamış olarak sunulmasıyla elde edilir. PKCE hakkında daha fazla bilgi için bkz . Internet Engineering Task Force web sitesindeki OAuth Ortak İstemcileri Tarafından Kod Değişimi için Yazım Denetleme Anahtarı.

Döndürülen URI sınıfın LoginUrl özelliğinde LoginViewModel depolanır. özelliğine dönüştüğünde IsLoginWebViewtrueiçindeki LoginView görünür hale gelir. VerilerWebView, özelliğini sınıfın LoginUrlLoginViewModel özelliğine bağlar Source ve bu nedenle özellik IdentityServer'ın yetkilendirme uç noktasına ayarlandığında IdentityServer'a LoginUrl oturum açma isteğinde bulunur. IdentityServer bu isteği aldığında ve kullanıcının kimliği doğrulanmamışsa , WebView Şekil 9-4'te gösterilen yapılandırılmış oturum açma sayfasına yönlendirilir.

Login page displayed by the WebView

Şekil 9-4: WebView tarafından görüntülenen oturum açma sayfası

Oturum açma işlemi tamamlandıktan sonra, WebView dönüş URI'sine yönlendirilir. Bu WebView gezinti, aşağıdaki kod örneğinde LoginViewModel gösterilen sınıfındaki yönteminin yürütülmesine neden NavigateAsync olur:

private async Task NavigateAsync(string url)  
{  
    ...  
    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))  
        {  
            Settings.AuthAccessToken = accessToken;  
            Settings.AuthIdToken = authResponse.IdentityToken;  

            await NavigationService.NavigateToAsync<MainViewModel>();  
            await NavigationService.RemoveLastFromBackStackAsync();  
        }  
    }  
    ...  
}

Bu yöntem, dönüş URI'sinde yer alan kimlik doğrulama yanıtını ayrıştırarak geçerli bir yetkilendirme kodunun mevcut olması koşuluyla kimlik doğrulama kodunu, PKCE gizli dizi doğrulayıcısını ve diğer gerekli parametreleri geçirerek IdentityServer'ın belirteç uç noktasına bir istekte bulunur. Belirteç uç noktası, kullanıcı ayarı olarak kullanıma sunulan temel uç noktanın 5105 numaralı bağlantı noktasındadır /connect/token . Kullanıcı ayarları hakkında daha fazla bilgi için bkz . Yapılandırma Yönetimi.

İpucu

Dönüş URI'lerini doğrulayın. eShopOnContainers mobil uygulaması dönüş URI'sini doğrulamasa da, en iyi yöntem dönüş URI'sinin açık yeniden yönlendirme saldırılarını önlemek için bilinen bir konuma başvurduğunu doğrulamaktır.

Belirteç uç noktası geçerli bir yetkilendirme kodu ve PKCE gizli dizi doğrulayıcısı alırsa erişim belirteci, kimlik belirteci ve yenileme belirteci ile yanıt verir. Erişim belirteci (API kaynaklarına erişime izin verir) ve kimlik belirteci daha sonra uygulama ayarları olarak depolanır ve sayfa gezintisi gerçekleştirilir. Bu nedenle, eShopOnContainers mobil uygulamasındaki genel etki şudur: Kullanıcıların IdentityServer ile başarılı bir şekilde kimlik doğrulaması yapabilmeleri koşuluyla, öğesini seçili sekmesi olarak görüntüleyen sayfaya MainViewTabbedPageCatalogView gider.

Sayfa gezintisi hakkında bilgi için bkz . Gezinti. Gezintinin bir görünüm modeli yönteminin yürütülmesine nasıl WebView neden olduğu hakkında bilgi için bkz . Davranışlar kullanarak Gezintiyi Çağırma. Uygulama ayarları hakkında bilgi için bkz . Yapılandırma Yönetimi.

Not

eShopOnContainers, uygulama içinde SettingsViewsahte hizmetleri kullanacak şekilde yapılandırıldığında sahte oturum açmaya da izin verir. Bu modda, uygulama IdentityServer ile iletişim kurmaz, bunun yerine kullanıcının herhangi bir kimlik bilgilerini kullanarak oturum açmasına izin verir.

Oturumu kapatma

Kullanıcı içindeki LOG OUT düğmesine dokunduğundaProfileViewLogoutCommand, sınıfındaki ProfileViewModel komutu yürütülür ve bu da yöntemini yürütürLogoutAsync. Bu yöntem, parametre olarak ayarlanmış bir LogoutParameter örneği geçirerek sayfaya true sayfa gezintisi LoginView gerçekleştirir. Sayfa gezintisi sırasında parametreleri geçirme hakkında daha fazla bilgi için bkz . Gezinti Sırasında Parametreleri Geçirme.

Bir görünüm oluşturulduğunda ve öğesine gidildiğinde, InitializeAsync görünümün ilişkili görünüm modelinin yöntemi yürütülür ve bu yöntem aşağıdaki kod örneğinde gösterilen sınıfın LoginViewModel yöntemini yürütürLogout:

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

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

Bu yöntem, uygulama ayarlarından CreateLogoutRequestIdentityService alınan kimlik belirtecini parametre olarak geçirerek sınıfında yöntemini çağırır. Uygulama ayarları hakkında daha fazla bilgi için bkz . Yapılandırma Yönetimi. Aşağıdaki kod örneği yöntemini gösterir CreateLogoutRequest :

public string CreateLogoutRequest(string token)  
{  
    ...  
    return string.Format("{0}?id_token_hint={1}&post_logout_redirect_uri={2}",   
        GlobalSetting.Instance.LogoutEndpoint,  
        token,  
        GlobalSetting.Instance.LogoutCallback);  
}

Bu yöntem, gerekli parametrelerle IdentityServer'ın bitiş oturumu uç noktası için URI'yi oluşturur. Son oturum uç noktası, kullanıcı ayarı olarak sunulan temel uç noktanın 5105 numaralı bağlantı noktasındadır /connect/endsession . Kullanıcı ayarları hakkında daha fazla bilgi için bkz . Yapılandırma Yönetimi.

Döndürülen URI sınıfın LoginUrl özelliğinde LoginViewModel depolanır. IsLogin özelliği olsa trueWebView da içindeki LoginView görünür. VerilerWebView, özelliğini sınıfın LoginUrlLoginViewModel özelliğine bağlar Source ve bu nedenle özellik IdentityServer'ın son oturum uç noktasına ayarlandığında IdentityServer'a LoginUrl bir oturum kapatma isteği gönderir. IdentityServer bu isteği aldığında, kullanıcının oturum açmış olması koşuluyla oturum kapatma gerçekleşir. Kimlik doğrulaması, ASP.NET Core'dan tanımlama bilgisi kimlik doğrulaması ara yazılımı tarafından yönetilen bir tanımlama bilgisi ile izlenir. Bu nedenle, IdentityServer oturumunu kapatarak kimlik doğrulama tanımlama bilgisini kaldırır ve oturum kapatma sonrası yeniden yönlendirme URI'sini istemciye geri gönderir.

Mobil uygulamada, WebView oturumu kapatma sonrası yeniden yönlendirme URI'sine yönlendirilir. Bu WebView gezinti, aşağıdaki kod örneğinde LoginViewModel gösterilen sınıfındaki yönteminin yürütülmesine neden NavigateAsync olur:

private async Task NavigateAsync(string url)  
{  
    ...  
    Settings.AuthAccessToken = string.Empty;  
    Settings.AuthIdToken = string.Empty;  
    IsLogin = false;  
    LoginUrl = _identityService.CreateAuthorizationRequest();  
    ...  
}

Bu yöntem, uygulama ayarlarından hem kimlik belirtecini hem de erişim belirtecini temizler ve özelliğini falseolarak ayarlar IsLogin ve bu da sayfadaki öğesinin WebViewLoginView görünmez olmasına neden olur. Son olarak özellik, LoginUrl kullanıcının bir sonraki oturum açma işlemine hazırlık olarak gerekli parametrelerle IdentityServer yetkilendirme uç noktasının URI'sine ayarlanır.

Sayfa gezintisi hakkında bilgi için bkz . Gezinti. Gezintinin bir görünüm modeli yönteminin yürütülmesine nasıl WebView neden olduğu hakkında bilgi için bkz . Davranışlar kullanarak Gezintiyi Çağırma. Uygulama ayarları hakkında bilgi için bkz . Yapılandırma Yönetimi.

Not

eShopOnContainers, uygulama Ayarlar View'da sahte hizmetleri kullanacak şekilde yapılandırıldığında da sahte oturum kapatmaya izin verir. Bu modda, uygulama IdentityServer ile iletişim kurmaz ve bunun yerine uygulama ayarlarından depolanan belirteçleri temizler.

Yetkilendirme

Kimlik doğrulamasının ardından, ASP.NET Core web API'lerinin genellikle erişimi yetkilendirmesi gerekir ve bu da hizmetin API'leri bazı kimliği doğrulanmış kullanıcılar için kullanılabilir hale getirmesine izin verir, ancak herkes tarafından kullanılamaz.

ASP.NET Core MVC yoluna erişimi kısıtlamak, aşağıdaki kod örneğinde gösterildiği gibi denetleyiciye veya eyleme erişimi kimliği doğrulanmış kullanıcılarla sınırlayan bir Denetleyiciye veya eyleme Yetkilendir özniteliği uygulanarak elde edilebilir:

[Authorize]  
public class BasketController : Controller  
{  
    ...  
}

Yetkisiz bir kullanıcı, özniteliğiyle Authorize işaretlenmiş bir denetleyiciye veya eyleme erişmeye çalışırsa, MVC çerçevesi bir 401 (yetkisiz) HTTP durum kodu döndürür.

Not

Bir API'yi belirli kullanıcılarla Authorize kısıtlamak için öznitelikte parametreler belirtilebilir. Daha fazla bilgi için bkz . Yetkilendirme.

IdentityServer, erişim belirteçlerinin denetim yetkilendirmesi sağlaması için yetkilendirme iş akışıyla tümleştirilebilir. Bu yaklaşım Şekil 9-5'te gösterilmiştir.

Authorization by access token

Şekil 9-5: Erişim belirteciyle yetkilendirme

eShopOnContainers mobil uygulaması kimlik mikro hizmetiyle iletişim kurar ve kimlik doğrulama işleminin bir parçası olarak bir erişim belirteci istemektedir. Daha sonra erişim belirteci, erişim isteklerinin bir parçası olarak sipariş ve sepet mikro hizmetleri tarafından kullanıma sunulan API'lere iletilir. Erişim belirteçleri, istemci ve kullanıcı hakkında bilgi içerir. API'ler daha sonra verilerine erişim yetkisi vermek için bu bilgileri kullanır. API'leri korumak için IdentityServer'ı yapılandırma hakkında bilgi için bkz . API Kaynaklarını Yapılandırma.

IdentityServer'ı Yetkilendirme Gerçekleştirecek Şekilde Yapılandırma

IdentityServer ile yetkilendirme gerçekleştirmek için yetkilendirme ara yazılımının web uygulamasının HTTP istek işlem hattına eklenmesi gerekir. Ara yazılım, web uygulamasının ConfigureAuthStartup sınıfında yöntemine eklenir ve yönteminden Configure çağrılır ve eShopOnContainers başvuru uygulamasından aşağıdaki kod örneğinde gösterilmiştir:

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

Bu yöntem, API'ye yalnızca geçerli bir erişim belirteci ile erişilmesini sağlar. Ara yazılım, güvenilir bir verenden gönderildiğinden emin olmak için gelen belirteci doğrular ve belirtecin bunu alan API ile kullanılmak üzere geçerli olduğunu doğrular. Bu nedenle, sıralama veya sepet denetleyicisine göz atmak, erişim belirtecinin gerekli olduğunu belirten bir 401 (yetkisiz) HTTP durum kodu döndürür.

Not

veya app.UseMvcWithDefaultRoute()ile app.UseMvc() MVC eklemeden önce IdentityServer yetkilendirme ara yazılımının web uygulamasının HTTP istek işlem hattına eklenmesi gerekir.

API'lere Erişim İstekleri Yapma

Sipariş ve sepet mikro hizmetleri için istekte bulunurken, kimlik doğrulama işlemi sırasında IdentityServer'dan alınan erişim belirteci, aşağıdaki kod örneğinde gösterildiği gibi isteğe dahil edilmelidir:

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

Erişim belirteci bir uygulama ayarı olarak depolanır ve platforma özgü depolama alanından alınır ve sınıfındaki yöntemine OrderService yapılan çağrıya GetOrderAsync dahil edilir.

Benzer şekilde, erişim belirteci aşağıdaki kod örneğinde gösterildiği gibi IdentityServer korumalı API'ye veri gönderirken eklenmelidir:

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

Erişim belirteci platforma özgü depolama alanından alınır ve sınıfındaki yöntemine UpdateBasketAsync yapılan çağrıya BasketService dahil edilir.

RequestProvider eShopOnContainers mobil uygulamasındaki sınıfı, eShopOnContainers başvuru uygulaması tarafından kullanıma sunulan RESTful API'lerine istekte bulunmak için sınıfını kullanırHttpClient. Yetkilendirme gerektiren sıralama ve sepet API'lerine istekte bulunurken, isteğe geçerli bir erişim belirteci eklenmelidir. Bu, aşağıdaki kod örneğinde gösterildiği gibi erişim belirtecini HttpClient örneğin üst bilgilerine ekleyerek elde edilir:

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

DefaultRequestHeaders sınıfının özelliğiHttpClient, her istekle birlikte gönderilen üst bilgileri kullanıma sunar ve erişim belirteci dizesiyle Bearerönekli üst bilgisine Authorization eklenir. İstek bir RESTful API'sine gönderildiğinde, üst bilginin değeri Authorization ayıklanır ve güvenilir bir verenden gönderildiğinden emin olmak için doğrulanır ve kullanıcının bunu alan API'yi çağırma izni olup olmadığını belirlemek için kullanılır.

eShopOnContainers mobil uygulamasının web isteklerini nasıl yaptığı hakkında daha fazla bilgi için bkz . Uzak Verilere Erişme.

Özet

Kimlik doğrulaması ve yetkilendirmeyi ASP.NET MVC web uygulamasıyla iletişim kuran bir Xamarin.Forms uygulamayla tümleştirmeye yönelik birçok yaklaşım vardır. eShopOnContainers mobil uygulaması, IdentityServer 4 kullanan kapsayıcılı kimlik mikro hizmetiyle kimlik doğrulaması ve yetkilendirme gerçekleştirir. IdentityServer, taşıyıcı belirteç kimlik doğrulaması gerçekleştirmek için ASP.NET Core Identity ile tümleşen ASP.NET Core için açık kaynak bir OpenID Bağlan ve OAuth 2.0 çerçevesidir.

Mobil uygulama, bir kullanıcının kimliğini doğrulamak veya bir kaynağa erişmek için IdentityServer'dan güvenlik belirteçleri ister. Bir kaynağa erişirken, yetkilendirme gerektiren API'lere yönelik isteğe bir erişim belirteci eklenmelidir. IdentityServer'ın ara yazılımı, güvenilir bir verenden gönderildiklerinden ve bunları alan API ile kullanılmak için geçerli olduklarından emin olmak için gelen erişim belirteçlerini doğrular.