JWT (JSON Web Token) Nedir? Modern Kimlik Doğrulamanın Altın Anahtarı
Modern web uygulamalarında kimlik doğrulama (authentication), kullanıcı deneyimi ve güvenlik arasındaki hassas dengenin kurulduğu en kritik noktadır. Eskiden sunucu taraflı oturumlar (session-based) standartken, dağıtık sistemlerin ve mikroservis mimarilerinin yükselişiyle birlikte Stateless (Durumsuz) çözümlere olan ihtiyaç arttı. İşte bu noktada sahneye JSON Web Token (JWT) çıkıyor.
Peki, JWT tam olarak nedir ve neden "modern kimlik doğrulamanın altın anahtarı" olarak anılıyor? Gelin, bu token'ın anatomisini ve güvenli kullanımını derinlemesine inceleyelim.
JWT Nedir?
JWT (RFC 7519), taraflar arasında bilgilerin JSON nesnesi olarak güvenli bir şekilde iletilmesini sağlayan açık bir standarttır. Bu bilgi "imzalı" olduğu için doğrulanabilir ve güvenilirdir. JWT'ler genellikle Authorization (Yetkilendirme) ve Information Exchange (Bilgi Alışverişi) senaryolarında kullanılır.
En yaygın senaryo şudur: Kullanıcı giriş yapar, sunucu bir JWT üretir ve bunu istemciye (client) gönderir. İstemci, sonraki her isteğinde bu token'ı sunucuya sunarak "Ben kimim" sorusunun cevabını verir. Sunucu ise veritabanına gitmeye gerek kalmadan token'ın imzasını kontrol ederek kullanıcının kimliğini doğrular.
JWT Anatomisi
Bir JWT, noktalarla (.) ayrılmış üç ana bölümden oluşur:
- Header (Başlık)
- Payload (Yük/Veri)
- Signature (İmza)
Görünümü şöyledir: xxxxx.yyyyy.zzzzz
1. Header
Token'ın türünü (JWT) ve kullanılan imzalama algoritmasını (örneğin HMAC SHA256 veya RSA) belirtir.
{
"alg": "HS256",
"typ": "JWT"
}
2. Payload
Token'ın taşıdığı asıl veridir. Burada "claim" adı verilen ifadeler bulunur. Claim'ler üç türe ayrılır:
- Registered Claims: Standartlaştırılmış alanlar (
iss(issuer),exp(expiration time),sub(subject) vb.). - Public Claims: IANA JSON Web Token Registry'de tanımlanan veya çakışmayı önleyecek şekilde adlandırılan alanlar.
- Private Claims: Taraflar arasında özel olarak tanımlanan alanlar (örneğin
userId,role).
{
"sub": "1234567890",
"name": "Enginhan Zengin",
"role": "admin",
"iat": 1516239022
}
Dikkat: Payload base64 ile kodlanır ancak şifrelenmez. Bu nedenle, payload içerisine asla şifre gibi hassas bilgiler koymamalısınız. Token'ı ele geçiren herkes payload içeriğini okuyabilir.
3. Signature
Token'ın bütünlüğünü doğrulamak için kullanılır. Header ve Payload'ın kodlanmış halleri, bir "secret" (gizli anahtar) ve Header'da belirtilen algoritma kullanılarak imzalanır.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)
Bu imza, sunucunun "Bu token'ı ben ürettim ve içeriği yolda değiştirilmedi" diyebilmesini sağlar.
Nasıl Çalışır?
- Authentication: Kullanıcı
usernamevepasswordile giriş yapar. - Token Creation: Sunucu bilgileri doğrular ve bir JWT üretir (imzalar).
- Response: JWT istemciye gönderilir.
- Storage: İstemci token'ı saklar (Genellikle LocalStorage veya HttpOnly Cookie).
- Request: İstemci, korumalı bir kaynağa erişmek istediğinde token'ı
Authorizationheader'ındaBearer <token>şemasıyla gönderir. - Verification: Sunucu token'ın imzasını ve süresini (
exp) kontrol eder. Geçerliyse isteği işler.
Neden JWT? (Session vs Token)
| Özellik | Session-Based (Oturum Tabanlı) | Token-Based (JWT) |
|---|---|---|
| Durum (State) | Stateful. Sunucu oturum bilgisini bellekte veya veritabanında tutar. | Stateless. Token gerekli tüm bilgiyi taşır, sunucu durum tutmaz. |
| Ölçeklenebilirlik | Zor. Yük dengeleyici (Load Balancer) arkasında "Sticky Session" veya ortak Redis gerekir. | Kolay. Herhangi bir sunucu token'ı doğrulayabilir. |
| Mobil Uyumluluk | Cookie yönetimi mobilde zor olabilir. | Token'lar her platformda (Mobil, Web, IoT) kolayca kullanılır. |
| Performans | Her istekte veritabanı/cache sorgusu gerekebilir. | İmza doğrulaması CPU bazlıdır, I/O gerektirmez (hızlıdır). |
Güvenlik İpuçları: "Altın Anahtarı" Korumak
JWT güçlüdür ancak yanlış kullanıldığında ciddi güvenlik açıklarına yol açabilir.
- HTTPS Kullanın: Token'lar hassas veridir. İletişim her zaman şifreli olmalıdır.
- Algoritma Seçimi:
HS256(Simetrik) yerine mümkünseRS256(Asimetrik) kullanın. Private key ile imzalayıp, Public key ile doğrulama yapmak anahtar güvenliğini artırır. - Kısa Ömürlü Tokenlar: Access Token'ların ömrünü kısa tutun (örneğin 15-30 dakika). Uzun oturumlar için Refresh Token mekanizması kullanın.
- Saklama Yeri (Storage):
- LocalStorage: XSS (Cross-Site Scripting) saldırılarına karşı savunmasızdır. JavaScript ile okunabilir.
- HttpOnly Cookie: XSS'e karşı daha güvenlidir çünkü JS ile okunamaz. Ancak CSRF (Cross-Site Request Forgery) koruması gerektirir.
- Öneri: Mümkünse HttpOnly Cookie kullanın.
- "None" Algoritmasını Engelleyin: Bazı kütüphaneler
alg: nonekabul edebilir. Sunucu tarafında bunu kesinlikle reddedin. - Secret Key Güvenliği: İmzalama anahtarınız (Secret) çok karmaşık olmalı ve asla kodun içinde (hardcoded) veya versiyon kontrol sisteminde (git) bulunmamalıdır. Environment variable kullanın.
Sonuç
JWT, modern web geliştirme dünyasında esneklik, performans ve ölçeklenebilirlik sağlayan harika bir araçtır. Ancak "stateless" doğası, güvenlik sorumluluğunu geliştiriciye daha fazla yükler. Doğru kurgulanmış bir JWT mimarisi, uygulamanızın güvenliğinin bel kemiği olabilirken; hatalı bir kurgu, sisteminizi savunmasız bırakabilir.
Unutmayın: En güvenli kod, henüz yazılmamış olandır; ama yazmak zorundaysak, en iyi pratikleri takip etmek boynumuzun borcudur.