JWT Standardı - Peptr Blog
Genel Fatih Cüre 4 Şubat 2020 0 0
JWT, JSON Web Token’in kısaltması ve adından da anlaşılacağı üzere bir token’dir. Bir IETF standardı olan bu token ile genellikle kullanıcı kimlikleme ya da doğrulama ve güvenli veri alışverişi sağlama konularında sıklıkla tercih edilmektedir.
JWT yapısına değinecek olursak; gövdesinde Header, Payload ve Verify Signature kısımlarını içerir. Her bir kısım arasında nokta ile ayrılan bir yapısı vardır. Bir token üretmek istediğimizde HMAC algoritması ile secret key ya da public/private key çiftlerini RSA veya ECDSA kullanarak imzalamamızı bu yapı mümkün kılıyor.
Örnek bir JWT aşağıdaki şekildedir.
JWT oluşturma yönünde yapının nasıl olacağını gösterelim.
Header, verinin tipinin “JWT” olduğunu, hangi algoritma ile mesajın doğrulanacağını(MAC) ve/veya şifreleneceğini(encrpyt) belirtir.
** MAC: Message Authentication Code
Bu yapıya JOSE Header denilmektedir.
JSON Web Token üzerinde JSON objesinin hangi kriptografik tanımlar ve ek özelliklerle birlikte niteleneceği bir başlık ile belirlenir ve bu başlığa JOSE Header denir.
Header kısmının token üzerindeki yeri bu JSON parçasının Base64URL ile şifrelenmesiyle(encode) elde edilir.
Payload kısmına gelecek olursak, bu kısımda dikkat edilmesi gereken ufak bir nüans var. JSON Web Token standardında önceden belirlenmiş alanlar bulunmaktadır ve bu alanların mantıklı olarak kullanılmasında fayda olacaktır. Fayda olacaktır diyoruz, çünkü bu alanların kullanımı zorunlu değildir, sadece kullanılması tavsiye edilmektedir. Bu alanlara örnek olarak; jti (ID), iat (issued at), nbf (not before) verilebilir. Toplamda yedi adet alan bu şekilde ön tanımlıdır. Buradan inceleyebilirsiniz. Tanımın dışına çıkmamak adına, bu alanların dışında kalan alanı dilediği gibi kullanmak geliştiriciye kalmıştır.
Örnek bir Payload yapısı ise aşağıdaki şekildedir.
Payload kısmı, Header kısmı ile aynı şekilde Base64URL ile şifrelenip(encode) görseldeki orta kısma yerleşecek.
JWT nin son alanı olan “Signature” alanını oluşturmak için şifrelenmiş başlık, payload ve secret key bulunmalıdır. Bu veriler bulunduğu taktirde hangi algoritmanın kullanılacağı başlık üzerinden alınarak imza oluşturulur.
*Algoritmanın “none” olarak belirlendiği tokenler “unsecured” tokenlere örnektir. Bunun gibi birkaç güvensiz JWT örneği daha vardır.
Bu üç alanın Base64URL çıktıları, aralarında nokta bulunacak şekilde bir araya getirilmesi ile token elde edilir.
JWT’nin yapısı ve az da olsa nasıl elde edildiği hakkında bilgi vermeye çalıştık. Şimdi bir kimlik doğrulama örneğini inceleyecek olursak;
Session kullanımı yönünden karşılaştıralım. Öncelikle session yapısının genellikle server tarafında session bilgisini bir şekilde saklaması gerektiğini biliyoruz. JWT’de ise sadece sizin server tarafınızın bildiği bir “secret” olduğunu düşünün ve token elde ederken veriyi, bu secret ile birlikte server tarafı imzalıyor.
Bu örneği bir sözleşmeye benzetecek olursak, token üzerindeki bilgileriniz sözleşmenin kendisi ve bir arkadaşınız da bu sözleşmeyi okuyabiliyor. Ancak altında bulunan imza sizin imzanız, bunu unutmamak gerek. İmzanız size has olduğu için, sadece sizin yordamınızla yapıldığında ortaya öyle bir imza çıkıyor. Bu bakımdan imza atış yordamınız ise “secret” oluyor. Bir başkası gelip sözleşmenizin birebir aynısını başka bir kağıda yazsa bile, altına sizin gibi imza atamayacağı için geçersiz bir sözleşme oluyor.
Aynı şekilde server tarafında karşı taraftan gelen tokene bakıp sizin imzanız olmadığını kontrol edip herhangi bir yönde karar vermek de size kalmış oluyor.
Peki JWT bize ne kazandırır ne kaybettirir?
+ Token kullanarak birden fazla servis ile muhatap olabiliyoruz. Kaynak bağımsız olmasından dolayı her servis kendi doğrulamasını yapabilmekte.
+ Çoğu bilgiyi kendi üzerinde tutuyor olmasının bir avantajı olarak, ayrı olarak bir tabloya ihtiyacını bazı durumlarda ortadan kaldırır.
– Sadece bir secret key’e bağlıdır. Birden fazla secret key kullanımına izin vermez.
– Kullanıcı tarafından bağımsız olduğu için gerektiği durumda kullanıcıya çıkış yaptırmak zordur.
– Bir yerde depolanmaları gerekir. Bu localStorage ya da sessionStorage olabilir.
Bu ve bunun gibi birçok avantaj ve dezavantaj sunulabilir. Bunun yanı sıra güvenlik konusunda nerelerde iyi, nerelerde kötü olduğu üzerine tartışılabilir.
Özeleyecek olursak, IEFT’nin bu standardı, yapı bakımından bir standart üzerine kurulduğu için güven veriyor ancak standart üzerinde gelmesi yanında, iyi yapılandırma ve üzerinde düşünme gerektirmesi gibi gereksinimleri de getiriyor. Bu bakımdan, JWT kullanımı öncesinde JWT’yi iyi anlamak ve buna göre karar kılmakta fayda olacaktır.