<\/div>\n

Merhaba,<\/p>\n

$\"IdentityServer4$ <\/a>

Temsili Client Credentials diyagram\u0131…<\/p><\/div>\n

IdentityServer4 Yaz\u0131 Serisi<\/a>nin bu \u00fc\u00e7\u00fcnc\u00fc makalesinde Client Credential yetki tipi ile gerekli konfig\u00fcrasyonlar e\u015fli\u011finde IdentityServer4 uygulamas\u0131 geli\u015ftirecek ve aya\u011fa kald\u0131raca\u011f\u0131z. Client Credential; machine to machine kimliklendirme dedi\u011fimiz iki uygulama aras\u0131ndaki etkile\u015fime istinaden kullan\u0131lan bir ak\u0131\u015f t\u00fcr\u00fcd\u00fcr. Kullan\u0131c\u0131(User) kimlik do\u011frulamas\u0131ndan ziyade sadece client’\u0131n do\u011frulanmas\u0131 \u00f6nemliyse(authorization) tercih edilmektedir.<\/p>\n

Client Credentials, resource server’lar\u0131 korumak i\u00e7in IdentityServer4’\u0131 kullanman\u0131n en temel senaryosunu sunar.<\/em><\/p><\/blockquote>\n
Client Credentials Stratejisi<\/h3>\n $\"IdentityServer4$ <\/a>Client Credentials yetki tipinde Auth Server sadece client’lara, sistemde tan\u0131ml\u0131 olan API’lara(resources) eri\u015fim yetkisi vermektedir. Yandaki g\u00f6r\u00fcnt\u00fcde de g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere sistemdeki t\u00fcm client’lar(her ne kadar tekil \u00f6rneklendirilmi\u015f olsada) Auth Server taraf\u0131ndan tan\u0131mlanmaktad\u0131r. Bu tan\u0131mlamada t\u00fcm client’lara, birbirlerinden ay\u0131rmak ve o anki iste\u011fin hangi client’tan geldi\u011fini anlayabilmek i\u00e7in Auth Server taraf\u0131ndan Client ID<\/em><\/strong> ve Client Secret<\/em><\/strong> de\u011ferleri atanmaktad\u0131r. Bu de\u011ferleri kullanarak Auth Server’dan token elde eden client, ilgili token’\u0131 kullanarak API’lara istekte bulunacakt\u0131r. API’lar ise gelen token’\u0131 kontrol edecek ve sistemdeki Auth Server taraf\u0131ndan da\u011f\u0131t\u0131lm\u0131\u015f oldu\u011funu anlad\u0131\u011f\u0131 taktirde onaylayarak veri eri\u015fimine izin verecektir…<\/p>\n
Client Credentials, kullan\u0131c\u0131dan ziyade client’\u0131n do\u011frulanmas\u0131n\u0131 baz al\u0131r.<\/em><\/p><\/blockquote>\n
Client Credentials, client do\u011frulanmas\u0131 temelli oldu\u011fundan dolay\u0131 kullan\u0131c\u0131 ile ilgili i\u015flemlerin(\u00fcyelik sistemi, kullan\u0131c\u0131 do\u011frulama vs.) olmad\u0131\u011f\u0131 durumlarda tercih edilmektedir. Client’\u0131n do\u011frulanmas\u0131, client ile API’lar aras\u0131ndaki etkile\u015fimin\/ileti\u015fimin\/konu\u015fturman\u0131n bir gere\u011fi olaca\u011f\u0131 i\u00e7in makalemizin ilk paragraflar\u0131nda de\u011finildi\u011fi gibi machine to machine tarifiyle nitelendirilmektedir. Dolay\u0131s\u0131yla iki uygulaman\u0131n(client – API) kendi aralar\u0131nda ileti\u015fim i\u00e7in yetkilendirmesi durumunu Client Credentials ile ger\u00e7ekle\u015ftirmekteyiz. Peki hocam, user ile ilgili yetkilendirme durumunu nas\u0131l ger\u00e7ekle\u015ftirmekteyiz?<\/strong><\/em> \u015feklinde sorunuzu duyar gibiyim… User ve daha nice durumlarla ilgili i\u015flemlerde kullanaca\u011f\u0131m\u0131z izin tiplerini yaz\u0131 serimizin devam\u0131ndaki makalelerde tek tek ele alaca\u011f\u0131m\u0131z\u0131 bildiririm. O y\u00fczden acele etmeksizin konumuzda kalmaya \u00f6zen g\u00f6sterelim \ud83d\ude42<\/p>\n
Client Credentials’da kullan\u0131c\u0131 \u00fcyelik sistemi vs. gibi kullan\u0131c\u0131ya dair operasyonlar bulunmamaktad\u0131r. Sistemdeki yap\u0131lar\u0131n(client – API) birbirleriyle haberle\u015fmesine dayal\u0131 bir yetkilendirme y\u00f6ntemidir.<\/em><\/p><\/blockquote>\n
IdentityServer4 – Client Credentials \u0130le Machine to Machine Kimliklendirme \u00d6rne\u011fi<\/h3>\n
Evet, i\u00e7eri\u011fimizin bu noktas\u0131ndan itibaren art\u0131k bir IdentityServer4 uygulamas\u0131 aya\u011fa kald\u0131racak ve Client Credentials yetki tipiyle machine to machine yetkilendirmenin nas\u0131l yap\u0131ld\u0131\u011f\u0131n\u0131 t\u00fcm detaylar\u0131yla pratikte inceleyece\u011fiz.<\/p>\n
Tabi her prati\u011fin k\u00fc\u00e7\u00fckte olsa bir teorisi vard\u0131r. \u015eu ana kadar att\u0131\u011f\u0131m\u0131z teorik temellerin d\u0131\u015f\u0131nda IdentityServer4 yap\u0131lanmas\u0131n\u0131n da temel kavramlar\u0131 olan “API Resource” ve “API Scope” terimlerini tan\u0131mlamadan uygulamaya giri\u015fmek, pratikte performans\u0131m\u0131z\u0131 olumsuz etkileyecektir. <\/p>\n
\n
API Resource<\/strong>
\nAuth Server uygulamas\u0131n\u0131n sorumlu oldu\u011fu resource’leri yani API’leri ifade eder.\n<\/li>\n
API Scope<\/strong>
\n\u00dcretilecek token de\u011ferinin API \u00fczerindeki yetki alan\u0131n\u0131 ifade eder. Client, Auth Service \u00fczerinden elde etti\u011fi token’da hangi scope de\u011ferlerine sahipse ancak o scope de\u011ferlerine sahip olan API’lara istekte bulunabilir.\n<\/li>\n<\/ul>\n
Bu a\u00e7\u0131klamalardan sonra art\u0131k uygulamam\u0131za ba\u015flayabiliriz. Uygulamam\u0131z bir banka senaryosu \u00fczerinden i\u015flevsellik g\u00f6sterecektir. IdentityServer4 uygulamas\u0131 i\u00e7in ‘AuthServer’ isimli bir API projesi, Resource Servers i\u00e7in ise ‘GarantiAPI’ ve ‘HalkBankAPI’ isimli iki adet API projesi olu\u015fturaca\u011f\u0131z. S\u00fcre\u00e7te client olarak Postman’i kullanaca\u011f\u0131z.<\/p>\n
dotnet new webapi --name AuthServer Port : 1000<\/span><\/strong><\/code> \ndotnet new webapi --name GarantiAPI Port : 2000<\/span><\/strong><\/code> \ndotnet new webapi --name HalkBankAPI Port : 3000<\/span><\/strong><\/code><\/p>\n
Hadi kodlayal\u0131m…<\/p>\n
\n1. Ad\u0131m – IdentityServer4(AuthServer) Uygulamas\u0131n\u0131 Geli\u015ftirme<\/strong> \nHer\u015feyden \u00f6nce uygulamam\u0131zda IdentityServer4 konfig\u00fcrasyonunu ger\u00e7ekle\u015ftirebilmek i\u00e7in ilk olarak projeye IdentityServer4<\/a> k\u00fct\u00fcphanesinin y\u00fcklenmesi gerekmektedir.<\/p>\n\ndotnet add package IdentityServer4 --version 4.1.1<\/code>\n<\/div>\n\u0130lgili k\u00fct\u00fcphaneyi y\u00fckledikten sonra art\u0131k IdentityServer4 konfig\u00fcrasyonuna ge\u00e7ebiliriz.<\/p>\n IdentityServer4; hangi client’\u0131n, hangi yetkilerle(scope), hangi API’lere(resource) eri\u015fmek istedi\u011fini bilmek ister. Bu y\u00fczden temel konfig\u00fcrasyon olarak bu olgular\u0131 tan\u0131tmam\u0131z gerekmektedir. Bunun i\u00e7in ‘AuthServer’ uygulamas\u0131nda ‘Config’ ad\u0131nda bir class tasarlayarak gerekli konfig\u00fcrasyonu i\u00e7erisinde ger\u00e7ekle\u015ftirebiliriz.(\u0130nternetteki t\u00fcm kaynaklarda benzer \u00e7al\u0131\u015fma ger\u00e7ekle\u015ftirildi\u011fi i\u00e7in gelene\u011fe riayet ediyor, bizde Config dosyas\u0131 \u00fczerinden \u00e7al\u0131\u015fmam\u0131z\u0131 ger\u00e7ekle\u015ftiriyoruz \ud83d\ude42 )<\/span><\/p>\n\r\n static public class Config\r\n {\r\n #region Scopes\r\n \/\/API'larda kullan\u0131lacak izinleri tan\u0131mlar.\r\n public static IEnumerable<ApiScope> GetApiScopes()\r\n {\r\n return new List<ApiScope>\r\n {\r\n new ApiScope("Garanti.Write","Garanti bankas\u0131 yazma izni"),\r\n new ApiScope("Garanti.Read","Garanti bankas\u0131 okuma izni"),\r\n new ApiScope("HalkBank.Write","HalkBank bankas\u0131 yazma izni"),\r\n new ApiScope("HalkBank.Read","HalkBank bankas\u0131 okuma izni"),\r\n };\r\n }\r\n #endregion\r\n #region Resources\r\n \/\/API'lar tan\u0131mlan\u0131r.\r\n public static IEnumerable<ApiResource> GetApiResources()\r\n {\r\n return new List<ApiResource>\r\n {\r\n new ApiResource("Garanti"){ Scopes = { "Garanti.Write", "Garanti.Read" } },\r\n new ApiResource("HalkBank"){ Scopes = { "HalkBank.Write", "HalkBank.Read" } }\r\n };\r\n }\r\n #endregion\r\n #region Clients\r\n \/\/API'lar\u0131 kullanacak client'lar tan\u0131mlan\u0131r.\r\n public static IEnumerable<Client> GetClients()\r\n {\r\n return new List<Client>\r\n {\r\n new Client\r\n {\r\n ClientId = "GarantiBankasi",\r\n ClientName = "GarantiBankasi",\r\n ClientSecrets = { new Secret("garanti".Sha256()) },\r\n AllowedGrantTypes = { GrantType.ClientCredentials },\r\n AllowedScopes = { "Garanti.Write", "Garanti.Read" }\r\n },\r\n new Client\r\n {\r\n ClientId = "HalkBankasi",\r\n ClientName = "HalkBankasi",\r\n ClientSecrets = { new Secret("halkbank".Sha256()) },\r\n AllowedGrantTypes = { GrantType.ClientCredentials },\r\n AllowedScopes = { "HalkBank.Write", "HalkBank.Read" }\r\n }\r\n };\r\n }\r\n #endregion\r\n }\r\n<\/pre>\nYukar\u0131daki kaynak koddaki tan\u0131mlanan metotlar\u0131 s\u0131ras\u0131yla ele alal\u0131m; 5.<\/strong><\/em> sat\u0131rdaki ‘GetApiScopes’ metodu i\u00e7erisinde API’lar da kullan\u0131lacak olan yetkileri bar\u0131nd\u0131rmaktad\u0131r. 18.<\/strong><\/em> sat\u0131rdaki ‘GetApiResources’ metodu ise sistemdeki API’lar\u0131 tan\u0131mlamakta ve dikkat ederseniz yetki alanlar\u0131 ‘Scopes’ propertysi ile verilmektedir. 29.<\/strong><\/em> sat\u0131rda ise API’lar\u0131 t\u00fcketecek olan client’lar tan\u0131mlanmaktad\u0131r. Her bir client’\u0131n ‘CliendId’ ve ‘ClientName’ de\u011feri verilmekte ve bununla birlikte ‘ClientSecrets’a verilen de\u011fer ‘Sha256’ ile \u015fifrelenerek set edilmektedir. ‘AllowedGrantTypes’ propertysi ile bu client’lar\u0131n yetki tipinin ne oldu\u011fu bildirilmekte ve ‘AllowedScopes’ ile de yetkileri bildirilmektedir.<\/p>\n Konfig\u00fcrasyon ayarlar\u0131 bu \u015fekilde tasarland\u0131ktan sonra uygulamaya dahil edilmesi gerekmektedir. Bunun i\u00e7in ‘Startup.cs’ dosyas\u0131 \u00fczerindeki ‘ConfigureServices’ metodu i\u00e7erisinde a\u015fa\u011f\u0131daki \u00e7al\u0131\u015fman\u0131n yap\u0131lmas\u0131 gerekmektedir.<\/p>\n\r\n public class Startup\r\n {\r\n public void ConfigureServices(IServiceCollection services)\r\n {\r\n services.AddIdentityServer()\r\n .AddInMemoryApiResources(Config.GetApiResources())\r\n .AddInMemoryApiScopes(Config.GetApiScopes())\r\n .AddInMemoryClients(Config.GetClients())\r\n .AddDeveloperSigningCredential();\r\n }\r\n .\r\n .\r\n .\r\n }\r\n<\/pre>\nDikkat ederseniz ‘Config’ s\u0131n\u0131f\u0131 i\u00e7erisinde tan\u0131mlanan t\u00fcm konfig\u00fcrasyonlar ilgili alanlarda \u00e7a\u011fr\u0131larak uygulamaya eklenmi\u015ftir. Burada ‘AddDeveloperSigningCredential’ metoduna dikkatinizi \u00e7ekmek istiyorum. Asl\u0131nda bu metodun muadili olan ‘AddSigningCredential’ metoduda mevcuttur. \n<\/a><\/p>\n \u0130kisi aras\u0131ndaki temel fark\u0131 anlayabilmek i\u00e7in JWT imzalama stratejileri hakk\u0131nda k\u00fc\u00e7\u00fckte olsa bilgi sahibi olunmas\u0131 gerekmektedir. Bu stratejiler temelde Simetrik<\/em> yahut Asimetrik<\/em> \u015fifreleme algoritmalar\u0131d\u0131r. JWT, i\u00e7erdi\u011fi bilgileri sald\u0131rganlara kar\u015f\u0131 koruyabilmek i\u00e7in Simetrik<\/em> yahut Asimetrik<\/em> \u015fifreleme algoritmalar\u0131 kullanmaktad\u0131r. <\/p>\n Simetrik \u015eifreleme<\/em>; \u015eifrelenecek olan bilgiyi de\u015fifre edebilmek i\u00e7in gizli anahtar kullanan ve kriptografi teknikleri i\u00e7erisinde bilinen en eski lakin bir o kadar da basit bir \u015fifreleme t\u00fcr\u00fcd\u00fcr. \u015eifrelenen veri g\u00f6nderen ve al\u0131c\u0131 taraf\u0131nda bulunmas\u0131 gereken gizli anahtar de\u011fer arac\u0131l\u0131\u011f\u0131yla \u00e7\u00f6z\u00fclebilmektedir. H\u0131zl\u0131 ve efektif bir i\u015flem s\u00fcresinin olmas\u0131ndan dolay\u0131 avantajl\u0131d\u0131r. JWT de\u011feri imzalan\u0131rken kullan\u0131lan de\u011ferin ayn\u0131 zamanda do\u011frulamak i\u00e7in kullan\u0131lmas\u0131 durumudur. \n <\/a>Simetrik \u015eifreleme<\/p><\/div><\/p>\n Asimetrik \u015eifreleme<\/em>; \u015eifre ve de\u015fifre mant\u0131\u011f\u0131n\u0131 kullanan bir \u015fifreleme y\u00f6ntemidir. Haberle\u015fen taraflardan her birinde, birbiriyle matematiksel ba\u011f\u0131 olan ve biri gizli(private-secret) ve bir di\u011feri a\u00e7\u0131k(public) olan birer anahtar bulunmaktad\u0131r. Bu anahtarlardan herhangi biriyle \u015fifreleme yap\u0131l\u0131rken, di\u011feriyle \u015fifre \u00e7\u00f6zme i\u015flemi ger\u00e7ekle\u015ftirilmektedir. Gizli anahtar haberle\u015fen taraflardan sadece birinde bulunmaktad\u0131r ve di\u011fer taraftaki a\u00e7\u0131k anahtar ile do\u011frulan\u0131r. B\u00f6ylece \u015fifre \u00e7\u00f6z\u00fclm\u00fc\u015f olur. A\u00e7\u0131k anahtar herkes taraf\u0131ndan eri\u015filebilirdir, dolay\u0131s\u0131yla i\u00e7eri\u011fi \u00e7ok rahat incelenebilir. Bu durum bir tehlike arz etmemekte, m\u00fchim olan gizli anahtar\u0131n de\u015fifre edilemez olmas\u0131 g\u00fcvenceyi sa\u011flamaktad\u0131r. Yani anlayaca\u011f\u0131n\u0131z bilgiler sadece gizli anahtar\u0131n sahibi taraf\u0131ndan \u00e7\u00f6z\u00fclebilecek \u015fekilde \u015fifrelenmektedir.<\/p>\nAsitmetrik \u015eifreleme, kap\u0131(public key) ve kilit(private key) modeline uygun bir tasar\u0131ma sahiptir.<\/em><\/p><\/blockquote>\n <\/a>Asimetrik \u015eifreleme<\/p><\/div> \nIdentityServer4 framework’\u00fc JWT’leri imzalamak i\u00e7in Asimetrik \u015eifreleme’yi kullanmaktad\u0131r. A\u015fa\u011f\u0131daki \u015femada oldu\u011fu gibi ‘AuthServer’ client’tan gelen talep neticesinde token da\u011f\u0131tmadan \u00f6nce ilgili token’\u0131 private key ile \u015fifreler ve ard\u0131ndan ilgili client’a g\u00f6nderir. Client bu \u015fifrelenmi\u015f token de\u011feri ile API’a istekte bulunacak ve API’nda bu iste\u011fi do\u011frulamas\u0131 gerekecektir. Bunun i\u00e7in public key’e ihtiyac\u0131 vard\u0131r. Dolay\u0131s\u0131yla API’da ‘AuthServer’dan public key’i al\u0131r. Velhas\u0131l, gelen istekteki private key ile API’da ki public key uyumu kontrol edilir ve do\u011frulama neticesinde istek ba\u015far\u0131yla sonu\u00e7lan\u0131r. \n<\/a> \nAPI bu \u015fekilde bir algoritmayla, gelen istekteki token de\u011ferinin ‘AuthServer’da \u00fcretilen token olup olmad\u0131\u011f\u0131n\u0131 do\u011frulam\u0131\u015f olmaktad\u0131r.<\/p>\n Nihai olarak; ‘AddDeveloperSigningCredential’ metodu development esnas\u0131nda private ve public keyleri kendisinin otomatik olu\u015fturaca\u011f\u0131n\u0131 ifade eder. ‘AddSigningCredential’ metodu ise production’a \u00e7\u0131kt\u0131\u011f\u0131nda(\u00f6rne\u011fin Azure) kullan\u0131lacak olan bir se\u00e7enektir.<\/p>\n T\u00fcm bu \u00e7al\u0131\u015fmadan sonra yap\u0131lmas\u0131 gereken son i\u015flem ‘UseIdentityServer’ middleware’ini ‘UseAuthorization’ middleware’inden \u00f6nce \u00e7a\u011f\u0131rmakt\u0131r.<\/p>\n \r\n public class Startup\r\n {\r\n .\r\n .\r\n .\r\n public void Configure(IApplicationBuilder app, IWebHostEnvironment env)\r\n {\r\n .\r\n .\r\n .\r\n app.UseIdentityServer();\r\n app.UseAuthorization();\r\n .\r\n .\r\n .\r\n }\r\n }\r\n<\/pre>\n<\/li>\n2. Ad\u0131m – Geli\u015ftirilen IdentityServer4(AuthServer) Uygulamas\u0131n\u0131 Aya\u011fa Kald\u0131rma<\/strong> \nGeli\u015ftirilen ‘AuthServer’ projesinin token \u00fcretip \u00fcretmedi\u011fini denetleyebilmek i\u00e7in test ama\u00e7l\u0131 aya\u011fa kald\u0131rmam\u0131z gerekmektedir. \n<\/a> \nIdentityServer4 i\u015flevsel a\u00e7\u0131dan i\u015fe yarar baz\u0131 endpointleri hali haz\u0131rda b\u00fcnyesinde bar\u0131nd\u0131rmaktad\u0131r. Bunlardan token talebinde bulunabilmek i\u00e7in \/connect\/token<\/strong><\/code> endpoint’ini kullanabiliriz.<\/p>\n\u0130lgili endpoint’e a\u015fa\u011f\u0131daki body bilgilerini bar\u0131nd\u0131ran POST iste\u011finde bulunulmas\u0131 yeterlidir.<\/p>\n\n\n\n\nclient_id<\/strong><\/td>\n Hangi client’tan talep geldi\u011fini ifade eder.<\/td>\n<\/tr>\n client_secret<\/strong><\/td>\n Client’a ait secret de\u011ferini ifade eder.<\/td>\n<\/tr>\n grant_type<\/strong><\/td>\n Yetki tipini ifade eder.<\/td>\n<\/tr>\n<\/table>\n<\/a> \nG\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere ilgili alanlara ‘Config’ dosyas\u0131nda belirtilen konfig\u00fcrasyonlardaki de\u011ferler girilerek istekte bulunuldu\u011funda ilgili client’a ait token de\u011feri ba\u015far\u0131yla \u00fcretilip, d\u00f6nd\u00fcr\u00fclmektedir.<\/p>\n Burada k\u00fc\u00e7\u00fck bir noktaya temas etmek istiyorum. IdentityServer4(AuthServer) uygulamas\u0131n\u0131 aya\u011fa kald\u0131rd\u0131\u011f\u0131m\u0131z zaman uygulama i\u00e7erisinde otomatik olarak ‘tempkey.jwk’ dosyas\u0131 olu\u015fturulmaktad\u0131r. Bu dosyan\u0131n korunmaya ihtiyac\u0131 yoktur. Silindi\u011fi taktirde yine tekrardan otomatik olu\u015fturulmaktad\u0131r. \u0130\u015flevsel a\u00e7\u0131dan ‘AddDeveloperSigningCredential’ metodunun olu\u015fturaca\u011f\u0131 keyleri tutmaktad\u0131r. \u0130\u00e7eri\u011fi a\u015fa\u011f\u0131daki gibidir; \n<\/a><\/p>\n B\u00f6ylece IdentityServer4 uygulamas\u0131n\u0131n ba\u015far\u0131yla \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 test etmi\u015f olduk. \u015eimdi s\u0131ra API’lar\u0131 geli\u015ftirmeye gelmi\u015ftir…\n<\/li>\n 3. Ad\u0131m – API’lar\u0131n Geli\u015ftirilmesi<\/strong> \n‘AuthServer’ uygulamas\u0131n\u0131n koruyaca\u011f\u0131 API’lerin i\u00e7eri\u011fini sembolik olarak a\u015fa\u011f\u0131daki gibi geli\u015ftirmemiz yeterli olacakt\u0131r. Nihayetinde burada API’lar\u0131n verecekleri hizmetlerden ziyade geli\u015fimsel \u00f6zellikleri \u00f6nplanda olacakt\u0131r. \nGarantiAPI;<\/u><\/p>\n\r\n [Route("api\/[controller]\/[action]")]\r\n [ApiController]\r\n [Authorize]\r\n public class GarantiBankController : ControllerBase\r\n {\r\n [HttpGet("{musteriId}")]\r\n public double Bakiye(int musteriId)\r\n {\r\n \/\/....\r\n return 1000;\r\n }\r\n [HttpGet("{musteriId}")]\r\n public List<string> TumHesaplar(int musteriId)\r\n {\r\n \/\/....\r\n return new()\r\n {\r\n "123456789",\r\n "987654321",\r\n "564738291"\r\n };\r\n }\r\n }\r\n<\/pre>\nHalkBankAPI;<\/u><\/p>\n\r\n [Route("api\/[controller]\/[action]")]\r\n [ApiController]\r\n [Authorize]\r\n public class HalkBankController : ControllerBase\r\n {\r\n [HttpGet("{musteriID}")]\r\n public double Bakiye(int musteriId)\r\n {\r\n \/\/....\r\n return 500.15;\r\n }\r\n [HttpGet("{musteriID}")]\r\n public List<string> TumHesaplar(int musteriId)\r\n {\r\n \/\/....\r\n return new()\r\n {\r\n "135792468",\r\n "019283745",\r\n "085261060"\r\n };\r\n }\r\n }\r\n<\/pre>\nBurada as\u0131l \u00f6nemli olan nokta, API’lar\u0131n client’tan gelen request’te ki token’\u0131 nas\u0131l do\u011frulayacaklar\u0131n\u0131 \u00f6\u011frenmeleri gerekmektedir. Yukar\u0131daki sat\u0131rlardan da biliyoruz ki token(access_token) private key ile imzalanmaktad\u0131r. \u0130\u015fte imzalanm\u0131\u015f bu token API’lar da public key ile do\u011frulanmal\u0131d\u0131r.<\/p>\nAPI’lar da gelecek token de\u011ferlerini do\u011frulayabilmek i\u00e7in \u00f6ncelikle ilgili API’lara Microsoft.AspNetCore.Authentication.JwtBearer<\/a> k\u00fct\u00fcphanesinin y\u00fcklenmesi gerekmektedir. Ard\u0131ndan t\u00fcm\u00fcnde a\u015fa\u011f\u0131daki \u00e7al\u0131\u015fma ger\u00e7ekle\u015ftirilmelidir.<\/p>\n \r\n public class Startup\r\n {\r\n\r\n public void ConfigureServices(IServiceCollection services)\r\n {\r\n .\r\n .\r\n .\r\n services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)\r\n .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>\r\n {\r\n \/\/Token'\u0131 yay\u0131nlayan Auth Server adresi bildiriliyor. Yani yetkiyi da\u011f\u0131tan mekanizman\u0131n adresi bildirilerek ilgili API ile ili\u015fkilendiriliyor.\r\n options.Authority = "https:\/\/localhost:1000";\r\n \/\/Auth Server uygulamas\u0131ndaki 'Garanti' isimli resource ile bu API ili\u015fkilendiriliyor.\r\n options.Audience = "Garanti";\r\n });\r\n .\r\n .\r\n .\r\n }\r\n public void Configure(IApplicationBuilder app, IWebHostEnvironment env)\r\n {\r\n .\r\n .\r\n .\r\n app.UseAuthentication();\r\n app.UseAuthorization();\r\n .\r\n .\r\n .\r\n }\r\n }\r\n<\/pre>\nYukar\u0131daki kaynak kodda ‘GarantiAPI’ uygulamas\u0131n\u0131n konfig\u00fcrasyonu bulunmaktad\u0131r. Benzer uygulamay\u0131 ‘HalkBankAPI’ uygulamas\u0131 i\u00e7inde ger\u00e7ekle\u015ftirmemiz gerekmektedir. Tabi ki de \u00f6rneklendirmemizdeki ‘HalkBankAPI’a kar\u015f\u0131l\u0131k geli\u015ftirmeyi her ne kadar sizlere b\u0131rakm\u0131\u015f olsamda, yaz\u0131lm\u0131\u015f halini makalemizin nihayetinde payla\u015faca\u011f\u0131m \u00f6rnek projede somut olarak inceleyebilirsiniz. Velhas\u0131l, \u015fimdi biz yukar\u0131daki kaynak kodun mealine odaklan\u0131rsak e\u011fer; 9.<\/em><\/strong> sat\u0131rda ‘AddAuthentication’ servisinin uygulamaya dahil edildi\u011fini g\u00f6rmekteyiz ve \u015fema ad\u0131 olarak ‘JwtBearerDefaults.AuthenticationScheme’ sabitinin ta\u015f\u0131d\u0131\u011f\u0131 ‘Bearer’ de\u011feri verilmektedir. Bu de\u011fer(\u015fema ad\u0131) uygulamada authentication instance’\u0131n\u0131 tutan bir nitelik kazanmaktad\u0131r. \u0130stek do\u011frultusunda farkl\u0131 bir isimde verilebilmektedir. 10.<\/em><\/strong> sat\u0131r\u0131 incelersek e\u011fer ‘AddJwtBearer’ servisi eklenerek uygulamada JWT entegrasyonu sa\u011flanm\u0131\u015ft\u0131r. \u0130\u00e7erik olarak yine ayn\u0131 \u015fema ad\u0131 bildirilmekte ve b\u00f6ylece uygulamadaki bir \u00f6nceki metotta eklenen ayn\u0131 \u015fema ad\u0131ndaki authentication mekanizmas\u0131 JWT ile ba\u011fda\u015ft\u0131r\u0131lmaktad\u0131r. Konfig\u00fcrasyon a\u00e7\u0131s\u0131ndan olay\u0131 de\u011ferlendirirsek e\u011fer 13.<\/em><\/strong> sat\u0131rda ‘Authority’ bilgisi verilerek bu API’\u0131n hangi Auth Server taraf\u0131ndan korundu\u011fu, ba\u015fka bir deyi\u015fle yetkilisinin kim oldu\u011fu bildirilmektedir. 15.<\/em><\/strong> sat\u0131rda ise ‘Audience’ ile Auth Server’da ki hangi resource’e kar\u015f\u0131l\u0131k geldi\u011fi bildirilmekte ve b\u00f6ylece API ile ili\u015fkilendirilmektedir. Son olarak 26.<\/em><\/strong> sat\u0131rda ‘UseAuthentication’ ve pe\u015finen ‘UseAuthorization’ middleware’leri \u00e7a\u011fr\u0131larak uygulama kimlik do\u011frulamaya genel hatlar\u0131yla haz\u0131r hale getirilmektedir.<\/p>\n Art\u0131k bu API’a bir istek gelince ‘Authority’de tan\u0131mlanm\u0131\u015f olan ilgili Auth Server’a gidecek ve public key’i alacakt\u0131r. Ard\u0131ndan private key ile imzalanm\u0131\u015f olan access token de\u011ferini bu public key ile do\u011frulayacak ve b\u00f6ylece token’\u0131n ger\u00e7ek bir token oldu\u011funu anlam\u0131\u015f olacakt\u0131r.<\/p>\nAyriyetten IdentityServer4 k\u00fct\u00fcphanesinin konfig\u00fcrasyon kolayl\u0131\u011f\u0131na dair dikkatinizi \u00e7ekmek istiyorum. Normalde Token Bazl\u0131 Kimlik Do\u011frulama(JWT)<\/a> makalemi incelerseniz e\u011fer bir API’da ki gelen token’\u0131 do\u011frulayabilmek i\u00e7in ‘SymmetricSecurityKey’ vs. gibi \u00f6zellikleri belirlememiz gerekmektedir. Halbuki g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere IdentityServer4 ile API’lar da bu gibi konfig\u00fcrasyonlara gerek duyulmamaktad\u0131r.\n<\/li>\n<\/ul>\n Test Edelim<\/h3>\n\u015eimdi geli\u015ftirilen t\u00fcm uygulamalar\u0131 aya\u011fa kald\u0131rarak test edelim.<\/p>\n\n\n\n\n\n\nUygulamalar\u0131n aya\u011fa kald\u0131r\u0131lmas\u0131<\/em><\/td>\n <\/a><\/td>\n<\/tr>\n Postman ile API’a istek g\u00f6nderme<\/em><\/td>\n <\/a> \nG\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere client direkt olarak API’a istek g\u00f6nderdi\u011finde 401(Unauthorized) hata kodu almaktad\u0131r. \u015eimdi yapmas\u0131 gereken Auth Server’a gidip bir token talebinde bulunmakt\u0131r.\n<\/td>\n<\/tr>\n Auth Server’dan token talebinde bulunma<\/em><\/td>\n <\/a> \nToken talebi yap\u0131l\u0131rken body’den ‘client_id’, ‘client_secret’ ve ‘grant_type’ de\u011ferlerinin verildi\u011fine dikkatinizi \u00e7ekerim. Bu de\u011ferler makale seyrimiz boyunca de\u011findi\u011fimiz Auth Server’da ki client kar\u015f\u0131l\u0131klar\u0131d\u0131r.\n<\/td>\n<\/tr>\n Token ile API’a talepte bulunma<\/em><\/td>\n <\/a> \nToken ile API’a talepte bulunabilmek i\u00e7in ‘Authorization’ sekmesinden ‘OAuth 2.0’ type’\u0131n\u0131 se\u00e7erek, ‘Header Prefix’ ‘Bearer’ kar\u015f\u0131l\u0131\u011f\u0131nda, ‘Access Token’ alan\u0131na elde edilen token de\u011feri verilmeli ve o \u015fekilde istek g\u00f6nderilmelidir. G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere istek ba\u015far\u0131l\u0131 bir \u015fekilde sonu\u00e7lanacakt\u0131r.<\/p>\nLakin elde edilen token ile ‘HalkBankAPI’a istek yapmak istersek e\u011fer; \n<\/a> \n401 durum koduyla kar\u015f\u0131la\u015f\u0131lacakt\u0131r. Bunun nedeni ilgili token’\u0131n sadece ‘GarantiAPI’a eri\u015fim sa\u011flayabilmesidir. ‘HalkBankAPI’a talep yap\u0131labilmesi i\u00e7in client’\u0131n Auth Server’dan ilgili API’a ait bir token de\u011feri istemesi ve elde edece\u011fi token ile talepte bulunmas\u0131 gerekmektedir; \n<\/a> \n<\/a>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere IdentityServer4 uygulamam\u0131z\u0131n testi ba\u015far\u0131yla sonu\u00e7lanm\u0131\u015ft\u0131r. \u015eimdi son olarak \u00fcretilen JWT yap\u0131lanmas\u0131n\u0131n nas\u0131l bir i\u00e7eri\u011fe sahip oldu\u011funu inceleyerek makalemizi noktalayal\u0131m.<\/p>\n JWT \u0130ncelemesi<\/h3>\n\u00dcretilen JWT de\u011ferini a\u00e7abilmek ve \u00fczerinde tutulan de\u011ferleri(Payload) inceleyebilmek i\u00e7in decode etmemiz gerekmektedir. Bunun i\u00e7in jwt.io<\/a> adresini kullanabilirsiniz. \u0130lgili adreste a\u00e7\u0131lan forma elinizdeki JWT de\u011ferini verirseniz e\u011fer decode edip, ta\u015f\u0131d\u0131\u011f\u0131 t\u00fcm payload’lar\u0131 sizlere g\u00f6sterecektir. \n <\/a>\u00d6rnek ama\u00e7l\u0131 HalkBankAPI i\u00e7in \u00fcretilen JWT de\u011feri kullan\u0131lm\u0131\u015ft\u0131r…<\/p><\/div><\/p>\n Burada JWT i\u00e7erisindeki \u015fifrelenmi\u015f t\u00fcm Payload’lar\u0131 g\u00f6rebilmek sizler a\u00e7\u0131s\u0131ndan hafif bir ku\u015fkuya mahal vermi\u015f olabilir ve hani burada g\u00fcvenlik!<\/strong><\/em> sorusunu sorman\u0131z\u0131 sa\u011flayabilir. Evet, JWT’ler bu \u015fekilde decode edilebilmektedir ama server’da ki hashlenmi\u015f secret key’i bilmeden kimse herhangi bir valid de\u011fer \u00fcretememektedir. Bu da token’\u0131n public olmas\u0131na herhangi bir sak\u0131nca getirmemektedir. <\/p>\nVelhas\u0131l, yukar\u0131da decode edilmi\u015f olan JWT payload’lar\u0131na g\u00f6z atarsak e\u011fer; \n<\/a> \ng\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere t\u00fcm bilgiler kar\u015f\u0131m\u0131zdad\u0131r. Burada aud(Audience)<\/span> de\u011feri bu JWT’nin hangi resource taraf\u0131ndan kabul edilece\u011fini, client_id<\/span> de\u011feri istek yapan client’\u0131n Auth Server’da ki kimlik bilgisini ve scope<\/span> de\u011feri ise ilgili client’\u0131n ta\u015f\u0131d\u0131\u011f\u0131 t\u00fcm yetkilerini bildirmektedir.<\/p>\n Sonu\u00e7<\/strong> \nBu makalemizde IdentityServer4 temellerini pratikte t\u00fcm detaylar\u0131yla ele alm\u0131\u015f, bir Auth Server’dan nas\u0131l token talebinde bulunulabilece\u011fini, client’\u0131n elde etti\u011fi token ile ne \u015fekilde API’lara eri\u015fim sa\u011flayabilece\u011fini vs. \u00fczerinde uzun uzun isti\u015fare ederek \u00f6rneklendirmi\u015f bulunmaktay\u0131z. Bundan sonra herhangi bir client uygulamas\u0131 \u00fczerinden bu operasyonun nas\u0131l ger\u00e7ekle\u015ftirilebilece\u011fini \u00e7ok rahat anlayabilecek seviyede temellerin at\u0131ld\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnmekteyim. Sonraki i\u00e7eriklerimizde ad\u0131m ad\u0131m yetkilendirme boyutunu detayland\u0131racak ve olay\u0131 daha kurumsal uygulamalarda profesyonel \u00e7al\u0131\u015fmalar yapabilecek noktalara getirece\u011fiz…<\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n Not : \u00d6rnek \u00e7al\u0131\u015fmay\u0131 indirebilmek i\u00e7in buraya<\/a> t\u0131klay\u0131n\u0131z.<\/p>\n","protected":false},"excerpt":{"rendered":" Merhaba, IdentityServer4 Yaz\u0131 Serisinin bu \u00fc\u00e7\u00fcnc\u00fc makalesinde Client Credential yetki tipi ile gerekli konfig\u00fcrasyonlar e\u015fli\u011finde IdentityServer4 uygulamas\u0131 geli\u015ftirecek ve aya\u011fa kald\u0131raca\u011f\u0131z. Client Credential; machine to machine kimliklendirme dedi\u011fimiz iki uygulama aras\u0131ndaki etkile\u015fime istinaden kullan\u0131lan...<\/p>\n","protected":false},"author":1,"featured_media":18168,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3826],"tags":[3849,3850,3852,3843,3844,3845,3827,3841,3842,3846,3847,3840,3848,3851],"class_list":["post-18269","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-identityserver4","tag-api-resource","tag-api-scope","tag-asimetrik-sifreleme","tag-client-credential","tag-client-id","tag-client-secret","tag-identityserver4","tag-identityserver4-ayaga-kaldirma","tag-identityserver4-client-credential","tag-identityserver4-client-id","tag-identityserver4-client-secret","tag-identityserver4-uygulamasi","tag-machine-to-machine","tag-simetrik-sifreleme"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/18269","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=18269"}],"version-history":[{"count":123,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/18269\/revisions"}],"predecessor-version":[{"id":18413,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/18269\/revisions\/18413"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/18168"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=18269"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=18269"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=18269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}