.Net Core Mikroservis Mimarisinde IdentityServer4 Framework’ü (Teorik -1)

Bu yazımda sizlere dilimin döndüğü kadarıyla IdenitityServer4 Framework’ünün teorik bilgisini paylaşıyor olacağım. Temel anlamda Microservice mimarisi ile uygulama geliştiriyorsanız ve JWT kullanıyorsanız, bu yazımın sizlere faydalı olacağını düşünüyorum.

İyi okumalar..

Nedir?

IdentityServer4 bir frameworktür. Peki nasıl bir frameworktür?

IdentityServer4, OAuth 2.0 (Authorization) ve OpenId Connect (Authentication) protokollerini implement eden , uygulayan bir frameworktür. Burada yeni sorular aklınıza gelecek. Diyeceksiniz ki “OAuth 2.0” ve “OpenId Connect” nedir?.

Şimdi birazda bu protokollerden bahsedelim.

OAuth 2.0

OAuth 2.0, yukarıdaki görselden de anlayacağımız gibi client ile server arasında yetkilendirmeyi sağlayan protokoldür. Burada bir kurallar bütünü vardır. Yani her tarafında uyulması gereken kuralları vardır. Bu kurallar uyulduğu taktirde Client ile Server arasında yetkilendirmeyi sağlayabiliyoruz.

OAuth 2.0 hakkında daha detaylı bilgi almak için buradan dokümantasyonu inceleyebilirsiniz.

Biz kısaca çözmüş olduğu problemden bahsedelim.

Yukarıdaki görselde de gördüğünüz gibi bir örnek üzerinden inceleyelim.

Diyelim ki “MyFinans” adında bir finans web uygulaması geliştiriyoruz. Bu site kullanıcının banka hesaplarından para çekme ve hesaplardaki paraları aktarma gibi işlemleri yapıyor olsun. Kullanıcı Myfinans sitesine giriş yaparak A banka ve B banka bilgilerine ulaşabilmesi lazım. Buradaki hesap bilgileri, IBAN ve benzeri bir çok bilgilere ulaşabiliyor olacak. Burada hem user hem de bankalar açısından ciddi bir problem var.

User açısındaki problem şu: User My Finans uygulamasına A Bankası ve B Bankasının bilgilerini vermiş oldu. Eğer ben kötü niyetli bir bir kişi yani sahte bir site isem A ve B bankasındaki bütün hesaplara erişirim. Bu user açısından ciddi bir problem.

Peki bankalar açısından kötü olan durum nedir?

Bankalar kendi kullanıcısının bilgilerini user kullanıcısı verdiğinden dolayı parayı çeken gerçekten bir user mı yoksa MyFinans mı bunu anlayamıyor. Bu yüzden A ve B bankası açısından user’ın kendi bilgilerini vermesi ciddi bir sıkıntı. İşte burada devreye OAuth 2.0 protokolü giriyor.

Eğer her iki banka OAuth 2.0 protokolünü uyguluyor ise o zaman akış şu şekilde ilerleyecek.

Yukarıdaki görselde de anlatmak istediğim, ben MyFinans uygulamasına bir buton koyacağım bu butona “A Bankasına giriş yap” diyorum. My Finans uygulamasında A bankasına giriş yap butonuna tıkladığımda site beni A bankasının giriş ekranına yönlendirecek ve ben A bankasının login bilgilerini giriyor olacağım. A bankası bana bir tane token verecek, bu token sayesinde user’ın yerine A bankası ile iletişime geçebilirim. A bankasının bilgilerini güvenli bir şekilde kullanabilirim. Tıpkı yemeksepeti.com daki “facebook ile giriş yap ” “google ile giriş yap” işlemi gibi. Aynı işlemi B bankası için de yapıyor olacağım.

Bu sayede OAuth 2.0 protokolü kullanıcının banka bilgilerini güvenli bir yerde girmesini sağlamış oldu. Böylece user kullanıcısı datalarını My Finans gibi third party client’ler ile paylaşmamış oldu.

Ben my finans uygulaması ile bankaya giriş yaptıktan sonra bir yetkilendirme sayfası çıkıyor olacak. Burada da diyecek ki My Finans uygulaması şu hesaplarına erişmek istiyor şu hesaptan para çekmek istiyor vs. Eğer burada izin verirsek ona göre token veriyor olacak. Ve bu token içerisinde sadece user’ın vermiş olduğu izinleri gerçekleştirebileceğim bir yetkilendirme var.

İşte OAuth 2.0 protokolü bizi kullanıcının bilgilerini direk almadan güvenli bir şekilde bir kullanıcı yerine ilgili sitelerden data almamıza veya data göndermemize imkan sağlıyor.

OpenID Connect

OpenId Connect aslında bir protokolden ziyade OAuth 2.0 protokolü üzerinde bir katman, bir layer gibi düşünebilirsiniz. Yetkilendirmeden daha çok kimlik doğrulama (Authentication) ile ilgili işlemleri yapar.

Kısaca Authentication ve Authorization arasındaki farktan bahsedec isek. Authentication giriş esnasında yapılan işlemlerdir. Yani kullanıcı A bankasına login olduğunda, userın username, e posta gibi kişisel bilgilerinin kullanmak istedeği yerdir. Authorization ise giriş yapıldıktan sonraki yetkilendirme işlemlerinin yapıldığı yerdir. Yani ilgili user şu safalara erişebilsin ama şu banka hesaplarına erişemesin gibi işlemlerin yapıldığı yer.

OpenID Connect protokolü kullanıcı ile ilgili işlemlerden sorumlu iken, OAuth 2.0 protokolü yetkilendirme işlemleri ile ilgili sorumludur. Bu iki protokol birbirini tamamlayan protokoldür.

Şimdi gelelim asıl konumuza. IdentityServer4'ün ne işe yaradığını anlamak için bu iki protokolü bilmemiz gerekiyordu. Bu protokolleri kullanabilmek için gidip her ikisinin dokümantasyonunu detaylı inceleyerek projenizde uzun uğraşlar sonunda implemente edebilirsiniz. Ancak IdentityServer4 bu iki protokolü içerisinde barındırarak iç yükünü minimuma indiren bir frameworktör.

Buraya kadar anlattıklarım aslında IdentityServer4 ün çözmüş olduğu bir problem ile alakalıydı. IdentityServe4 ün çözmüş olduğu bir diğer problemi de şu şekilde anlatabilirim.

Görselde belirttiğim gibi microservis ile geliştirdiğimiz bir adet client uygulamamız ve 3 adet Api Servisimiz mevcut olsun. Userlar client üzerinden ilgili apilere erişim sağlıyor olacak. User kullanıcı bilgilerini doğru girerek apilere erişir. Ancak burada bir sorunumuz var. Buda bizim client’ımız dışındaki yabancı clientlerin API’lerimize erişim sağlayabiliyor olması. Modern web uygulamarında bu sorun bir token ile çözülüyor. Şuanda en popüler olanı Jason Web Token (JWT) ile yapılan authentication’dir.

Basit anlamda user kullanıcı bilgilerini cliente girer, client kullanıcı bilgilerini alarak bir jwt token döndürür ve bu token sayesinde API lere erişim sağlanır.

Peki IdentityServer4 ne yapıyor burada?.

Yine şekiller üzerinden anlatarak ilerleyeceğim.

Burada direk client üzerinden API lere erişmek yerine önce client IdentityServer Microservisine bir istekte blunuyor. IdentityServer servisinde her client için hangi apilere erişebilir hangi apide hangi metotlara erişebilir, okuma yazma güncelleme gibi hangi Authentication işlemlerinin yapılacağı bilgisini kayıt ediyoruz. Client Önce Identity’e istek atar. Identity Userın Aouthentication bilgilerini de barındırdığı bir token döndürür. Bu token ile client api lere istek atar. Bu sayede 3. parti uygulamaların Api lerimize erişim izni engellenmiş olur.

Buraya kadar teorik bilgi ile sizlere dilimin döndüğü kadar IdentityServer4 ile ilgili temel bilgi vermiş oldum. Umarım buraya kadar okuduklarınız anlaşılır ve faydalı bilgiler olmuştur.

Yazımın 2. Serisine buradaki medium adresinden ulaşabilirsiniz.

Teşekkürler.