Modern bir Tek Sayfalı Uygulamaya (React veya Vue gibi) veya mobil uygulamaya giriş yaptığınızda, sunucunun kim olduğunuzu hatırlaması için bir yola ihtiyacı vardır. Geleneksel olarak bunu, sunucudaki büyük bir veritabanına bir "oturum kimliği" depolayarak ve tarayıcınıza bir çerez bırakarak yapıyordu. Bir düğmeye her tıkladığınızda, sunucunun bu kimliği veritabanında araması gerekiyordu. Buna durum bilgisi olan kimlik doğrulama denir.
Ancak mikro hizmetler ve bulut ölçeklendirme çağında veritabanları bir darboğaz haline geldi. Bu sorunu çözmek için geliştiriciler, JSON Web Tokens (JWT) aracılığıyla Durum Bilgisiz Kimlik Doğrulamayı benimsedi. JWT ile sunucunun sizin kim olduğunuzu hatırlamasına gerek yoktur; tarayıcınız sunucuya tam olarak kim olduğunuzu söyler ve bunu kanıtlamak için kriptografiyi kullanır.
Bir JWT'nin Anatomisi
Modern bir uygulamada oturum açtıktan sonra ağ trafiğini incelerseniz, muhtemelen bir "Yetkilendirme: Taşıyıcı" başlığını ve ardından iki noktayla ayrılmış uzun, rastgele görünümlü bir karakter dizisi görürsünüz. Bu bir JWT'dir.
Bir JWT tam olarak üç bölümden oluşur: Header.Payload.Signature.
1. Başlık
İlk bölüm, yalnızca belirteci tanımlayan Base64URL kodlu bir JSON nesnesidir. Genellikle iki özellik içerir: belirtecin türü (JWT) ve kullanılan imzalama algoritması (HMAC SHA256 veya RSA gibi).
2. Yük (İddialar)
Orta kısım da Base64URL kodlu bir JSON nesnesidir. Gerçek verilerin yaşadığı yer burasıdır. Bu veri parçalarına "iddialar" denir. Örneğin, Kullanıcı Kimliğinizi, rolünüzü (ör. "Yönetici") ve süre sonu zaman damgasını içerebilir. Bu veri her isteğe eklendiğinden, sunucu bir veritabanını sorgulamadan anında kim olduğunuzu bilir.
KRİTİK UYARI: Yük yalnızca kodlanmıştır, şifrelenmiş değildir. Bir JWT'yi yakalayan herkes kolaylıkla kodunu çözebilir ve yükü okuyabilir. Parolaları, sosyal güvenlik numaralarını veya hassas verileri asla bir JWT verisi içinde saklamayın.
3. İmza
Eğer herhangi biri veriyi okuyup düzenleyebiliyorsa, kötü niyetli bir kullanıcının rolünü "Kullanıcı" yerine "Yönetici" olarak değiştirmesini engelleyen nedir? sorunun cevabı "İmza" dır.
İmzayı oluşturmak için sunucu, Başlığı, Yükü ve son derece güvenli bir Gizli Anahtarı (yalnızca sunucu tarafından bilinir) alır ve bunları bir şifreleme algoritması (SHA256 gibi) aracılığıyla çalıştırır. Ortaya çıkan karma İmza olur.
Sunucu, istemciden bir jeton geri aldığında, imzayı Gizli Anahtarını kullanarak yeniden hesaplar. Kullanıcı veri yüküne müdahale ederse (tek bir harfi bile değiştirse), yeniden hesaplanan imza jetondaki imzayla eşleşmez ve sunucu, sahtekarlık gerekçesiyle isteği anında reddeder.
Tokenları Güvenle İnceleyin
Uygulamanızda hata ayıklamak için JWT'nin yükünü okumanız mı gerekiyor? Hassas jetonunuzu uzak bir sunucuya göndermeden talepleri anında incelemek için çevrimdışı JWT kod çözücümüzü kullanın.
JWT Kod Çözücüyü açınMikro Hizmetler JWT'leri Neden Seviyor?
Netflix gibi bir şirket düşünün. Bir Kimlik Doğrulama sunucusu, bir Video Akışı sunucusu ve bir Faturalandırma sunucusu var. Geleneksel oturumlar kullanılsaydı, her bir sunucunun, bir kullanıcının oturum açıp açmadığını kontrol etmek için sürekli olarak merkezi bir veritabanıyla iletişim kurması gerekirdi.
JWT'lerde Kimlik Doğrulama sunucusu, belirteci özel bir anahtar kullanarak imzalar. Kullanıcı daha sonra bu jetonu doğrudan Video sunucusuna iletir. Video sunucusunun ortak anahtarı olduğundan imzayı bağımsız olarak doğrulayabilir. Video sunucusu, Kimlik Doğrulama sunucusuyla veya bir veritabanıyla konuşmadan kullanıcının tam olarak kim olduğunu bilir. Bu, altyapının darboğazlar olmadan sonsuz şekilde ölçeklendirilmesine olanak tanır.
Karanlık Taraf: Tokenların Geçersiz Kılması
JWT'ler mükemmel değildir. En büyük güçleri (vatansız olmaları) aynı zamanda en büyük zayıflıklarıdır. Sunucu etkin belirteçlerin kaydını tutmadığından, bir kullanıcının oturumunu kolayca kapatamaz veya belirli bir belirteci süresi dolmadan geçersiz kılamazsınız.
Bir bilgisayar korsanı, kullanıcının JWT'sini çalarsa, bilgisayar korsanı, belirtecin son kullanma tarihi dolana kadar tam erişime sahip olur. Bu riski azaltmak için güvenlik mühendisleri iki jetonlu bir sistem kullanır:
- Erişim Jetonları: API istekleri için kullanılan kısa ömürlü JWT'ler (ör. 15 dakika).
- Jetonları Yenile: Güvenli bir şekilde saklanan uzun ömürlü, durum bilgisi olan jetonlar, yalnızca yeni Erişim Jetonları istemek için kullanılır. Bir hesabın güvenliği ihlal edilirse, sunucu Yenileme Simgesini iptal eder ve bilgisayar korsanının Erişim Simgesi doğal olarak 15 dakika içinde ölecektir.
Sıkça Sorulan Sorular (SSS)
JWT'yi ön uçta nerede saklamalıyım?
JWT'leri localStorage'da depolamak onları Siteler Arası Komut Dosyası Çalıştırma (XSS) saldırılarına karşı savunmasız hale getirir. Bir JWT'yi bir web tarayıcısında depolamak için en güvenli yer, JavaScript'in ona erişmesini engelleyen HttpOnly çerezinin içidir.
Sunucumun Gizli Anahtarı sızdırılırsa ne olur?
Felaket. Bir bilgisayar korsanı HMAC gizli anahtarınızı veya RSA özel anahtarınızı ele geçirirse, istediği herhangi bir veri yüküyle geçerli JWT'ler oluşturabilir. Kendilerine "Süper Yönetici" ayrıcalıkları veren jetonlar oluşturabilirler ve sunucunuz bunları geçerli olarak kabul eder. Anahtarlarınızı hemen döndürmeniz gerekir.
JWT'ler oturum çerezlerinden daha mı hızlı?
Mutlaka değil. JWT'ler dosya boyutu açısından 32 karakterlik oturum kimliğinden önemli ölçüde daha büyüktür; bu, her istekte daha fazla ağ bant genişliği tükettikleri anlamına gelir. Hız avantajları tamamen arka uçtaki veritabanı aramalarının atlanmasından kaynaklanmaktadır.