<\/div>\n

Merhaba,
\n

Ba\u015fl\u0131klar<\/p>\nToggle<\/span>

Direct Grant Flow Nas\u0131l Bir Davran\u0131\u015fa Sahiptir?<\/a>

Asp.NET Core \u0130le Direct Grant Flow \u00c7al\u0131\u015fmas\u0131<\/a>

Token \u0130le API’yi Koruyal\u0131m…<\/a><\/li><\/ul><\/li><\/ul><\/li><\/ul><\/nav><\/div>\n
\nBu i\u00e7eri\u011fimizde kullan\u0131c\u0131y\u0131 login ekran\u0131na hi\u00e7 y\u00f6nlendirmeksizin, uygulama arac\u0131l\u0131\u011f\u0131yla username + password’\u00fc do\u011frudan Keycloak’a g\u00f6nderip access token al\u0131nmas\u0131n\u0131 sa\u011flayacak olan Direct Grant Flow davran\u0131\u015f\u0131n\u0131 mercek alt\u0131na al\u0131yor olaca\u011f\u0131z.<\/p>\n

<\/span>Direct Grant Flow Nas\u0131l Bir Davran\u0131\u015fa Sahiptir?<\/span><\/h3>\n

Direct Grant Flow’da browser yoktur, redirect yoktur, HTML form yoktur… Tamamen arka planda programatik olarak \u00e7al\u0131\u015fan bir kimlik do\u011frulama \u015feklidir…<\/em><\/p><\/blockquote>\n
Direct Grant Flow’da uygulama Keycloak’a arka plandan programatik olarak username & password bilgilerini g\u00f6nderir, Keycloak ise bu bilgileri do\u011frulayarak token \u00fcretir. B\u00f6ylece kullan\u0131c\u0131y\u0131 Keycloak’a y\u00f6nlendirmeksizin s\u0131f\u0131r etkile\u015fimle token al\u0131nmas\u0131n\u0131 sa\u011flar. Bu i\u015flem, OAuth2 Resource Owner Password Credentials Grant<\/strong><\/em>‘in Keycloak taraf\u0131ndaki kar\u015f\u0131l\u0131\u011f\u0131d\u0131r.<\/p>\n
<\/span>Hangi Durumlar\/Senaryolar \u0130\u00e7in Tasarlanm\u0131\u015ft\u0131r?<\/span><\/h5>\n
Direct grant flow, \u00f6zellikle backend a\u011f\u0131rl\u0131kl\u0131 \u00e7al\u0131\u015fmalar i\u00e7in olduk\u00e7a kullan\u0131\u015fl\u0131d\u0131r. Misal olarak; eski CLI ara\u00e7lar\u0131, script’ler, cron job’lar da bir login olma ihtiyac\u0131 varsa s\u00fcreci daha da komplike etmemek i\u00e7in bu ak\u0131\u015ftan istifade edilebilir ve kullan\u0131c\u0131 ad\u0131 ve \u015fifre odakl\u0131 \u00e7al\u0131\u015fma h\u0131zl\u0131ca sa\u011flanarak gerekli yetkilendirme ger\u00e7ekle\u015ftirilebilir. Ayr\u0131ca taray\u0131c\u0131n\u0131n kullan\u0131lamayaca\u011f\u0131 mobil veya desktop uygulamalarda login olunmas\u0131 gerekiyorsa e\u011fer yine bu ak\u0131\u015ftan istifade edilebilir yahut m\u00fcdahale ihtimali d\u00fc\u015f\u00fck olan legacy sistemlerde de login ihtiyac\u0131n\u0131 giderebilmek i\u00e7in de tercih edilebilir. Tabi bu ve bunlara benzer durumlar\u0131 saymakla bitiremesek de k\u0131saca a\u015fa\u011f\u0131daki gibi \u00f6zetleyebilir ve genel bir tan\u0131mda bulunabiliriz…<\/p>\n\n\n\n\n\n\n\n\n\n\n
Durum<\/th>\n Nedeni?<\/th>\n \n
\n
\u00d6neriliyor mu?<\/div>\n
Alternatifi var m\u0131?<\/div>\n<\/p><\/div>\n<\/th>\n<\/tr>\n<\/thead>\n
Eski CLI ara\u00e7lar\u0131, script’ler, cron job’lar<\/td>\n \u00c7\u00fcnk\u00fc bu tarz eski sistemlerde token almak i\u00e7in yap\u0131lacak \u00e7al\u0131\u015fmalar a\u015f\u0131r\u0131 derecede dallan\u0131p budaklanabilir ve zaten muhtemelen karma\u015f\u0131k olan yap\u0131 daha da arap sa\u00e7\u0131na d\u00f6nerek geli\u015ftiricileri zorlayabilir. O y\u00fczden kullan\u0131c\u0131 ad\u0131 ve \u015fifre ile token almak en basit ve ideal \u00e7\u00f6z\u00fcm olacakt\u0131r.<\/td>\n \n
\n
\n \u2714<\/span>\n <\/div>\n
\n \u2716<\/span>\n <\/div>\n<\/p><\/div>\n<\/td>\n<\/tr>\n
Kurumsal i\u00e7 a\u011fda, g\u00fcvenilir mobil\/desktop uygulamalar<\/td>\n Kurumsal i\u00e7 a\u011flarda genellikle uygulamalar geli\u015ftiricilerin kontrol\u00fcnde olurlar ve credentials’\u0131n \u00e7al\u0131\u015fmayaca\u011f\u0131na dair bir g\u00fcven s\u00f6z konusu olur.<\/td>\n \n
\n
\n \u2714<\/span>\n <\/div>\n
\n \u2716<\/span>\n <\/div>\n<\/p><\/div>\n<\/td>\n<\/tr>\n
Legacy sistem entegrasyonu<\/td>\n Eski sistemler genellikle ba\u015fka bir ak\u0131\u015f bilmezler ya da farkl\u0131 bir ak\u0131\u015fa y\u00fcksek diren\u00e7 g\u00f6sterebilirler.<\/td>\n \n
\n
\n \u2714<\/span>\n <\/div>\n
\n \u2716<\/span>\n <\/div>\n<\/p><\/div>\n<\/td>\n<\/tr>\n
Testing \/ development ortamlar\u0131<\/td>\n Bu ortamlarda ama\u00e7 genellikle business logic kontrol\u00fcn\u00fc sa\u011flamak oldu\u011fundan login s\u00fcre\u00e7lerindeki ak\u0131\u015f maliyetlerinden ka\u00e7\u0131nmak i\u00e7in kullan\u0131labilir.<\/td>\n \n
\n
\n \u2714<\/span>\n <\/div>\n
\n \u0130stenirse bu ortamlarda da geli\u015ftirme sa\u011flanabilir, ancak gereksiz ve yersiz bir maliyet yarataca\u011f\u0131 i\u00e7in \u00f6nerilmez!<\/span>\n <\/div>\n<\/p><\/div>\n<\/td>\n<\/tr>\n
\u00d6zel uygulama login ekranlar\u0131<\/td>\n Kimi uygulamalarda login ekranlar\u0131 uygulamaya \u00f6zel olarak tasarlanmakta ve Keycloak’\u0131n login UI’\u0131 hi\u00e7 kullan\u0131lmamaktad\u0131r. B\u00f6yle durumlarda bu ak\u0131\u015f olduk\u00e7a etkili \u00e7\u00f6z\u00fcm sa\u011fl\u0131yor olacakt\u0131r.<\/td>\n \n
\n
\n \u2714<\/span>\n <\/div>\n
\n \u2716<\/span>\n <\/div>\n<\/p><\/div>\n<\/td>\n<\/tr>\n
Microservice \/ sistemden sisteme kullan\u0131c\u0131 do\u011frulama<\/td>\n Bir servis browser ak\u0131\u015f\u0131 olmaks\u0131z\u0131n kullan\u0131c\u0131 ad\u0131na i\u015flem yapacaksa e\u011fer tercih edilebilir.<\/td>\n \n
\n
\n Pek de\u011fil!<\/span>\n <\/div>\n
\n Client Credentials Flow<\/span>\n <\/div>\n<\/p><\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Peki hangi durumlarda tercih edilmemelidir?<\/em><\/strong>
\nDirect grant flow, \u00f6zellikle public olan yaz\u0131l\u0131mlarda tercih edilmemelidir. Misal olarak; 3. taraf mobil uygulamalarda bu flow’u kullanmak credentials’\u0131n uygulama i\u00e7inde saklanmas\u0131ndan dolay\u0131 \u00e7ok tehlikelidir.<\/p>\n
Ayr\u0131ca modern SPA + backend uygulamalarda Authorization Code Flow + PKCE ve machine-to-machine \u00e7al\u0131\u015fmalar\u0131nda ise Client Credentials Flow yakla\u015f\u0131mlar\u0131 \u00e7ok daha g\u00fcvenli olaca\u011f\u0131ndan dolay\u0131 bu tarz senaryolarda da \u00f6nerilmemektedir.<\/p>\n
IoT cihazlar\u0131 sorarsan\u0131z e\u011fer bu tarz durumlarda da cihaz ak\u0131\u015flar\u0131 s\u00f6z konusu olaca\u011f\u0131ndan Device Authorization Grant<\/em> tercih edilmelidir.<\/p>\n
Yani anlayaca\u011f\u0131n\u0131z browser tabanl\u0131 web uygulamalar\u0131nda, SSO beklentisi olan sistemlerde, MFA \/ OTP gibi geli\u015fmi\u015f auth gerektiren senaryolarda ve g\u00fcvenli\u011fi \u00f6ncelik olan modern uygulamalarda direct grant flow kullan\u0131lmamal\u0131d\u0131r!<\/p>\n
Direct Grant Flow’da, kimlik av\u0131 (phishing) ve kimlik bilgilerinin s\u0131zd\u0131r\u0131lmas\u0131 (credential leakage) riski her daim s\u00f6z konusudur! O y\u00fczden dikkatli kullan\u0131lmal\u0131d\u0131r.<\/em><\/p><\/blockquote>\n
<\/span>Direct Grant Flow’un \u0130\u00e7 Yap\u0131s\u0131<\/span><\/h3>\n
Direct grant flow’un i\u00e7 yap\u0131s\u0131 a\u015fa\u011f\u0131daki gibidir. <\/p>\n
\nDirect Grant
\n\u251c\u2500\u2500 Username Validation (execution)
\n\u251c\u2500\u2500 Password (execution)
\n\u251c\u2500\u2500 Direct Grant – Conditional OTP (sub-flow)
\n\u2502 \u251c\u2500\u2500 Condition – user configured (condition)
\n\u2502 \u2514\u2500\u2500 OTP (step)\n<\/div>\n
Burada g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere, direct grant flow’un ak\u0131\u015f mant\u0131\u011f\u0131 olduk\u00e7a sadedir… Keycloak’un \/token<\/code> endpoint’ine direct grant flow t\u00fcr\u00fcnden bir istek geldi\u011fi taktirde bu ak\u0131\u015f\u0131n her bir ad\u0131m\u0131 \u015fu sorumluluklar\u0131 yerine getiriyor olacakt\u0131r:<\/p>\n
\n1\ufe0f\u20e3Username Validation<\/em><\/strong> \nGelen istekte username de\u011ferini alacak, realm i\u00e7erisinde ilgili kullan\u0131c\u0131y\u0131 arayacak ve ard\u0131ndan bu kullan\u0131c\u0131da \u015funlar\u0131 kontrol edecektir: \n\ud83e\udc12 Kullan\u0131c\u0131 var m\u0131? \n\ud83e\udc12 Enabled m\u0131? \nE\u011fer ba\u015far\u0131s\u0131z olursa ak\u0131\u015f HTTP 400<\/em> e\u015fli\u011finde invalid_grant<\/em> d\u00f6necektir. Yok e\u011fer ba\u015far\u0131l\u0131 olursa da user context olu\u015fturulacak ve bir sonraki ad\u0131ma ge\u00e7ilecektir.\n<\/li>\n 2\ufe0f\u20e3Password<\/em><\/strong> \nGelen istekten password de\u011feri al\u0131nacak ve kullan\u0131c\u0131n\u0131n stored credential hash’i ile kar\u015f\u0131la\u015ft\u0131r\u0131lacakt\u0131r. E\u011fer kar\u015f\u0131la\u015ft\u0131rma ger\u00e7ekle\u015ftirilemiyorsa yine invalid_grant<\/em> d\u00f6necek ve ak\u0131\u015f\u0131 sonland\u0131racakt\u0131r. Yok e\u011fer kar\u015f\u0131la\u015ft\u0131rma ba\u015far\u0131l\u0131ysa kullan\u0131c\u0131 authenticate edilmi\u015f say\u0131lacak (ama hen\u00fcz token \u00fcretilmeyecek!)<\/u> ve bir sonraki ad\u0131ma ge\u00e7ilecektir.\n<\/li>\n 3\ufe0f\u20e3Direct Grant – Conditional OTP<\/em><\/strong> \nBu ad\u0131m esas\u0131nda bir sub flow’dur ve a\u015fa\u011f\u0131daki b\u00f6l\u00fcmlerden olu\u015fmaktad\u0131r:<\/p>\n\n3\ufe0f\u20e3.1\ufe0f\u20e3Condition \u2013 user configured<\/em><\/strong> \nBu ad\u0131mdan da anla\u015f\u0131laca\u011f\u0131 \u00fczere bir condition execution’d\u0131r ve ilgili kullan\u0131c\u0131da OTP credential’\u0131n tan\u0131ml\u0131 olup olmad\u0131\u011f\u0131n\u0131 kontrol etmektedir.<\/p>\nE\u011fer ki OTP yap\u0131land\u0131r\u0131lmam\u0131\u015fsa i\u00e7inde bulunulan sub flow tamamen atlanacakt\u0131r. Yok e\u011fer bir yap\u0131land\u0131rma s\u00f6z konusuysa bir sonraki ad\u0131ma ge\u00e7ilecektir.\n<\/li>\n 3\ufe0f\u20e3.2\ufe0f\u20e3OTP<\/em><\/strong> \nBu ad\u0131m yaln\u0131zca bir \u00f6nceki condition true oldu\u011fu taktirde \u00e7al\u0131\u015facakt\u0131r. \u0130\u015flevsel olarak \u015funlar\u0131 kontrol edecektir: \n\ud83e\udc12 Request i\u00e7erisinde totp<\/code> parametresi var m\u0131? \n\ud83e\udc12 G\u00f6nderilen OTP kodu do\u011fru mu? \n\ud83e\udc12 Time Step Window ge\u00e7erli mi?<\/p>\nE\u011fer ki totp<\/code> yoksa yahut OTP kodu yanl\u0131\u015fsa request ba\u015far\u0131s\u0131z kabul edilecek, aksi taktirde ba\u015far\u0131l\u0131 bir giri\u015f yap\u0131lm\u0131\u015f olunacakt\u0131r…\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n \u015eimdi muhtemelen, giri\u015f ba\u015far\u0131l\u0131 oldu\u011fu taktirde token’\u0131n \u00fcretilmi\u015f olmas\u0131n\u0131 bekliyorsunuz, ancak flow’da hala token \u00fcretilmi\u015f de\u011fildir! \u00c7\u00fcnk\u00fc dikkat ederseniz token \u00fcretimi flow’un bir execution ad\u0131m\u0131 de\u011fildir \ud83d\ude09 Flow’dan sonra token Keycloak taraf\u0131ndan \u00fcretilecektir…<\/p>\n <\/span>Direct Grant Flow’da Dikkat Edilmesi Gereken Durumlar<\/span><\/h3>\nDirect grant flow’u kullanacaksan\u0131z ba\u015f\u0131n\u0131z\u0131n derde girme ihtimalini de de\u011ferlendirmeniz gerekmektedir. Haliyle bu de\u011ferlendirme s\u00fcrecini sizlerin ac\u0131 ve maliyetli tecr\u00fcbelerine b\u0131rakmaks\u0131z\u0131n bir ka\u00e7 madde e\u015fli\u011finde teoride de olsa deneyimlendirerek fark\u0131ndal\u0131\u011f\u0131n\u0131z\u0131 art\u0131rmakta fayda g\u00f6r\u00fcyorum \ud83d\ude42<\/p>\n \nClient ayarlar\u0131na dikkat edin!<\/em><\/strong> \nDirect grant kullan\u0131rken client’\u0131n mutlaka Confidential olmas\u0131 gerekmektedir \u00e7\u00fcnk\u00fc bu ak\u0131\u015fta kullan\u0131c\u0131 ad\u0131 ve \u015fifre do\u011frudan token endpoint’ine g\u00f6nderilir; e\u011fer client Public olursa ortada bir client_secret<\/code> olmad\u0131\u011f\u0131 i\u00e7in hem uygulama kimli\u011fi do\u011frulanamaz hem de credential’\u0131n k\u00f6t\u00fcye kullan\u0131m riski ciddi \u015fekilde art\u0131\u015f g\u00f6sterebilir.<\/p>\nConfidential client kullan\u0131ld\u0131\u011f\u0131nda ise Keycloak, kullan\u0131c\u0131 kimlik bilgilerini do\u011frulamadan \u00f6nce client’\u0131 da client_id<\/code> + client_secret<\/code> ile do\u011frular ve b\u00f6ylece hem kullan\u0131c\u0131 hem de uygulama taraf\u0131 g\u00fcvence alt\u0131na al\u0131nm\u0131\u015f olur. Aksi taktirde public client + direct grant kombinasyonu, \u00f6zellikle backend yerine istemci taraf\u0131nda kullan\u0131l\u0131yorsa, \u015fifre s\u0131z\u0131nt\u0131s\u0131na ve k\u00f6t\u00fcye kullan\u0131ma a\u00e7\u0131k bir yap\u0131 olu\u015fturabilir.<\/li>\n Direct Grant’\u0131 herkes i\u00e7in a\u00e7may\u0131n!<\/em><\/strong> \nDirect grant’i realm genelinde serbest b\u0131rakmak, yani varsay\u0131lan flow’u de\u011fi\u015ftirip t\u00fcm client’lar\u0131n grant_type=password<\/code> ile token alabilmesine izin vermek ciddi bir g\u00fcvenlik riskidir. \u00c7\u00fcnk\u00fc bu durumda \u00f6zellikle web veya frontend client’lar da kullan\u0131c\u0131 ad\u0131 ve \u015fifreyi do\u011frudan token endpoint’ine g\u00f6nderebilir hale gelebilirler. Bu durum, credential s\u0131z\u0131nt\u0131s\u0131 ile brute force sald\u0131r\u0131s\u0131 y\u00fczeyini b\u00fcy\u00fctebilir ve risk ihtimallerini ister istemez art\u0131rabilir.<\/p>\n\n Brute Force nedir?<\/em><\/strong> Brute force, bir sald\u0131rgan\u0131n ayn\u0131 kullan\u0131c\u0131 i\u00e7in s\u00fcrekli \u015fifre denemesi yapmas\u0131d\u0131r. Misal olarak; ahmet \/ 123456, ahmet \/ 1234567, ahmet \/ qwerty, ahmet \/ 11111 vs. \u015feklinde…<\/p>\nDirect grant’te bu davran\u0131\u015f olduk\u00e7a tehlikeli hal alabilmektedir. \u00c7\u00fcnk\u00fc her \u015fey API \u00e7a\u011fr\u0131s\u0131 olarak cereyan ederken bu s\u00fcre\u00e7te login ekran\u0131 yok, captcha yok, UI yok… Yani bir script ile saniyede y\u00fczlerce deneme yap\u0131labilmesi m\u00fcmk\u00fcnd\u00fcr…\n<\/p>\n<\/div>\n Bu mant\u0131kla, direct grant’i yaln\u0131zca ger\u00e7ekten ihtiya\u00e7 duyan ve backend taraf\u0131ndan g\u00fcvenli \u015fekilde \u00e7al\u0131\u015fan belirli, confidential client’lar i\u00e7in a\u00e7\u0131k tutmak, di\u011fer web ve public client’larda kapal\u0131 b\u0131rakmak en do\u011fru yakla\u015f\u0131m olacakt\u0131r.\n<\/li>\n Brute Force durumuna kar\u015f\u0131 haz\u0131rl\u0131kl\u0131 olun!<\/em><\/strong> \nDirect grant ak\u0131\u015f\u0131nda login ekran\u0131, captcha ya da kullan\u0131c\u0131y\u0131 yava\u015flatan herhangi bir g\u00f6rsel engel olmad\u0131\u011f\u0131 i\u00e7in token endpoint do\u011frudan otomatik denemelere a\u00e7\u0131k hale gelmektedir. Bu da bir sald\u0131rgan\u0131n script yazarak ayn\u0131 kullan\u0131c\u0131 i\u00e7in ya da farkl\u0131 kullan\u0131c\u0131 adlar\u0131yla h\u0131zl\u0131ca \u015fifre denemesi yapabilmesine imkan sa\u011flar. \u0130\u015fte bizler bu sald\u0131raya brute force sald\u0131r\u0131s\u0131 diyoruz.<\/p>\nBu fark\u0131ndal\u0131kla, Keycloak Admin UI \u00fczerinden Realm<\/code> \ud83e\udc12 Security defenses<\/code> \ud83e\udc12 Brute force detection<\/code><\/span> kombinasyonuna gelerek brute force’a kar\u015f\u0131 koruma davran\u0131\u015f\u0131 mutlaka aktif edilmelidir.<\/a>Burada g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere d\u00f6rt farkl\u0131 yap\u0131land\u0131rmayla brute force’a kar\u015f\u0131 bir davran\u0131\u015f belirlenebilmektedir:<\/p>\n \nDisabled<\/em><\/u>: Brute force korumas\u0131 kapal\u0131d\u0131r. Kullan\u0131c\u0131 ne kadar yanl\u0131\u015f deneme yaparsa yaps\u0131n hesap kilitlenmeyecektir.<\/li>\n Lockout permanently<\/em><\/u>: Belirlenen ba\u015far\u0131s\u0131z deneme say\u0131s\u0131 a\u015f\u0131l\u0131nca hesap sadece adminin a\u00e7abilece\u011fi \u015fekilde kal\u0131c\u0131 olarak kilitlenecektir.<\/li>\n Lockout temporarily<\/em><\/u>: Limit a\u015f\u0131l\u0131nca hesap belirli bir s\u00fcreli\u011fine kilitlenecek, s\u00fcre doldu\u011fu taktirde otomatik a\u00e7\u0131lacakt\u0131r.<\/li>\n Lockout permanently after temporary lockout<\/em><\/u>: \u00d6nce ge\u00e7ici kilitleme uygulanacak, bu durum tekrar etti\u011fi taktirde hesap tamamen kilitlenecektir.<\/li>\n<\/ul>\nBizler bu yap\u0131land\u0131rmalar sayesinde ba\u015far\u0131s\u0131z deneme e\u015fi\u011fini (failure factor) istedi\u011fimiz gibi belirleyebilir ve hatal\u0131 denemeler bu e\u015fi\u011fi a\u015ft\u0131\u011f\u0131 taktirde ister ge\u00e7ici istersek de kal\u0131c\u0131 kilitleme (lockout) uygulayabiliriz.\n<\/li>\nMFA beklentisini do\u011fru ayarlay\u0131n!<\/em><\/strong> \nDirect grant ak\u0131\u015f\u0131, kullan\u0131c\u0131 ad\u0131 ve \u015fifreyi do\u011frudan API \u00fczerinden alarak token \u00fcretmeye yarad\u0131\u011f\u0131 i\u00e7in yaln\u0131zca password ve TOTP gibi basit OTP tabanl\u0131 MFA y\u00f6ntemlerini desteklemektedir. Ancak kullan\u0131c\u0131y\u0131 y\u00f6nlendirme ve ek do\u011frulama ekranlar\u0131 gerektiren SMS do\u011frulama, e-posta ile challenge, push notification yahut WebAuthn gibi etkile\u015fimli ve taray\u0131c\u0131 tabanl\u0131 ikinci fakt\u00f6rleri \u00e7al\u0131\u015ft\u0131ramamaktad\u0131r!<\/p>\nBu nedenle ileride daha geli\u015fmi\u015f veya farkl\u0131 MFA y\u00f6ntemlerinin eklenmesi planlan\u0131yorsa e\u011fer direct grant do\u011fru bir tercih olmayacak, onun yerine standart authorization code flow (bknz : Browser Flow Authentication<\/a>) gibi taray\u0131c\u0131 destekli bir ak\u0131\u015f kullanmak daha isabetli olacakt\u0131r.\n<\/li>\n Token s\u00fcresini k\u0131salt\u0131n!<\/em><\/strong> \nDirect grant genellikle mobil uygulamalar, CLI ara\u00e7lar\u0131 ve scriptler taraf\u0131ndan kullan\u0131ld\u0131\u011f\u0131 i\u00e7in g\u00fcvenlik a\u00e7\u0131s\u0131ndan token s\u00fcrelerinin k\u0131sa tutulmas\u0131 \u00f6nerilmektedir. \u00d6zellikle access token \u00f6mr\u00fc m\u00fcmk\u00fcn oldu\u011funca k\u0131sa ayarlanmal\u0131, refresh token<\/a> taraf\u0131nda ise rotation (her kullan\u0131mda yeni refresh token \u00fcretme) a\u00e7\u0131k olmal\u0131 ve reuse (eski refresh token’\u0131n tekrar kullan\u0131labilmesi) ise kapal\u0131 tutulmal\u0131d\u0131r. B\u00f6ylece bir token ele ge\u00e7irilse bile k\u0131sa s\u00fcrede ge\u00e7ersiz olacak ve yeniden kullan\u0131lma riski minimize edilmi\u015f olacakt\u0131r.\n<\/li>\n Scope ve rolleri minimal tutun!<\/em><\/strong> \nDirect grant ile al\u0131nan token’lar do\u011frudan kullan\u0131c\u0131 ad\u0131 ve \u015fifreyle \u00fcretildi\u011fi i\u00e7in g\u00fcvenlik a\u00e7\u0131s\u0131ndan daha hassas kabul edilirler. Bu nedenle, bu token’lara geni\u015f yetkiler vermek hi\u00e7 de do\u011fru de\u011fildir! \u00d6zellikle realm-admin<\/em> gibi y\u00fcksek ayr\u0131cal\u0131kl\u0131 roller ya da full access<\/em> benzeri geni\u015f scope’lar tan\u0131mlanmamal\u0131, bunun yerine sadece ger\u00e7ekten ihtiya\u00e7 duyulan scope ve roller verilerek least privilege<\/u><\/em> prensibi uygulanmal\u0131d\u0131r. Yani uzun laf\u0131n k\u0131sas\u0131, direct grant bir anlamda daha riskli bir giri\u015f kap\u0131s\u0131 oldu\u011fu i\u00e7in, \u00fcretilen token’\u0131n yetkisi m\u00fcmk\u00fcn oldu\u011funca dar tutulmal\u0131d\u0131r!\n<\/li>\n Client credentials ile kar\u0131\u015ft\u0131rmay\u0131n!<\/em><\/strong> \nDirect grant ile client credentials<\/a> ak\u0131\u015flar\u0131 s\u0131k\u00e7a kar\u0131\u015ft\u0131r\u0131l\u0131r ancak aralar\u0131nda temel bir fark vard\u0131r: Direct grant’te kullan\u0131c\u0131 ad\u0131 ve \u015fifre g\u00f6nderilerek cliet taraf\u0131ndan kullan\u0131c\u0131 ad\u0131na token al\u0131n\u0131r, yani ortada ger\u00e7ek bir user context vard\u0131r. Client credentials’ta ise hi\u00e7bir kullan\u0131c\u0131 yoktur, sadece client kendi kimli\u011fiyle (client id ve secret) token al\u0131r ve bu token uygulaman\u0131n kendisini temsil eder. Bu y\u00fczden direct grant user-based authentication i\u00e7inken, client credentials ise service-to-service ileti\u015fim senaryolar\u0131 i\u00e7in tercih edilir.\n<\/li>\n Logging & monigoring’e \u00f6zen g\u00f6sterin!<\/em><\/strong> \nDirect grant ak\u0131\u015f\u0131 do\u011frudan \/token<\/code> endpoint’i \u00fczerinden \u00e7al\u0131\u015ft\u0131\u011f\u0131 i\u00e7in brute force, credential stuffing ve otomatik sald\u0131r\u0131lara daha a\u00e7\u0131k bir y\u00fczey olu\u015fturmaktad\u0131r. Bu nedenle logging ve monitoring kritik bir \u00f6neme sahiptir. Ba\u015far\u0131s\u0131z login denemeleri, ola\u011fand\u0131\u015f\u0131 IP yo\u011funlu\u011fu, k\u0131sa s\u00fcrede \u00e7ok say\u0131da token talebi gibi anormallikler loglardan takip edilmeli ve m\u00fcmk\u00fcnse SIEM ya da benzeri bir izleme sistemine g\u00f6nderilerek alarm \u00fcretilmelidir. Aksi taktirde sald\u0131r\u0131lar sessizce ger\u00e7ekle\u015febilir ve ancak hasar olu\u015ftu\u011funda fark edilebilir.\n<\/li>\n HTTPS zorunlulu\u011funu \u00f6nemseyin!<\/em><\/strong> \nDirect grant ak\u0131\u015f\u0131nda kullan\u0131c\u0131 ad\u0131 ve \u015fifre do\u011frudan HTTP iste\u011fi body’sinde g\u00f6nderildi\u011fi i\u00e7in HTTPS kullan\u0131m\u0131 tart\u0131\u015fmas\u0131z \u015fekilde zorunludur. Aksi halde bu bilgiler a\u011f \u00fczerinde a\u00e7\u0131k metin olarak yakalanabilir ve kullan\u0131c\u0131 hesab\u0131 y\u00fcksek riskle kar\u015f\u0131 kar\u015f\u0131ya kalabilir. TLS sayesinde hem kimlik bilgileri hem de d\u00f6nen access token ve refresh token’lar \u015fifrelenmi\u015f \u015fekilde iletilir, b\u00f6ylece man-in-the-middle<\/em> ve dinleme sald\u0131r\u0131lar\u0131na kar\u015f\u0131 temel g\u00fcvenlik sa\u011flanm\u0131\u015f olur.\n<\/li>\n Legacy mi, ge\u00e7ici mi iyi de\u011ferlendirin!<\/em><\/strong> \nDirect grant g\u00fcn\u00fcm\u00fczde daha \u00e7ok legacy ya da ge\u00e7i\u015f s\u00fcrecindeki senaryolar i\u00e7in tercih edilen bir ak\u0131\u015f olarak g\u00f6r\u00fclmektedir. \u00c7\u00fcnk\u00fc modern g\u00fcvenlik yakla\u015f\u0131m\u0131 kullan\u0131c\u0131y\u0131 do\u011frudan yetkilendirme sunucusuna y\u00f6nlendirerek authorization code flow gibi taray\u0131c\u0131 tabanl\u0131 ve MFA a\u00e7\u0131s\u0131ndan daha esnek ak\u0131\u015flar\u0131 kullanmay\u0131 \u00f6nerir. Bu nedenle, yeni geli\u015ftirilen sistemlerde m\u00fcmk\u00fcnse browser-based flow tercih edilmeli, direct grant ise ger\u00e7ekten zorunlu olan durumlarda kontroll\u00fc ve s\u0131n\u0131rl\u0131 yetkilerle kullan\u0131lmal\u0131d\u0131r.\n<\/li>\n<\/ol>\nYani k\u0131saca direct grant flow’u kullan\u0131rken neleri yap\u0131p yapmamam\u0131z gerekti\u011fini a\u015fa\u011f\u0131da \u015f\u00f6yle bir tabloda toparlayal\u0131m:<\/p>\n\n\n\n\n\n\n\n\n\n\u2705 Yap<\/th>\n \u274c Yapma<\/th>\n<\/tr>\n<\/thead>\n Confidential client<\/td>\n Frontend\u2019ten direct grant<\/td>\n<\/tr>\n Sadece belirli client\u2019larda aktif<\/td>\n Public client<\/td>\n<\/tr>\n Brute force protection<\/td>\n MFA beklentisi<\/td>\n<\/tr>\n K\u0131sa token s\u00fcreleri<\/td>\n Geni\u015f yetkiler<\/td>\n<\/tr>\n Minimal yetki<\/td>\n S\u0131n\u0131rs\u0131z login denemesi<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/span>12 Kritik Soru \/ 12 Kritik Cevap<\/span><\/h3>\n\u015eimdi direct grant flow ile ilgili akla gelebilecek t\u00fcm kritik sorular\u0131 sorup, cevapland\u0131rmaya \u00e7al\u0131\u015fal\u0131m ve b\u00f6ylece konuya dair teferruatlar\u0131 da tamamlayarak teoride t\u00fcm y\u00f6nleriyle incelemeyi tamamlam\u0131\u015f olal\u0131m.<\/p>\n \nSoru 1 | Direct Grant Flow tam olarak hangi OAuth2 grant’ine kar\u015f\u0131l\u0131k gelmektedir?<\/span><\/summary>\nKullan\u0131c\u0131n\u0131n \u015fifresini do\u011frudan uygulamaya verdi\u011fi ve uygulaman\u0131n da bu bilgileri \/token<\/code> endpoint’ine iletti\u011fi Resource Owner Password Credentials Grant’e kar\u015f\u0131l\u0131k gelmektedir.<\/p>\n Not : Resource Owner Password Credentials Grant, OAuth2 d\u00fcnyas\u0131nda deprecated kabul edilen bir yakla\u015f\u0131m olsa dahi Keycloak bu yakla\u015f\u0131m\u0131 hala kontroll\u00fc bir \u015fekilde desteklemektedir.<\/span> \n<\/details>\n \nSoru 2 | Keycloak neden Direct Grant’\u0131 varsay\u0131lan olarak \u00f6n plana \u00e7\u0131karmaz?<\/span><\/summary>\n\u00c7\u00fcnk\u00fc; OAuth’un temel amac\u0131 \u015fifreyi client’tan saklamakt\u0131r. Haliyle direct grant bu ilkeyi bile bile bozmaktad\u0131r.<\/p>\n Keycloak, -bu ak\u0131\u015f\u0131 kullan\u0131ysan, ne yapt\u0131\u011f\u0131n\u0131 biliyorsundur-<\/em> varsay\u0131m\u0131yla hareket etmektedir. \n<\/details>\n \nSoru 3 | Direct Grant ile SSO neden m\u00fcmk\u00fcn de\u011fildir?<\/span><\/summary>\nDirect grant; stateless \u00e7al\u0131\u015fmaktad\u0131r ve cookie \u00fcretmemektedir, ayr\u0131ca browser context’i yoktur. Bundan kaynakl\u0131 SSO uygulanamamaktad\u0131r. Dolay\u0131s\u0131yla bu ak\u0131\u015fla elde edilen token sadece o uygulamaya\/client’a aittir. \n<\/details>\n \nSoru 4 | Direct Grant ile login olan kullan\u0131c\u0131 Keycloak UI’da oturum a\u00e7m\u0131\u015f say\u0131l\u0131r m\u0131?<\/span><\/summary>\nHay\u0131r! Direct grant ile login olundu\u011funda Keycloak bir access token ve refresh token \u00fcretir ancak bu i\u015flem taray\u0131c\u0131 \u00fczerinden ger\u00e7ekle\u015fmedi\u011fi i\u00e7in Keycloak taraf\u0131ndan bir browser session (SSO session) olu\u015fturulmaz. Haliyle kullan\u0131c\u0131 ger\u00e7ekten Keycloak login ekran\u0131na girip oturum a\u00e7m\u0131\u015f gibi say\u0131lmaz. Bu y\u00fczden Admin Console’daki aktif oturumlar listesinde bir “taray\u0131c\u0131 oturumu” g\u00f6r\u00fclemez. K\u0131saca, direct grant API kullan\u0131m\u0131 i\u00e7in ge\u00e7erli bir token verecektir ancak bu Keycloak UI’da a\u00e7\u0131lm\u0131\u015f bir oturum anlam\u0131na gelmeyecektir. Yani token’\u0131n var olmas\u0131, browser session’\u0131n var olmas\u0131 demek de\u011fildir! \n<\/details>\n \nSoru 5 | Direct Grant’te MFA neden s\u0131n\u0131rl\u0131d\u0131r?<\/span><\/summary>\n\u00c7\u00fcnk\u00fc kullan\u0131c\u0131n\u0131n etkile\u015fime girecek bir ekran\u0131 yoktur ve bu nedenle challenge-response yap\u0131s\u0131 kullan\u0131lamamaktad\u0131r.<\/p>\n Haliyle direct grant’te TOTP kullan\u0131m\u0131 m\u00fcmk\u00fcnken; SMS, e-mail, Push vs. kullanmak m\u00fcmk\u00fcn de\u011fildir! \nNeden TOTP m\u00fcmk\u00fcnde di\u011ferleri de\u011fil?<\/strong> \n\u00c7\u00fcnk\u00fc TOTP tamamen statik ve senkron bir ikinci fakt\u00f6rd\u00fcr de ondan. Yani kullan\u0131c\u0131, telefonundaki authenticator uygulamas\u0131ndan 6 haneli kodu g\u00f6rebilir ve direct grant iste\u011fi s\u00fcrecinde bu kodu \u015fifreyle birlikte g\u00f6nderebilir. Bunun i\u00e7in ekstradan bir y\u00f6nlendirme, challenge ba\u015flatma ya da kullan\u0131c\u0131yla etkile\u015fime vs. gerek yoktur!<\/p>\n Ancak SMS, e-posta veya push do\u011frulama y\u00f6ntemleri challenge-response mant\u0131\u011f\u0131yla \u00e7al\u0131\u015fmaktad\u0131rlar. \u00d6nce sunucu bir kod \u00fcretecek ve kullan\u0131c\u0131ya g\u00f6nderecektir, kullan\u0131c\u0131 o bildirimi g\u00f6recek ve kimi zaman linke t\u0131klayacak kimi zaman da onay verecektir. Yani s\u00fcre\u00e7 ne olursa olsun bir ka\u00e7 ad\u0131ml\u0131 etkile\u015fim gerektirecektir.<\/p>\n Direct grant’\u0131n yap\u0131sal olarak tek bir HTTP iste\u011finde kullan\u0131c\u0131 ad\u0131 ve \u015fifre (ve varsa OTP) ile token \u00fcretmek i\u00e7in tasarlanmas\u0131; ara ad\u0131mlar\u0131, beklemeleri, y\u00f6nlendirmeleri veya kullan\u0131c\u0131 etkile\u015fimlerini bar\u0131nd\u0131rmamaktad\u0131r. Dolay\u0131s\u0131yla SMS\/push gibi asenkron ve etkile\u015fimli MFA y\u00f6ntemlerini teknik olarak \u00e7al\u0131\u015ft\u0131rmas\u0131 m\u00fcmk\u00fcn de\u011fildir! \n<\/span> \n<\/details>\n<\/details>\n \nSoru 6 | Direct Grant Flow’a custom authentication step eklenebilir mi?<\/span><\/summary>\nEvet eklenebilir. Misal olarak; custom credential validator, custom OTP check yahut IP \/ device kontrol\u00fc gibi \u00f6zel ad\u0131mlar eklenebilir. Ama kullan\u0131c\u0131dan ek bilgi isteyen ad\u0131mlar eklenemezler. \n<\/details>\n \nSoru 7 | Direct Grant neden frontend uygulamalarda kesinlikle \u00f6nerilmez?<\/span><\/summary>\n\u00c7\u00fcnk\u00fc, frontend’de direct grant’i kullanmak demek \u015fifreyi istemciye emanet etmek demektir. Haliyle \u015fifre XSS ile \u00e7al\u0131nabilir ve network log’lar\u0131nda g\u00f6r\u00fclebilir. \n<\/details>\n \nSoru 8 | Direct Grant ile Client Credentials aras\u0131ndaki kritik fark nedir?<\/span><\/summary>\n\n\n\n\n\n\n\n\nDirect Grant<\/th>\n Client Credentials<\/th>\n<\/tr>\n<\/thead>\n Kullan\u0131c\u0131 vard\u0131r<\/td>\n Kullan\u0131c\u0131 yok<\/td>\n<\/tr>\n Username + password<\/td>\n Client ID + secret<\/td>\n<\/tr>\n User context<\/td>\n App context<\/td>\n<\/tr>\n Riskli<\/td>\n Daha g\u00fcvenli<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nKullan\u0131c\u0131 ad\u0131na i\u015flem yap\u0131yorsan direct grant, sistem ad\u0131na yap\u0131yorsan client credentials tercih edilmelidir. \n<\/details>\n \nSoru 9 | Direct client ile al\u0131nan token revoke edilebilir mi?<\/span><\/summary>\nRevoke<\/strong>, bir token’\u0131 ya da oturumu ge\u00e7ersiz k\u0131lmak yani iptal etmek demektir. Daha \u00f6nce \u00fcretilmi\u015f ve normalde s\u00fcresi dolana kadar ge\u00e7erli olmas\u0131 beklenen bir access token’\u0131 veya refresh token’\u0131, s\u00fcresi dolmadan \u00f6nce art\u0131k kullan\u0131lamaz hale getirmek anlam\u0131na gelmektedir.<\/p>\n Keycloak’da direct grant ile al\u0131nan token’da tabi ki de revoke edilebilir ancak browser session olmad\u0131\u011f\u0131 i\u00e7in revoke fark\u0131 kullan\u0131c\u0131 taraf\u0131ndan hemen hissedilmeyecektir. \n<\/details>\n \nSoru 10 | Direct Grant neden ‘ge\u00e7ici \u00e7\u00f6z\u00fcm’ olarak g\u00f6r\u00fclmelidir?<\/span><\/summary>\n\u00c7\u00fcnk\u00fc g\u00fcvenlik modeli zay\u0131fd\u0131r. Ayr\u0131ca MFA uyumsuzlu\u011fu, SSO davran\u0131\u015f\u0131n\u0131n olmay\u0131\u015f\u0131 ve modern yakla\u015f\u0131mlara ters olmas\u0131 bu d\u00fc\u015f\u00fcnceyi do\u011furmaktad\u0131r. \n<\/details>\n \nSoru 11 | Direct Grant kullanan bir client compromise olursa ne olur?<\/span><\/summary>\nDirect grant kullanan bir client’\u0131n compromise olmas\u0131 (yani uygulaman\u0131n ya da client secret’\u0131n\u0131n ele ge\u00e7irilmesi durumunda), ciddi g\u00fcvenlik riskleri s\u00f6z konusu olur. \u00c7\u00fcnk\u00fc bu ak\u0131\u015fta kullan\u0131c\u0131 ad\u0131 ve \u015fifre do\u011frudan uygulama taraf\u0131ndan al\u0131nd\u0131\u011f\u0131 i\u00e7in credential’lar s\u0131zabilir, \u00fcretilmi\u015f access ve refresh token’lar ele ge\u00e7irilebilir ve e\u011fer token’lara geni\u015f scope verilmi\u015fse sistem i\u00e7inde b\u00fcy\u00fck yetkiler k\u00f6t\u00fcye kullan\u0131labilir. Bu nedenle direct grant senaryolar\u0131nda token \u00f6m\u00fcrleri k\u0131sa tutulmal\u0131, refresh token g\u00fcvenli\u011fi s\u0131k\u0131 ayarlanmal\u0131, client’a minimum yetki verilmeli ve mutlaka etkin bir loglama d\u00fczene\u011fi ile izleme yap\u0131lmal\u0131d\u0131r. \n<\/details>\n \nSoru 12 | Direct Grant Flow’da en kritik g\u00fcvenlik ayar\u0131 hangisidir?<\/span><\/summary>\nYukar\u0131daki sat\u0131rlarda vurgulamaya \u00e7al\u0131\u015ft\u0131\u011f\u0131m gibi brute force protection ayar\u0131d\u0131r. \n<\/details>\n <\/span>Asp.NET Core \u0130le Direct Grant Flow \u00c7al\u0131\u015fmas\u0131<\/span><\/h3>\nEvet, teoriyi yeterince konu\u015ftuk \ud83d\ude0a Art\u0131k s\u0131ra bu ak\u0131\u015f\u0131 ASP.NET Core \u00fczerinde ad\u0131m ad\u0131m, \u00e7al\u0131\u015fan bir \u00f6rnekle hayata ge\u00e7irmeye gelmi\u015ftir. Tabi bunun i\u00e7in ilk olarak bir Asp.NET Core uygulamas\u0131 ile birlikte Keycloak’da a\u015fa\u011f\u0131daki konfig\u00fcrasyonlarda application-client<\/code> isimli bir client olu\u015fturulmas\u0131 gerekmektedir.<\/a>Dikkat ederseniz direct grant flow i\u00e7in olu\u015fturulacak client’\u0131n sade ve sadece Direct access grants<\/em> olmas\u0131 yeterlidir. Ancak sizler isterseniz Client authentication<\/em>‘\u0131 da a\u00e7abilir ve s\u00fcre\u00e7te client_secret<\/code> de\u011ferini de kullanabilirsiniz.<\/p>\n Hatta bu yakla\u015f\u0131m, mimarisel olarak g\u00fcvenlik modelini farkl\u0131 bir yere ta\u015f\u0131man\u0131za imkan tan\u0131yabilir. \u015e\u00f6yle ki; client authentication olmaks\u0131z\u0131n herhangi bir client’tan yanl\u0131zca username & password e\u015fli\u011finde Keycloak’dan token talep edebilirsiniz. Ancak client authentication ile token talebini, kendi olu\u015fturdu\u011funuz bir arac\u0131 API’ye y\u00f6nlendirebilir ve client_id<\/code> + client_secret<\/code> ile birlikte direct grant flow’u uygulayabilirsiniz. B\u00f6ylece token talebinde bulunan client, ister bir backend uygulamas\u0131 olsun isterse de SPA fark etmeksizin client_secret<\/code> de\u011ferini g\u00f6rmeyecek, bu de\u011fer yaln\u0131zca \u00f6zel arac\u0131 olarak olu\u015fturulan API’da tutulmu\u015f olacak ve o API \u00fczerinden token talebinde bulunulmu\u015f olacakt\u0131r.<\/p>\n Ancak bu durum sizlere \u00e7ok ideal gibi gelse de bana sorarsan\u0131z direct grant flow’u uygulayaca\u011f\u0131n\u0131z \u00e7al\u0131\u015fmalar da pek \u00f6nermedi\u011fim bir yakla\u015f\u0131md\u0131r. Neden mi?<\/em> Zaten modern OAuth \/ OIDC yakla\u015f\u0131m\u0131n\u0131n \u00f6zellikle ka\u00e7\u0131nmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131 \u015fey kullan\u0131c\u0131 \u015fifresinin uygulamalardan uzakla\u015ft\u0131r\u0131lmas\u0131d\u0131r. Haliyle bizler bu yakla\u015f\u0131m\u0131 benimsedi\u011fimiz taktirde kullan\u0131c\u0131 ad\u0131 ve \u015fifresi yine bizlere ait uygulaman\u0131n elinden ge\u00e7iyor olacakt\u0131r ve bu durum zaten istenmeyen vaziyetin ta kendisi olacakt\u0131r. Tamam, belki Keycloak’dan token isteyen client’\u0131n kim oldu\u011funa dair biraz daha s\u0131k\u0131 \u00e7al\u0131\u015fma sa\u011flanm\u0131\u015f olacak ama g\u00fcvenlik zincirinin halkas\u0131nda pek etken olmayacakt\u0131r. Hem, direct grant’i kullan\u0131yorsan\u0131z e\u011fer zaten do\u011fas\u0131 gere\u011fi g\u00fcvenlik eksikli\u011fi oldu\u011funun fark\u0131nda olman\u0131z gerekmekte ve bu tarz u\u011fra\u015flara girmenin pek de l\u00fczumlu olmad\u0131\u011f\u0131n\u0131 s\u00f6ylemekte fayda g\u00f6rmekteyim.<\/p>\n Haliyle; direct grant, client authentication ile teoride daha s\u0131k\u0131 bir g\u00fcvenlik sa\u011fl\u0131yormu\u015f gibi g\u00f6r\u00fcnse de pratikte kazan\u0131m\u0131 olduk\u00e7a d\u00fc\u015f\u00fck ve hatta gereksiz bir u\u011fra\u015f olacakt\u0131r. E\u011fer ger\u00e7ekten g\u00fcvenli\u011fi art\u0131rmak istiyorsan\u0131z direct grant’ten vazge\u00e7ip autorization code + PKCE’ye ge\u00e7mek \u00e7ok daha do\u011fru bir hamle olacakt\u0131r.<\/p>\n Evet, art\u0131k Keycloak’da client’\u0131 olu\u015fturdu\u011fumuza g\u00f6re s\u0131ra Asp.NET Core uygulamas\u0131na gelmi\u015ftir. Bu uygulaman\u0131n temellerini a\u015fa\u011f\u0131daki k\u00fct\u00fcphaneler e\u015fli\u011finde g\u00f6sterildi\u011fi gibi yap\u0131land\u0131ral\u0131m:<\/p>\n \n Gerekli K\u00fct\u00fcphaneler<\/strong> \nMicrosoft.AspNetCore.OpenApi<\/a> \nScalar.AspNetCore<\/a>\n<\/div>\n\n\r\nusing Microsoft.AspNetCore.Mvc;\r\nusing Scalar.AspNetCore;\r\nusing Shared.Modals.Request;\r\n\r\nvar builder = WebApplication.CreateBuilder(args);\r\n\r\nbuilder.Services.AddOpenApi();\r\n\r\nbuilder.Services.AddHttpClient("keycloak", configure =>\r\n{\r\n configure.BaseAddress = new Uri("http:\/\/127.0.0.1:8080");\r\n});\r\n\r\nvar app = builder.Build();\r\n\r\nif (app.Environment.IsDevelopment())\r\n{\r\n app.MapOpenApi();\r\n app.MapScalarApiReference(options =>\r\n {\r\n options.Layout = ScalarLayout.Classic;\r\n options.WithTheme(ScalarTheme.BluePlanet);\r\n });\r\n}\r\n\r\n.\r\n.\r\n.\r\n\r\napp.Run();\r\n<\/pre>\n<\/div>\nVe direct grant ile token talebini \u015f\u00f6yle bir endpoint ile ger\u00e7ekle\u015ftirelim:<\/p>\n\n\r\napp.MapPost("\/login\/{realm}", async (LoginRequest loginRequest, IHttpClientFactory httpClientFactory, string realm = "master") =>\r\n{\r\n var httpClient = httpClientFactory.CreateClient("keycloak");\r\n\r\n var parameters = new Dictionary<string, string>\r\n {\r\n ["grant_type"] = "password",\r\n ["client_id"] = "application-client",\r\n \/\/["client_secret"] = "TSQ7dhxgymeqxPunV18S3WQY6dmBY9Il",\r\n ["username"] = loginRequest.Username,\r\n ["password"] = loginRequest.Password\r\n };\r\n\r\n var response = await httpClient.PostAsync($"realms\/{realm}\/protocol\/openid-connect\/token", new FormUrlEncodedContent(parameters));\r\n\r\n if (!response.IsSuccessStatusCode)\r\n return Results.Unauthorized();\r\n\r\n var token = await response.Content.ReadFromJsonAsync<Shared.Modals.Responses.AccessTokenResponse>();\r\n return Results.Ok(token);\r\n});\r\n<\/pre>\n<\/div>\n\u0130\u015fte bu kadar \ud83d\ude42 \u015eu ana kadar t\u00fcm risklerini aktarmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131m bu ak\u0131\u015f esas\u0131nda bu kadar basit bir \u015fekilde uygulanabilen bir yakla\u015f\u0131ma sahiptir. Ve evet, bu endpoint’e gerekli bilgiler do\u011frultusunda istekte bulunuldu\u011fu taktirde a\u015fa\u011f\u0131daki gibi token elde ediliyor olacakt\u0131r.<\/a>Tabi \u015fu andaki durumuyla ilgili client her t\u00fcrl\u00fc sald\u0131r\u0131ya a\u00e7\u0131k vaziyettedir. Haliyle bu realm’de direct grant flow kullan\u0131ld\u0131\u011f\u0131 i\u00e7in brute force protection<\/em>‘\u0131n a\u00e7\u0131lmas\u0131n\u0131 ve rate limiting<\/em>‘in uygulanmas\u0131n\u0131 tavsiye ederim. Ayr\u0131ca \u015fu a\u015famadan sonra sistemi en k\u00f6t\u00fc ihtimal loglarla takip etmeyi ihmal etmemek gerekmektedir…<\/p>\n <\/span>Token \u0130le API’yi Koruyal\u0131m…<\/span><\/h5>\nEvet, bunun i\u00e7in ekstradan bir Asp.NET Core projesi olu\u015fturmaya gerek g\u00f6rmemekteyim. Mevcut uygulamam\u0131zda bir endpoint’i korumal\u0131 hale getirebilir ve do\u011frulamay\u0131 ger\u00e7ekle\u015ftirebiliriz.<\/p>\n \u015eimdi bunun i\u00e7in mevcut uygulamada a\u015fa\u011f\u0131daki gibi authentication ve authorization yap\u0131land\u0131rmalar\u0131nda bulunal\u0131m:<\/p>\n\n\r\nvar builder = WebApplication.CreateBuilder(args);\r\n\r\nbuilder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)\r\n .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>\r\n {\r\n options.Authority = "http:\/\/127.0.0.1:8080\/realms\/master";\r\n\r\n options.Audience = "account";\r\n\r\n options.RequireHttpsMetadata = false;\r\n\r\n options.TokenValidationParameters = new TokenValidationParameters\r\n {\r\n ValidateIssuer = true,\r\n ValidateAudience = true,\r\n ValidateLifetime = true,\r\n ValidateIssuerSigningKey = true,\r\n NameClaimType = JwtRegisteredClaimNames.PreferredUsername\r\n };\r\n });\r\n\r\nbuilder.Services.AddAuthorization();\r\n.\r\n.\r\n.\r\nvar app = builder.Build();\r\n\r\napp.UseAuthentication()\r\n .UseAuthorization();\r\n.\r\n.\r\n.\r\napp.Run();\r\n<\/pre>\n<\/div>\nArd\u0131ndan a\u015fa\u011f\u0131daki gibi korumal\u0131 bir endpoint tasarlayal\u0131m:<\/p>\n\n\r\napp.MapGet("\/profile", (HttpContext httpContext) =>\r\n{\r\n return Results.Ok(new\r\n {\r\n httpContext.User.Identity?.Name,\r\n Claims = httpContext.User.Claims.Select(claim => new { claim.Type, claim.Value })\r\n });\r\n}).RequireAuthorization();\r\n<\/pre>\n<\/div>\n\u0130\u015fte tamamd\u0131r… Art\u0131k token edinmeksizin bu endpoint’e istekte bulunulamayacakt\u0131r. Tabi bunun testini sizlere b\u0131rak\u0131yor ve bu i\u00e7eri\u011fi art\u0131k noktal\u0131yorum \ud83d\ude42<\/p>\n Nihai olarak; \nBu i\u00e7eri\u011fimizde direct grant flow’un tam teferruatl\u0131 incelemi\u015f ve nedir, nas\u0131l yap\u0131l\u0131rdan ziyade genel \u00e7izginin d\u0131\u015f\u0131na \u00e7\u0131karak ilgili flow’u dikkat edilmesi gereken hususlar do\u011frultusunda ciddi bir ara\u015ft\u0131rma ve inceleme s\u00fcrecine tabi tutmu\u015f bulunmaktay\u0131z.<\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n\n\n \n\u00d6rnek \u00e7al\u0131\u015fmaya a\u015fa\u011f\u0131daki GitHub reposundan eri\u015febilirsiniz.<\/div>\nhttps:\/\/github.com\/gncyyldz\/Keycloak.Examples<\/div>\n<\/p><\/div>\n<\/p><\/div>\n\n Bu repository, ilgili projenin kaynak kodlar\u0131n\u0131 ve mimari yap\u0131s\u0131n\u0131 i\u00e7ermektedir. Detaylar i\u00e7in GitHub \u00fczerinden inceleyebilirsiniz.\n <\/div>\n \n GitHub\u2019da G\u00f6r\u00fcnt\u00fcle \u2192 \n <\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Merhaba, Bu i\u00e7eri\u011fimizde kullan\u0131c\u0131y\u0131 login ekran\u0131na hi\u00e7 y\u00f6nlendirmeksizin, uygulama arac\u0131l\u0131\u011f\u0131yla username + password’\u00fc do\u011frudan Keycloak’a g\u00f6nderip access token al\u0131nmas\u0131n\u0131 sa\u011flayacak olan Direct Grant Flow davran\u0131\u015f\u0131n\u0131 mercek alt\u0131na al\u0131yor olaca\u011f\u0131z. Direct Grant Flow Nas\u0131l Bir...<\/p>\n","protected":false},"author":1,"featured_media":28235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5206,5554],"tags":[5662,5661,5616,5659,5555,5610,5660],"class_list":["post-28434","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net","category-keycloak","tag-brute-force","tag-device-authorization-grant","tag-direct-grant-flow","tag-direct-grant-flow-authentication","tag-keycloak","tag-resource-owner-password-credentials-grant","tag-resource-owner-password-grant"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28434","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=28434"}],"version-history":[{"count":13,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28434\/revisions"}],"predecessor-version":[{"id":28460,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28434\/revisions\/28460"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/28235"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=28434"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=28434"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=28434"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}