- JWT,
JSON Web Tokens ifadesinin kısaltmasıdır ve kimliği doğrulanmış belirteçler için bir standarttır.
- JWT; başlık, payload, imza veya mesaj kimlik doğrulama kodundan oluşur.
- Doğrulama anahtarına sahip olan biri, payload'un gerçekliğini doğrulayabilir.
JWT'nin yaygın kullanım kalıbı
- JWT; yayıncı, alıcı, konu ve sona erme zamanı gibi bilgileri içerir.
- Alıcı, belirtecin gerçekliğini doğruladıktan sonra süresinin dolup dolmadığını kontrol eder ve konuyu kimliği doğrulanmış kullanıcı olarak kabul eder.
JWT'nin avantajları
- JWT'nin başlıca avantajı, alıcının kullanıcı veritabanına bağlanmadan belirtecin gerçekliğini doğrulayabilmesidir.
- Büyük ölçekli kurulumlarda, kimlik doğrulama hizmeti merkezi kullanıcı veritabanına erişen tek hizmet olabilir.
Oturumu kapatma ve oturum geçersiz kılma sorunu
- Kimlik doğrulama belirtecinin ömrü kısa olmalıdır. Örneğin en fazla 5 dakika.
- İstemciye ayrıca yeni bir kimlik doğrulama belirteci isteyebilmesini sağlayan bir refresh token verilir.
- Refresh token fiilen gerçek oturum belirteci rolünü üstlenir.
JWT'nin gerekli olmadığı durumlar
- Oturumu kapatma özelliğini uygulamak için geçerli JWT'lerin bir izin listesini veya iptal edilmiş JWT'lerin bir engelleme listesini tutmak gerekir.
- Bir kullanıcıyı engellemek için veritabanındaki
kullanıcı aktif işaretini kontrol etmek gerekir.
- Kullanıcı nesnesi ile diğer nesneler arasında ek ilişkilere ihtiyaç vardır.
- Veritabanıyla ilişkili işlemler gerçekleştirilir.
Sonuç
- Yukarıdaki koşullardan biri bile geçerliyse JWT'ye ihtiyaç yoktur.
- Sıradan opak oturum belirteçleri kullanmak ve bunları veritabanında saklamak daha iyidir.
- Böylece JWT'nin dezavantajlarından kaçınılabilir ve karmaşıklık azaltılabilir.
GN⁺ görüşü
- JWT, büyük ölçekli hizmetler için uygun olsa da çoğu küçük hizmette gereksiz karmaşıklık yaratabilir.
- Sıradan oturum yönetimi mekanizmaları, çoğu web uygulaması için yeterlidir.
- JWT kullanımı, oturumu kapatma ve oturum geçersiz kılma gibi özelliklerin uygulanmasını zorlaştırabilir.
- JWT'nin avantajlarından yararlanmak için hizmetin ölçeği ve gereksinimleri dikkatle değerlendirilmelidir.
- Başka bir alternatif olarak OAuth2 gibi kimlik doğrulama çerçeveleri düşünülebilir.
8 yorum
Çeşitli istemci kimlik doğrulamalarının gerektiği durumlarda, JWT kullanımıyla elde edilen fayda büyüktü.
Ancak ölçeklenebilirlik ve güvenlik her zaman farklı yönlere baktığı için, özellikle güvenlik kritikse başka yöntemleri kullanmanın daha iyi olduğunu düşünüyorum.
Ben kişisel olarak JWT token’larının, açığa çıksa da sorun olmayacak geçici verileri tarayıcı üzerinden sistemler arasında alıp verirken kullanılması gerektiğini düşünüyorum.
Kimlik doğrulamada kullanılan ve kişisel veri içeren token’lar içinse opaque token kullanmanın daha iyi olduğu kanaatindeyim..
Kişisel deneyimime göre, MVP yaparken JWT’nin avantajları vardı.
Örneğin, tek başına geliştirip bakımını yaptığınız bir hizmetse, ani taleplerden doğan planlama maliyetini azaltma düşüncesi vardı. Sonuçta başlangıçta kurduğunuz veri ilişkileri bir iki ay sonra tamamen değişebildiği için, planlama netleşmemiş bir durumdayken (özellikle
authile ilgili konularda) JWT payload yapısını optional field biçiminde kurgulayıp feature’ları önceden hayata geçirirseniz, planlama ekibinin domain ayrımı ve servis ayrımı işlerini yapmasına gerek kalmadan, en azından monolitik bir hizmette domain’i kolayca ayırabilecek şekilde uygulayıp pazarda test etme imkânı oluyordu diye hatırlıyorum. (Sonrasında da hizmetleri ayırma adımlarına geçiliyordu. Ya da vazgeçiliyordu.)Bununla birlikte, bunun geliştirilecek hizmetin domain’ine göre de değişeceğini düşünüyorum. Söz konusu proje, gerçek zamanlı hizmetler arasında özellikle üçüncü taraflarla bağlılığı yüksek bir projeydi.... Bu yüzden hızlı geliştirme sırasında veritabanında çok büyük miktarda document/row birikirse yönetim maliyetinin artacağı düşüncesiyle bu şekilde ilerlemiştik diye hatırlıyorum.
Elbette, odak hızlı geliştirmekse session yöntemi daha iyi olabilir diye düşünüyorum. (Başlangıçta farklı hizmetler arasındaki coupling çok güçlü olmadığı için sistemi baştan kurup yeniden yapmak da daha kolay oluyor.) Ayrıca başka ekip üyeleri katıldığında devir maliyeti de daha düşük oluyor.
O zamanlar kısa bir süre de olsa bunun üzerine epey düşünmüştüm ama açıkçası şimdi dönüp baktığımda, hangi tarafı seçerek geliştirmiş olursak olalım bunun proje üzerindeki etkisi o kadar da kritik olmayabilirdi gibi geliyor.
Ben kişisel olarak, API gateway kullanırken auth uygulamasını JWT ile yaptığımda fayda sağladığını düşünüyorum; ancak küçük ölçekli servislerde JWT’nin ne gibi avantajları olduğunu merak ediyorum. JWT içine koyulan kullanıcı bilgilerinin sık sık değiştiği durumlardan mı bahsediyorsunuz?
Söylediğinizle genel çerçevede büyük ölçüde aynı fikirdeyim. Sadece, kullanıcı varlığının kendisine dair modelleme sık sık bilgi değiştirmeyi gerektirecek şekilde değişmekten ziyade, yeni özellikler eklendiğinde ya da üçüncü taraf araçların kullanılacağı yeni bir servis ek bilgiler istediğinde bunların opsiyonel olarak eklenmesine daha yakındı. (Biraz daha açarsam, potansiyel olarak auth yönetimini API gateway gibi bir şeyle ayırıp ayırmama ya da buna benzer rol oynayan tek bir sunucu olup olmaması arasında belirsiz bir durum da vardı...)
Biraz daha somut örnek vermek gerekirse, ana servis olarak A adlı servisi götürdüğümüz bir durumdu. MVP olduğu için kullanıcı tablosunda sadece ödeme bilgisi ya da doğrulanmış kullanıcı olup olmadığı bilgisi vardı. Ama kullanıcıya göre farklı kimlik doğrulama bilgileri gerektiği için ancak bu şekilde kullanılabilen B ve C servislerini de eklememiz yönünde bir talep geldi. Bunlardan B'nin A servisinin içine girip girmeyeceği bile henüz belli değildi, C ise tamamen ortadan kalkabileceği için hafifçe test edilmek isteniyordu. (Plan yönetimi özelliğini ise söylemeye gerek kalmadan eklemek daha güvenli olurdu). Buna ek olarak B ve C'nin, mevcutta A servisini sunan web servis sayfası içinde birlikte kullanılabildiği bir yapı ile başlaması isteniyordu. Canlıdaki servisin yapısı gereği, plan yönetimi tablosu (ya da genel amaçlı bir kimlik doğrulama tablosu) oluşturup alan ilişkilerini servis bazında çizerek eşleyip uygulamaya geçene kadar birden fazla tablo sorgusu (veya collection sorgusu) kaçınılmazdı. Bunu toparlayacak birinin olduğu bir projede birkaç toplantı yapıp tam olarak çözmek istediğimiz problemin ne olduğu ve istenen özelliğin ne olduğu net biçimde çıkarılabilirdi, ama bunun garanti olduğu bir durum değildi. Ayrıca bu tür borçları ne zaman temizleyebileceğimiz de belirsizdi. Zaten A adlı servisin lansmanından önce de bunun olacağına dair işaretler görünüyordu... Bu yüzden ilk kurulumda auth sırasında mümkün olduğunca sorgu maliyetini ve ilerideki bakım maliyetini azaltacak bir yapıya gidelim diye düşününce JWT seçtik. Bunun dışında da benzer küçük olayların oldukça fazla olduğunu sanıyorum.
Ama yorumun sonunda da belirttiğim gibi, aslında bunu neyle hayata geçirmiş olsak da projenin kendisine çok büyük bir etkisi olmayabilirdi. Session ile yapmış olsak, session tarafında da bir yol bulunurdu diye düşünüyorum. Hatta geliştiricinin başka görev alanlarının işlerini de yapmak zorunda kaldığı durumlara ya da iletişim maliyetinin sürekli bozulduğu ortamlara maruz kalması çok daha yıkıcıydı diye düşünüyorum.
Monolitik yapıya uygun olsa bile, bazı servislerin ayrıştırılması ya da genişleme yol ayrımına gelindiğinde JWT ile oturum tabanlı mantık arasında belirgin farklar görülüyor. Mesele sadece kimlik doğrulama süreci değil; iç mantığın kullanılabilirliğinde veri kaynağını ele alma yöntemleri de değişecektir. Bu yüzden "küçük servis" bağlamını hangi ölçüte göre uygun saymak gerektiğini pek bilmiyorum. Bütün servislerin mutlaka küçük kalacağı varsayımı mı yapılıyor, yoksa büyük servislerin zor olacağı varsayımı mı, emin değilim. Yine de, bizim geliştirdiğimiz servislerin her zaman ne tür bir durumla karşılaşacağı belli olmasa da hâlâ faydalı olacak bağlamları destekleyen bir yapıyı en azından asgari düzeyde barındırması gerekmez mi diye düşünüyorum. Küçük servis varsayımı sanki sadece daha da küçülmeye devam edecekmiş gibi geliyor.
Hacker News görüşü
Hacker News yorum özeti