JWT ile Kimlik Doğrulama Nedir? Güvenli Kullanım Rehberi

JWT (JSON Web Token), iki taraf arasında kimlik ve yetki bilgisini güvenli biçimde taşımak için kullanılan kompakt bir token formatıdır. Özellikle web API'lerinde, mobil uygulamalarda ve servisler arası iletişimde yaygın olarak kullanılır. Doğru uygulandığında pratik ve ölçeklenebilirdir; yanlış uygulandığında ise ciddi güvenlik açıklarına yol açabilir.

JWT'nin yapısı

Bir JWT, noktayla ayrılmış üç parçadan oluşur:

header.payload.signature

• Header: Token türü ve imza algoritması.
• Payload: Kullanıcı kimliği, roller, geçerlilik süresi gibi bilgiler (claim'ler).
• Signature: Header ve payload'un gizli anahtar veya özel anahtarla imzalanmış hali. Token'ın değiştirilmediğini doğrular.

Önemli: Payload şifrelenmez, yalnızca Base64URL ile kodlanır. Herkes içeriğini okuyabilir. Bu nedenle parola, kimlik numarası veya hassas kişisel veri JWT içine konmamalıdır.

Kimlik doğrulama akışı

1. Kullanıcı kullanıcı adı ve parolasıyla giriş yapar.
2. Sunucu bilgileri doğrular ve imzalı bir access token üretir.
3. İstemci sonraki isteklerde token'ı Authorization: Bearer <token> başlığıyla gönderir.
4. API, her istekte imzayı ve süreyi doğrular; veritabanına oturum sorgusu yapmadan kullanıcıyı tanır.

Bu "durumsuz" (stateless) yapı, API'lerin yatay ölçeklenmesini kolaylaştırır.

Access token ve refresh token

• Access token: Kısa ömürlü olmalıdır (örneğin 5–15 dakika). Çalınırsa kötüye kullanım süresi kısa kalır.
• Refresh token: Daha uzun ömürlüdür ve yalnızca yeni access token almak için kullanılır. Sunucu tarafında kaydedilip iptal edilebilir olmalıdır.

Refresh token rotasyonu: Her kullanımda yeni bir refresh token verip eskisini geçersiz kılmak, çalınan token'ların tespit edilmesini kolaylaştırır.

Token nerede saklanmalı?

Web uygulamalarında token saklama tartışmalı bir konudur:

• localStorage: Kullanımı kolaydır ancak XSS saldırısında JavaScript ile okunabilir.
• HttpOnly, Secure, SameSite çerez: JavaScript tarafından okunamaz; XSS'e karşı daha dayanıklıdır. CSRF riskine karşı SameSite ayarı ve gerekirse CSRF token kullanılmalıdır.

Tarayıcı tabanlı uygulamalarda refresh token'ı HttpOnly çerezde tutmak yaygın ve güvenli bir yaklaşımdır. Mobil uygulamalarda ise işletim sisteminin güvenli depolama alanları kullanılmalıdır.

ASP.NET Core'da temel yapılandırma

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(o =>
    {
        o.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidAudience = builder.Configuration["Jwt:Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]!))
        };
    });

İmza anahtarı yeterince uzun ve rastgele olmalı, kaynak kodunda değil güvenli yapılandırmada saklanmalıdır. Endpoint tarafı için Minimal API rehberi yazımıza bakabilirsiniz.

Sık yapılan güvenlik hataları

1. İmzayı veya süreyi doğrulamamak. Tüm doğrulama parametreleri açık olmalıdır.
2. Zayıf veya sabit anahtar kullanmak. Tahmin edilebilir anahtarlar token üretilmesine izin verir.
3. Algoritmayı token'dan okumak. Sunucu kabul ettiği algoritmayı kendisi belirlemelidir; "none" algoritması asla kabul edilmemelidir.
4. Çok uzun ömürlü access token. Günlerce geçerli token'lar risklidir.
5. Hassas veriyi payload'a koymak.
6. Çıkışta hiçbir şey yapmamak. Refresh token'ı sunucuda iptal edin.
7. HTTPS kullanmamak. Token'lar mutlaka şifreli bağlantıyla taşınmalıdır. Bkz. SSL sertifikası nedir.

JWT her zaman doğru seçim mi?

Tek bir sunucu tarafından render edilen klasik web uygulamalarında çerez tabanlı oturum yönetimi daha basit ve yeterli olabilir. JWT; API'ler, mobil istemciler ve birden fazla servisin aynı kimliği doğrulaması gereken senaryolarda öne çıkar. Hesap güvenliğini artırmak için iki faktörlü doğrulama ile birlikte kullanılması önerilir.

Sık sorulan sorular

JWT'yi sunucudan iptal edebilir miyim?

Access token kendi başına iptal edilemez; süresi dolana kadar geçerlidir. Bu yüzden kısa süre ve iptal edilebilir refresh token kullanılır. Kritik durumlar için bir engel listesi de tutulabilir.

Simetrik mi, asimetrik mi imza?

Token'ı üreten ve doğrulayan aynı sistemse simetrik (HMAC) yeterlidir. Birden fazla servis doğrulayacaksa asimetrik (RSA, ECDSA) imza, özel anahtarın tek yerde kalmasını sağlar.

Sonuç

JWT, API güvenliğinde güçlü ve esnek bir araçtır; ancak güvenliği doğru yapılandırmaya bağlıdır. Kısa ömürlü access token, iptal edilebilir refresh token, güvenli saklama ve tam doğrulama temel kurallardır. API güvenliği ve kimlik doğrulama altyapısı için iletişime geçebilirsiniz.