1- > JWT – JSON Web Token Nedir ?
IETF kuruluşu tarafından tasarlanmış bir token mekanızmasıdır. Detaylar için : RFC 7519
Birbirleriyle haberleşen iki veya daha fazla sistem üzerinde kullanıcı doğrulama, kullanıcının aynı kişi olup olmadığının bilinmesi için kullanılır. Yetkilendirme Mekanızmasında çokça kullanılan bu yapı da kullanıcı bir kez oturum açtığında, bunu takip eden her istek JWT içeriyor olacak ve bu tokenla kullanıcı sistemde erişimi olan yerlere giriş sağlayabilecek.
JWT Token yapısı aşağıdaki resim gibidir. Claims dediğimiz aslında payload. Burada 3 ‘ünü ayıran özellik “.” işaretidir.
1-> Header : Şifreleme Algoritmasında ne kullanılacağını belirlediğimiz yapıdır. Yukarıdaki resimde de görüldüğü üzere ilk “.” ‘ya kadar olan kısımdır. Örnek olarak aşağıdaki gibidir.
{
“alg”: “HS256”, -> Hangi hashleme alg. kullanılacağı.(//jwt.io/ kısmında debug içerisinde farklı hash şifrelerle kontrol sağlanabilir.)
“typ”: “JWT” -> Tipi
}
2-> Payload : 2. Nokta ‘ya kadar olan kısımdır.
Payload, giriş yapan kullanıcının bilgilerini örneğin kullanici id, kullanici adi ve kullanıcının yönetici kullanıcı olup olmadığı hakkındaki bilgileri içerir. JWT Token ları encrypt edilmediği için herhangi bir base64 kod çözücü ile decode edilebilir, bu nedenle payload içinde hassas bilgiler bulunmamalıdır.
Üç tür payload vardır: reserved, public, and private talep.
- Reserved (Ayrılmış) claim’ler: Önceden tanımlanmış claim’lerdir. Kullanılması zorunlu değildir fakat önerilir. Bunlardan bazıları: iss (issuer) (yayınlayıcı), exp(expiration time) (son kullanım zamanı), sub (subject) (konu), aud (audience) (hedef kitle) ve diğerleridir.
- Public (Açık) claim’ler: İsteğe göre eklenen alanlardır. Fakat rezerve edilmiş IANA JSON Web Token kayıtları veya URI’da tanımlanan parametreler ile kullanımın çakışmasından kaçınılmalıdır.
- Private (Gizli) claim’ler: Bilgi paylaşımı için tarafların kendi aralarında anlaştığı özel claim’lerdir.
Örnek bir yapı :
{
“sub”: “1111”,
“name”: “Ümit KÖSE”,
“iat”:1422779638 -> iat, anahtarın oluşturulma zamanını içeren bilgiyi taşır ve JWT’de önerilen bir kullanımdır.
}
3-> Signature : Sunucunun imzası, 2. “.” ‘dan sonraki alan, kalan son kısımdır. Signature kısmınının oluşması için, base64 ile encodlanmış header, base64 ile encodlanmış payload ve belirlenen bir secret key’ e gereklidir. Sonrasında imza oluşturmak için header’da tanımlanan hashleme algoritması kullanılır.
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
(256 Bitlik Secret Key)
)
//jwt.io/ -> Debug kısmında daha detaylı inceleyebilirsiniz.
Avantajlar
- JWT’ler durumsuz (stateless) oldukları için kullanıcı durumlarının elde edilmesi için veritabanı sorgulamasına gerek kalmaz.
- Oturum yönetimi, çerezler kullanılmaksızın yapılabilir.
- Tek bir anahtar, birden fazla arka uçta (backend) kullanılabilir.
- Veritabanı sorgulaması ya da dosya sistemi kullanımı gerektirmediği için performanslıdır.
- CSRF ataklarına karşı daha kapalı olması
- Hızlı doğrulama yapılabilmesi
- Kolay ölçeklenebilir olması
- Web uygulamaları açısından HTTP session gerekmemesi, stateless kullanıma uygun olması
- Veri bütünlüğünü sağlaması
Dezavantajlar
- JWT’ler durumsuz oldukları için, sunucuda durum tutulmadığı sürece anahtarları gerektiğinde geçersiz kılmanın bir yolu yoktur.
- JWT gizli anahtarı yeterince güçlü değil ise, kırılması daha kolay olur.
Standart etiketler
Aşağıda JWT’nin IETF taslağında belirtilen, JWT’nin payload kısmında doğrulama amacıyla kullanılabilecek, önerilen standart etiketler bulunmaktadır:
| etiket | isim | açıklama |
| iss | Verici (“issuer”) | JWT’yi oluşturan/veren kuruluşun adı. |
| sub | Alıcı (“subject”) | JWT’nin alıcısını belirten eşsiz değer. |
| aud | Hedef kitle (“audience”) | JWT’yi yürütecek tarafı belirten değer. Eğer değer yürütmeciyle eşleşmiyorsa JWT reddedilir. |
| exp | Bitiş zamanı (“expiration”) | JWT’nin hangi süreye kadar geçerli olduğunu belirten değer. Sayısal formatta olmalıdır.[3] |
| nbf | Öncesi olamaz (“not before”) | JWT’nin hangi süreden önce geçerli olamayacağını belirtir. Sayısal formatta olmalıdır. |
| iat | Oluşturulma zamanı (“issued at”) | Anahtarın oluşturulma zamanını içeren bilgiyi taşır. Sayısal formatta olmalıdır. |
| jti | JWT ID | Büyük/küçük harfe duyarlı, JWT’yi tanımlayan eşsiz anahtar kodu. |
Kullanım
Kimlik doğrulaması sırasında, kullanıcının gönderdiği bilgiler de doğrulandıysa bir anahtar (token) oluşturulup kullanıcıya döndürülür ve bu lokalde saklanır (örneğin çerezler ya da web storage).
Kullanıcı doğrulaması gerektiren durumlarda, istemci tarafından sunucuya Bearer şemasına sahip Authorization header’ı gönderilir. Header içeriği aşağıdaki gibi görünecektir:
Authorization: Bearer JWTTOKEN
Bu durumsuz (stateless) kimlik doğrulama yöntemidir ve kullanıcı durumu asla sunucu belleğine kaydedilmez. Sunucu daima Authorization header’ından gönderilen JWT’nin geçerli olup olmadığını kontrol eder ve geçerliyse kullanıcının korumalı kaynaklara erişmesine izin verilir. Tüm bilgiler JWT’nin içerisinde olduğundan veritabanının birden fazla sorgulanma ihtiyacını azaltır.
Sunucu ‘ya kullanıcı adı ve şifre ile client request yapar. Yapmış olduğu request sonucunda eğer kullanıcı adı ve şifre doğru ise server bir token ‘ı client ‘ta geri döndürür. Client almış olduğu jwt token ‘ı server ‘a http header içerisinde yollar ve sunucu eğer token doğru ise data ‘yı değilse http 401 ‘i döner. (http 401 -> Unauthorized (Yetkisiz Kullanıcı) hatasıdır.)
