Mikroservis Mimarisinde API Gateway ve JWT (JSON Web Token) Authentication

Günümüz uygulama geliştirme ortamlarında artık monolitik yapılar yerine mikro servis mimarisi tercih edilmektedir. Mikro servis mimarisi, bir uygulamanın farklı işlevlerini birbirinden bağımsız küçük servisler halinde sunarak daha ölçeklenebilir, esnek ve bakımı kolay bir yapı oluşturmayı amaçlar. Örneğin; herhangi bir e-ticaret uygulamasını ele aldığımızda sipariş, anasayfa, kullanıcı bilgileri, kullanıcı yetkileri(claim atamaları), ürün/kullanıcı detayları, kategoriler ve sepet gibi farklı bir çok mikroservise bölünebilir.

Bu yapılar genellikle bir güvenlik duvarının arkasındadır. Kullanıcıların kimlik doğrulama aşaması bir güvenlik kontrolüdür. Somut bir örnek ile ne anlatmak istediğime bakalım.

Yukarıda da verdiğim örnek üzerinden gidecek olursam, e-ticaret uygulaması üzerinden sepete ürün ekledim fakat bu ürünü giriş yapmadan satın alamam. Bu kullanıcının kimlik doğruladıktan sonra bir sonra ki aşamaya geçmesi yani client isteklerinin işlenmesi için bir mikroservis çağırması anlamına geliyor. Peki bu servisin her kullanıcı giriş yapmak istediğinde çağırılıp kullanıcı kimliğini doğrulama yükünü kaldırmalı mı? Bu çok verimsiz bir yapı olurdu.

Bu yapıda API Gateway kullanarak istekleri yönlendiren bir ara katman gereklidir. API Gateway, gelen istekleri farklı mikro servislere yönlendirir. API Gateway Pattern’de clientler mikroservislere direkt olarak erişemez. Bu yüzden isteklerin uygun ve doğru bir biçimde mikroservislere ulaşması için giriş noktasıdır diyebiliriz. Bu sayede, mikro servislerin kendi rollerine ve sorumluluklarına odaklanmalarına izin verilir. API Gateway aynı zamanda gelen istekleri doğrulayabilir ve yetkilendirme yapabilir. Bu, güvenlik açısından önemlidir, çünkü sadece doğru kimlik bilgilerine sahip olan kullanıcıların belirli servislere erişmesine izin verilir.

Bu ara katmanın birçok faydası vardır, ancak en önemlileri Authentication ve Authorization işlevlerinin sağlanmasıdır. Authentication, bir kullanıcının söylediği kişi olup olmadığını kontrol eder. Authorization ise kullanıcı kimliğinin doğrulanmış bir kişinin izin/yetki ve ayrıcalıklarının ne olacağı, hangi kaynaklara erişebileceğini doğrulamakla yükümlüdür.

Authentication, kullanıcıların kimliklerinin doğrulanması işlemidir. Bu, kullanıcı adı ve şifre gibi kimlik bilgilerinin doğruluğunun kontrol edilmesi yoluyla gerçekleştirilir. Authentication işlemi, doğru kimlik bilgilerine sahip olan kullanıcılara erişim izni verir.

Authorization ise kullanıcıların erişim yetkisini kontrol eder. Örneğin, bir kullanıcının sadece belirli bir mikro servise erişim izni olabilir, ancak diğerlerine erişim izni olmayabilir. Bu sayede, kullanıcıların uygulamanın farklı bileşenlerine erişimini kontrol etmek mümkün olur.

API Gateway’in Authentication ve Authorization işlevlerini sağlamak için, farklı kimlik doğrulama mekanizmaları kullanılabilir. Örneğin, OAuth2, JWT ve Basic Authentication gibi mekanizmalar kullanılabilir. Bu mekanizmalar, kullanıcıların kimliklerinin doğrulanması ve yetkilendirme işlemlerinin gerçekleştirilmesi için gerekli araçları sağlar.

Mikroservislerde JWT Uygulaması

1. Kullanıcı client’ten, kimlik bilgilerini doğrulama için Authorization Server’a gönderir.
2. Identity Server kimlik bilgilerini doğrular. Geçerli kullanıcı için, sunucu token’in içeriğini depolar ve bir access token oluşturur. Sunucu da rastgele şifrelenmiş olan bu token’i client’e gönderir.
3. Client oluşturulmuş olan token’i alır ve (Request+Reference Access Token) istek ile birlikte API Gateway’e gönderir.
4. Api Gateway, token’i client’ten alır. Alınan token’i yeniden Authorization Server’a gönderir.
5. Authorization Server, token’i doğrular. API Gateway’e bir JSON Access Token (JWT) döndürür. Artık bu token içerisinde hem kullanıcı bilgileri hem de bu kullanıcının izin bilgilerini içerir.
6. API Gateway, isteği JWT ile birlikte ilgili mikroservise yönlendirir.
7. Mikroservisler, gelen JWT içeriğini kullanarak doğrulama ve yetkilendirmeyi denetler.

JWT, güvenli bir şekilde bilgi iletmek için kompakt ve bağımsız bir yol tanımlayan açık standarttır (RFC 7519). JSON Web Token, kompakt biçiminde, noktalarla ( .) ayrılmış üç bölümden oluşur.

xxxxx.yyyyy.zzzzz

Header: JWT’nin ilk bölümü, tipik olarak iki bölümden oluşur: JWT olan token’in türü ve HMAC SHA256 veya RSA gibi kullanılan imzalama algoritması.

{
  "alg": "HS256",
  "typ": "JWT"
}

Ardından, bu JSON, JWT’nin ilk bölümünü oluşturmak için Base64Url olarak kodlanır.

Payload: Claim’leri yani JWT içinde gönderilecek bilgileri içeren bölümdür. Talepler, bir varlık (tipik olarak kullanıcı) ve ek veriler hakkındaki ifadelerdir. Üç tür talep vardır: registered, public, and private claims.

• Registered (Kayıtlı) Talepler : Bunlar, bir dizi yararlı, birlikte çalışabilir talep sağlamak için zorunlu olmayan ancak önerilen önceden tanımlanmış bir dizi taleptir. Bunlardan bazıları şunlardır: iss (veren), exp (son kullanma süresi), sub (konu), aud (izleyici) ve diğerleri .
• Public (Genel) Talepler : Bunlar, JWT’leri kullananlar tarafından istenildiği zaman tanımlanabilir. Ancak çakışmaları önlemek için IANA JSON Web Token Registry’de tanımlanmalı veya çarpışmaya dayanıklı bir ad alanı içeren bir URI olarak tanımlanmalıdırlar.
• Private (Özel) Talepler : Bunlar, bunları kullanmayı kabul eden taraflar arasında bilgi paylaşmak için oluşturulan özel hak talepleridir ve ne tescilli ne de kamuya açık hak talepleridir.

{
 "sub": "3333333333",
 "name": "Rüveyha",
 "role": Admin,
 "iss": http://rr.com,
 "exp": 1472034208
}

Signature: header’da belirtilen algoritma kullanılarak gizli bir anahtarla imzalanmasıyla oluşturulur.

Örneğin: HMAC SHA256 algoritması kullanılarak oluşturulan bir anahtar:

HMACSHA256(  
base64UrlEncode(header) + "." +
base64UrlEncode(payload),  secret)

Sonuç olarak HTML ve HTTP ortamlarında kolayca geçirilebilen noktalarla ayrılmış üç Base64-URL dizesidir ve SAML gibi XML tabanlı standartlarla karşılaştırıldığında daha kompakttır. Ortaya çıkan token aşağıdaki gibi bir hal alır ve request gönderilirken Authorization kısmında Bearer ile birlikte kullanılır.

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjQifQ.
-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

Mikroservisler, header ve payload içerisinde ki Base64 URL kodlu JSON formatında ki oluşmuş hash’i ayıklar. Signature bölümünün de şifresini key ile çözer. Signature zaten header ve payload’ın karmasından oluşmuş bir değerdir. Daha sonrasında bu değerlerin eşitliğini kontrol eder ve signature değerleri eşit ise kimliği doğrulanmış sonucuna varır.

Sonuç olarak, API Gateway, mikro servis mimarisinde önemli bir rol oynar. Authentication ve Authorization işlevleri, uygulamanın güvenliği için kritik öneme sahiptir ve API Gateway’in bu işlevleri sağlaması, uygulamanın daha güvenli ve esnek bir yapıya sahip olmasını sağlar.

İlk sorumuzun cevabı da burada alınmış oluyor. Temel avantaj, bir mikro servisin her çağırıldığında, bir kullanıcının kimlik doğrulama adımlarında ki yükünün azaltılmasıdır. Cevap olarak client’a gönderilecek bilgiler, daha sonra validate ve authenticate işlemi yapılabilmesi adına API Gateway’in cache’ine yazılır. Böylece gelecek herhangi bir request tekrar authentication servisine gitmeye gerek kalmadan Authentication Gateway diye adlandırabileceğimiz Api Gateway üzerinde authenticate edilebilir.JWT kullanıcının doğrulanması için yeterli olan bilgilerini şifreli bir şekilde içerir. Mikro hizmetler de her seferinde doğrulama adımlarını gerçekleştirmeye ve kullanıcının bilgileri için veritabanı servislerine gitmek gibi ek işlemlerin yapılmasını engeller.