JWT Nedir? JSON Web Token ile Kimlik Doğrulama Nasıl Çalışır?

JWT nedir ve ne işe yarar?

JWT (JSON Web Token), iki taraf arasında bir kullanıcı ya da sistem hakkındaki iddiaları kompakt, URL uyumlu ve imzalı bir metin olarak taşıyan açık standarttır. Sunucu imzayı doğrular, böylece içeriğin yolda değişmediğinden emin olur. Standardın tanımı IETF tarafından yayımlanan RFC 7519 belgesinde yer alır.

Basit bir benzetmeyle anlatalım: JWT, üzerinde adınız, yetkiniz ve geçerlilik süreniz yazan mühürlü bir giriş kartıdır. Kapıdaki görevli sizi tanımak zorunda değildir, ancak mühür gerçekse kartı kabul eder. Mühür bozulmuşsa kart geçersizdir.

Bu yüzden ekipler JWT'yi özellikle web arayüzü, mobil uygulama ve API gibi birden fazla parçanın konuştuğu sistemlerde tercih eder. Giriş yaptıktan sonra aldığınız token, sonraki isteklerde "ben kimim ve neye yetkiliyim" sorusunu cevaplar. Sunucu her istekte veritabanına gitmeden bu cevabı doğrulayabilir.

Ancak JWT bir güvenlik sihri değildir. Doğru kurulursa pratik bir taşıma formatıdır, yanlış kurulursa sessiz açıklar üretir. Bu rehberde yapıyı, akışı, riskleri ve kontrol listesini kavramsal düzeyde birlikte inceleyeceğiz.

JWT nedir diye araştıran okurların çoğu iki ayrı grupta toplanır. Bir kısmı yeni başlayan geliştiricidir ve "token" kelimesinin ne anlama geldiğini öğrenmek ister. Diğer kısmı ise mevcut bir sistemin güvenliğini değerlendiren teknik ekiptir. Bu yazı ikisine de hitap etmek için önce sade tanımı, sonra ayrıntıyı verir.

JWT nedir sorusunu günlük hayattan bir örnekle nasıl anlatırız?

Mühürlü, şeffaf bir zarf düşünün. Zarfın içindeki mektubu herkes okuyabilir, çünkü zarf saydamdır. Ama mühür yalnızca zarfı veren kuruma aittir ve kimse mührü taklit edemez. Biri mektubu değiştirirse mühür kopar ve siz değişikliği hemen fark edersiniz.

JWT tam olarak böyle çalışır. İçeriği herkes okuyabilir, yani içerik gizli değildir. Gizli olan şey, imzayı üreten anahtardır; dolayısıyla JWT nedir sorusunun en önemli cevabı "gizlilik değil, bütünlük sağlar" cümlesidir. Bu fark çok önemlidir, çünkü yeni başlayanların en sık düştüğü hata "JWT şifrelidir" varsayımıdır.

Örneğin bir etkinlik bileti, sizin hakkınızda bilgi içerir ve girişteki görevli onu kontrol eder. Biletin sahte olup olmadığını görevli bilet numarasını merkeze sorarak da anlayabilir, mührüne bakarak da anlayabilir. İlk yöntem oturum çerezine, ikinci yöntem JWT yaklaşımına benzer.

JWT nedir ve gerçek hayatta hangi alanlarda kullanılır?

Örnek senaryo: Bir perakende işletmesinin mobil uygulaması, web mağazası ve stok paneli aynı kullanıcı hesabıyla çalışıyor. Kullanıcı bir kez giriş yaptığında kimlik servisi imzalı bir token üretiyor. Sipariş servisi bu tokenı kimlik servisine sormadan doğruluyor. Böylece servisler arasındaki bağımlılık azalıyor ve sistem büyüdükçe yönetmesi kolaylaşıyor.

• Tek oturum açma (SSO): Kullanıcı bir kez giriş yapar, birden fazla uygulamaya geçiş yapar.
• API erişimi: Mobil ve web istemcileri her isteğe token ekler.
• Servisler arası kimlik: Mikroservisler birbirine kim olduklarını tokenla bildirir.
• Kısa ömürlü, tek amaçlı işlemler: Örneğin bir doğrulama bağlantısının geçerlilik bilgisini taşımak.

Kısacası JWT nedir sorusunun pratik cevabı şudur: kimlik ve yetki bilgisini iki taraf arasında güvenle taşımanın standart yoludur. Ancak her kullanım alanında aynı derecede doğru seçim olmadığını ilerleyen bölümlerde birlikte göreceğiz.

JWT'nin başlık, yük ve imza bölümleri nedir?

Bir JWT üç parçadan oluşur ve nokta işareti parçaları birbirinden ayırır. Kavramsal görünüm "başlık.yük.imza" şeklindedir. Sistem her parçayı base64url denen, URL için güvenli bir kodlamayla yazar. Bu kodlama bir şifreleme değildir, yalnızca veriyi metne çevirir ve herkes geri çevirebilir.

• Başlık: Token tipini ve imza algoritmasını anlatan küçük bir JSON nesnesidir.
• Yük: İddiaları, yani token sahibine ve tokenın kullanımına dair bilgileri taşıyan JSON nesnesidir.
• İmza: Başlık ile yükün bir anahtarla imzalanmasıyla üretilen, bütünlüğü kanıtlayan değerdir.

Sunucu imzayı yeniden hesaplar ve gelenle karşılaştırır. Eşleşme yoksa başlık ya da yük değişmiştir ve sunucu tokenı reddeder. Güvenlik tamamen bu karşılaştırmaya dayanır; dolayısıyla imzayı doğrulamayan bir sistem JWT'nin güvenlik faydasından yararlanamaz.

Ayrıca başlıktaki algoritma bilgisi tek başına güven kaynağı değildir; bu konuyu güvenlik hataları bölümünde ayrıca ele alacağız.

Not: Bu yazıda bilerek gerçek görünümlü bir token örneği vermiyoruz. Yapıyı anlamak için üç parçalı şemayı hatırlamanız yeterlidir.

JWT yükündeki claim yani iddia alanları nelerdir?

Claim, token sahibi ya da token hakkında öne sürülen tek bir bilgidir. RFC 7519 birkaç standart (kayıtlı) alan tanımlar. Bunların hepsi isteğe bağlıdır, ama pratikte çoğu sistem bir kısmını mutlaka kullanır. Böylece her uygulama aynı kelimelerle aynı anlamı kastetmiş olur.

• iss (issuer): Tokenı kimin ürettiğini belirtir.
• sub (subject): Tokenın kimden bahsettiğini, genellikle kullanıcının kimliğini belirtir.
• aud (audience): Tokenın hangi hizmet için üretildiğini belirtir.
• exp (expiration time): Tokenın bittiği anı belirtir.
• nbf (not before): Tokenın daha önce kabul edilmemesi gereken anı belirtir.
• iat (issued at): Üretildiği anı belirtir.
• jti (JWT ID): Tokena özgü bir tanımlayıcıdır ve tekrar kullanımı izlemede işe yarar.

Bunların yanında kendi özel alanlarınızı da ekleyebilirsiniz, örneğin kullanıcı rolü. Ancak yük küçük kalmalıdır, çünkü token her istekte başlıkla birlikte gider. Ayrıca özel alanlarda hassas veri tutmayın; nedenini ilerleyen bölümde göreceğiz.

JWT imzası nasıl çalışır ve neden her istekte doğrulamalısınız?

İmzalamanın iki temel yolu vardır. Birincisi paylaşılan gizli anahtarla çalışan MAC yöntemidir (örneğin HMAC). Tokenı üreten ve doğrulayan taraf aynı gizli anahtarı bilir. İkincisi asimetrik imzadır: üretici özel anahtarla imzalar, doğrulayıcılar yalnızca herkese açık anahtarı kullanır.

Küçük ve tek servisli bir uygulamada paylaşılan anahtar yeterli olabilir. Birden fazla servis varsa asimetrik imza daha rahattır, çünkü doğrulayan servisler imza üretme gücüne sahip olmaz. Böylece bir servisin ele geçirilmesi tüm sistemin token üretmesi anlamına gelmez.

Doğrulama her istekte yapılmalıdır, çünkü sunucu tokenı bir kez gördü diye ona sonsuza kadar güvenemez. Birileri tokenı cihazda, ağda ya da bir kayıt dosyasında kopyalamış olabilir. İmza, süre ve hedef kitle kontrollerini her gelişte tekrarlarsınız. Gerçek dünyada hesap açma ve ödeme gibi hassas adımlarda bu kontrollerin atlanması en pahalı hatadır.

Anahtar yönetimi ve anahtar döndürme neden önemlidir?

İmza anahtarı sızarsa, anahtara sahip herkes sizin adınıza geçerli token üretebilir. Bu yüzden anahtarı kod deposunda, istemci uygulamasında ya da düz metin ayar dosyalarında tutmayın. Gizli bilgi yönetimi için tasarlanmış bir depo kullanın ve erişimi sınırlayın.

Anahtarları düzenli aralıklarla yenilemek (anahtar döndürme) de iyi bir alışkanlıktır. Token başlığındaki bir anahtar tanımlayıcı (kid), hangi anahtarın kullanıldığını söyler. Doğrulayan taraf, geçiş döneminde hem eski hem yeni anahtarı kabul eder. Herkese açık anahtarların yayımlanması için JWK ve JWKS biçimleri vardır.

Ancak bir uyarı gerekiyor: tokenın başlığı, anahtarı nereden alacağınızı söylese bile ona körü körüne güvenmeyin. OWASP, anahtar bilgisini token başlığından alıp doğrudan kullanmayı ayrı bir tehdit olarak listeler. Güvendiğiniz anahtar kaynaklarını sunucuda önceden tanımlayın.

JWS ile JWE arasındaki fark nedir?

JWT aslında kendi başına bir kapsayıcı değildir; iddia kümesini taşımak için iki yapıdan birini kullanır. JWS (JSON Web Signature, RFC 7515) iddiaları imzalar. JWE (JSON Web Encryption, RFC 7516) iddiaları şifreler. Yani gündelik konuşmada "JWT" dediğimiz şey çoğu zaman imzalı olan JWS biçimidir.

İmzalı JWT bütünlük ve kaynak doğrulaması verir, ama içerik okunabilir kalır. Şifreli JWT ise içeriği yalnızca doğru anahtara sahip tarafa açar. Dolayısıyla yükte gizli kalması gereken bir bilgi varsa imza yetmez; ya o bilgiyi hiç koymamalı ya da şifreli biçim kullanmalısınız.

İkisini iç içe kullanan "iç içe JWT" yapısı da vardır, yani önce imzalayıp sonra şifrelemek gibi. Ancak çoğu işletme uygulamasında en iyi yol, yükü zaten hassas veri taşımayacak şekilde küçük tutmaktır. Bu yaklaşım hem daha sade hem de daha az hata üretir.

JWT nedir, oturum çerezinden farkı ne?

Geleneksel oturum çerezinde sunucu, giriş yapan kullanıcı için kendi tarafında bir kayıt tutar. Sunucu tarayıcıya yalnızca anlamsız bir oturum numarası verir. JWT yaklaşımında bilgi tokenın içindedir ve sunucu çoğu zaman kayıt tutmak zorunda kalmaz. Her iki modelin de güçlü ve zayıf yanları vardır.

Tabloya bakarak "JWT her zaman daha modern" sonucuna varmayın. OWASP JWT Cheat Sheet belgesi, JWT'nin "durumsuz kullanıcı oturumu" için önerilmesine açıkça temkinli yaklaşır. Çünkü iptal ve çıkış yapma gibi ihtiyaçlar sunucu tarafı durum gerektirir. Basit bir web sitesinde sağlam yönetilen oturum çerezi çoğu zaman daha güvenli ve daha az zahmetlidir.

Erişim token'ı ve yenileme token'ı nasıl birlikte çalışır?

Pratikte ekipler tek bir uzun ömürlü token yerine iki token kullanır. İstemci erişim token'ını (access token) API'ye gönderir ve bu token kısa süre yaşar. Yenileme token'ı (refresh token) ise yalnızca yeni erişim token'ı almaya yarar ve daha uzun süre yaşar. Böyle bir ayrım, çalınan bir erişim token'ının zararını sınırlar. JWT nedir sorusunu akış düzeyinde anlamak isteyenler için en kritik kavram budur.

1. Kullanıcı kimlik bilgileriyle ya da passkey ile giriş yapar.
2. Kimlik sunucusu bir erişim token'ı ve bir yenileme token'ı üretir.
3. İstemci erişim token'ını API isteklerine ekler.
4. Erişim token'ının süresi dolunca API isteği reddeder.
5. İstemci yenileme token'ını kimlik sunucusuna gönderir ve yeni bir erişim token'ı alır.
6. Kullanıcı çıkış yapınca ya da şüpheli durumda kimlik sunucusu yenileme token'ını iptal eder.

Burada kritik nokta, yenileme token'ının sunucu tarafında izlenebilmesidir. Böylece iptal edebilir, kullanım sayısını izleyebilir ve çalındığına dair işaret görürseniz tüm zinciri kapatabilirsiniz. Süre değerlerini rakam olarak sabitlemiyoruz; bu değerleri uygulamanızın risk düzeyine göre ve güncel kılavuzlara bakarak belirleyin.

Sunucu gelen bir JWT'yi hangi kontrollerle kabul eder?

Doğrulama tek bir "imza tamam" kontrolünden ibaret değildir. RFC 8725 (JWT için güncel en iyi uygulamalar) ve OWASP belgeleri birden fazla kontrolü birlikte önerir. Bunlardan biri eksik kalırsa token geçerli gibi durur ama yanlış yerde kabul edilebilir.

1. Tokenın üç parçalı yapıda olduğunu ve düzgün çözülebildiğini kontrol edin.
2. Beklediğiniz imza algoritmasını sunucuda sabitleyin; tokenın başlığındaki seçime körü körüne uymayın.
3. İmzayı doğru anahtarla doğrulayın.
4. exp ve nbf alanlarına göre süreyi denetleyin.
5. iss alanının güvendiğiniz üretici olduğunu doğrulayın.
6. aud alanının sizin servisinizi içerdiğini doğrulayın.
7. Gereken yetkinin tokenda bulunduğunu kontrol edin ve asıl yetkilendirme kararını sunucuda verin.

Kısacası, imza "bu token değişmedi" der. Süre, üretici ve hedef kitle kontrolleri ise "bu token şimdi, burada ve bu iş için geçerli mi" sorusunu cevaplar. İkisini birlikte yaptığınızda JWT sağlam bir taşıyıcıya dönüşür.

JWT tarayıcıda nerede saklanmalıdır?

Saklama kararı, JWT güvenliğinin en tartışmalı konusudur. Kesin bir tek doğru yoktur, ama riskler bellidir. Sayfadaki bir betik tarafından okunabilen bir depoya konan token, sayfaya zararlı kod sızarsa (XSS) çalınabilir. Çerezlerde ise başka bir sorun vardır: tarayıcı çerezi otomatik gönderdiği için sahte istek riskine (CSRF) karşı ayrı önlem gerekir.

Genel olarak tarayıcıya yazılan token için çoğu ekip HttpOnly, Secure ve uygun SameSite ayarlı bir çerez tercih eder, çünkü betikler bu çerezi okuyamaz. Çerez özellikleri için MDN çerez belgesi iyi bir birincil kaynaktır. Mobil uygulamalarda ise işletim sisteminin güvenli depolama alanını kullanırsınız.

Hangi yolu seçerseniz seçin, iki ilke geçerlidir. Birincisi, XSS açıklarını kapatmak zorundasınız, çünkü bu açık varsa hiçbir saklama yöntemi tam koruma vermez. İkincisi, erişim token'ını kısa ömürlü tutarak olası bir sızıntının etkisini azaltırsınız. Web güvenliğinin genel çerçevesi için OWASP Top 10 rehberimize göz atabilirsiniz.

JWT kullanırken en sık yapılan güvenlik hataları nelerdir?

Ekiplerin sahada en çok gördüğü hatalar şaşırtıcı biçimde basittir. Bunların çoğu kütüphanenin değil, kütüphaneyi kullanış biçiminin sonucudur. Aşağıdaki liste, bir denetim yaparken ilk bakacağınız yerleri özetler.

• Yükte hassas veri tutmak, çünkü yük şifreli değildir.
• İmzayı hiç doğrulamamak ya da yalnızca çözüp içeriğe güvenmek.
• Algoritma seçimini tokenın kendisine bırakmak ve anahtar türünü karıştırmak.
• Süresiz ya da çok uzun ömürlü token üretmek.
• Tokenı tarayıcıda betiklerin okuyabildiği bir yerde saklamak.
• iss ve aud kontrollerini atlamak.
• Çıkış yapma ve iptal senaryosunu hiç tasarlamamak.
• İmza anahtarını kod deposuna, kayıt dosyalarına ya da istemci tarafına koymak.

Bu maddelerin her birini aşağıdaki bölümlerde ayrı ayrı ele alıyoruz. Genel saldırı yüzeyini daha geniş görmek isterseniz yetkisiz erişim hatasını anlatan 401 Unauthorized yazımıza da bakabilirsiniz.

JWT yüküne neden hassas veri koymamalısınız?

Yük yalnızca kodlanmıştır, şifrelenmemiştir. Tokenı eline geçiren herkes, hiçbir anahtara ihtiyaç duymadan yükü okuyabilir. Bu kişi bir saldırgan olabileceği gibi, tokenın geçtiği bir proxy, bir kayıt sistemi ya da tarayıcıdaki bir eklenti de olabilir.

Dolayısıyla parola, kart bilgisi, sağlık bilgisi, açık adres ya da kimlik numarası gibi veriler yükte yer almamalıdır. Yükte kullanıcı numarası, rol ve süre gibi minimum bilgi yeterlidir. Gerisi için sunucu, kullanıcı numarasıyla kendi veritabanına bakar.

Kişisel veri işleyen sistemlerde bu konu aynı zamanda mevzuat meselesidir. Veri minimizasyonu ilkesi, gereksiz veriyi hiç taşımamayı önerir. Bu yazı hukuki danışmanlık değildir; bu konuda KVKK ve GDPR uyumlu web sitesi rehberimizi okuyup hukuk danışmanınıza başvurun.

İmza doğrulanmazsa ya da algoritma karışırsa ne olur?

İmza doğrulanmazsa token yalnızca düz bir metindir ve kimse tarafından kolayca değiştirilebilir. Rol bilgisini değiştirmek, başka kullanıcının numarasını yazmak gibi senaryolar mümkün hale gelir. Bu hata genellikle "çözüp bakmak yeterli" diye düşünen hızlı bir prototip canlıya çıkarken ortaya çıkar.

Algoritma karışıklığı ise biraz daha incedir. Token başlığı, hangi algoritmayla imzalandığını söyler. Sunucu bu bilgiye körü körüne uyarsa, saldırgan sunucunun beklemediği bir yöntemi seçtirebilir. Standart ayrıca imzasız ("unsecured") JWT biçimini de tanımlar. Bu biçim yalnızca imza dışında bir güvencenin bulunduğu özel durumlar içindir; kullanıcı girişi için asla kabul etmemelisiniz.

Savunma basittir: kabul edeceğiniz algoritmaları sunucuda sabit bir liste olarak tanımlayın, anahtar türünü algoritmayla eşleştirin ve bakımı yapılan, güncel bir kütüphane kullanın. Ayrıntılı ve resmi öneriler için RFC 8725 belgesini inceleyin.

Süresiz token ve iptal sorunu nasıl çözersiniz?

İmzalı bir JWT, süresi dolana kadar geçerlidir ve sunucu varsayılan olarak onu "geri çağıramaz". Bu nedenle süresiz token en tehlikeli tercihtir: çalınırsa sonsuza kadar kullanılabilir. Her token bir bitiş zamanı taşımalıdır ve siz bu süreyi erişim token'ı için kısa tutarsınız.

Yine de bazı durumlarda tokenı süre dolmadan geçersiz kılmanız gerekir. Örneğin kullanıcı çıkış yapar, parolasını değiştirir ya da hesabını kapatır. OWASP belgesi bunun için başlıca şu yaklaşımları sayar: iptal ettiğiniz token'ların listesini tutmak (denylist), token durum listesi kullanmak ve yenileme token'larını sunucu tarafında izlemek.

Dolayısıyla "tamamen durumsuz" hayali ile "anında iptal" ihtiyacı çatışır. Çoğu gerçek uygulama ikisi arasında bir denge kurar: kısa ömürlü erişim token'ı, sunucuda izlenen yenileme token'ı ve kritik işlemlerde ek doğrulama. İptal gereksinimi çok güçlüyse, sunucu tarafı oturum modeli daha dürüst bir çözümdür.

JWT, OAuth 2.0 ve OpenID Connect ile nasıl ilişkilidir?

Çoğu kişi bu üç terimi karıştırır, oysa terimler farklı katmanlardadır. JWT bir veri formatıdır. OAuth 2.0 yetkilendirme çerçevesidir; bir uygulamanın başka bir hizmete sizin adınıza sınırlı erişimini düzenler. OpenID Connect ise OAuth 2.0 üzerine kurulu bir kimlik katmanıdır ve kullanıcının kim olduğunu bildirir.

Yani "Google ile giriş" gibi bir akışta arka planda OpenID Connect çalışır ve kimlik token'ı JWT olarak gelir. Bu yüzden JWT öğrenmek, modern kimlik sistemlerini okuyabilmek için temel bir adımdır. Yapay zeka maliyetlerinde geçen "token" ise tamamen farklı bir kavramdır; karışıklık yaşarsanız yapay zekada token nedir yazımıza bakın.

JWT ile passkey arasındaki fark nedir?

Passkey, kullanıcının kim olduğunu kanıtlamanın bir yoludur. Parola yerine cihazdaki özel anahtarı ve biyometrik ya da PIN doğrulamasını kullanırsınız. JWT ise kimlik kanıtlandıktan sonra bu sonucu bir sonraki isteklere taşıyan kanıttır. Yani biri "kim olduğumu nasıl kanıtlarım" sorusunu, öteki "bu kanıtı nasıl taşırım" sorusunu cevaplar.

Bu iki teknoloji birbirinin rakibi değildir; birlikte çalışırlar. Kullanıcı passkey ile giriş yapar, sunucu da başarılı girişin ardından kısa ömürlü bir token ya da oturum üretir. Passkey'in kendisini ayrıntılı öğrenmek isterseniz passkey nedir yazımızı okuyabilirsiniz.

Örnek senaryo: Bir mobil uygulamada kullanıcı passkey ile girer. Uygulama arka planda kısa ömürlü bir erişim token'ı alır. Giriş yöntemi parolasızdır, ama istekler arasındaki taşıma işini yine token üstlenir.

JWT ne zaman doğru seçimdir, ne zaman değildir?

JWT'nin güçlü olduğu yerler belli: birden fazla servisin aynı kimliği bağımsız doğrulaması, mobil uygulama ve API iletişimi, kısa ömürlü yetki taşıma ve tek oturum açma (SSO) senaryoları. Böyle sistemlerde her servisin ortak bir oturum deposuna bağlanmaması büyük kolaylıktır.

• Uygun: Servisler arası kimlik taşıma, kısa ömürlü API erişimi, federasyon ve SSO.
• Dikkatli olun: Uzun süreli kullanıcı oturumu, çıkış yapınca anında kapanması gereken yetki, büyük yük taşıma.
• Gereksiz olabilir: Tek bir sunucuda çalışan klasik web sitesi, basit yönetim paneli.

REST ya da GraphQL API'nizi token ile koruyorsanız, API tasarım kararlarını da gözden geçirin. İlgili bakış açısı için GraphQL ile REST farkı yazımıza göz atın. Gerçek zamanlı bağlantılarda kimlik doğrulama ayrıca düşünülmelidir; bunun için WebSocket rehberimiz yol gösterir.

JWT boyutu ve performansı uygulamanızı nasıl etkiler?

Token her istekle birlikte gider. Yükte ne kadar çok iddia ve yetki listesi varsa, her istek o kadar şişer. Bu durum ağ trafiğini artırır ve bazı sunucuların ya da ara katmanların üst bilgi sınırlarına takılma riskini doğurur. Dolayısıyla yetkilerin tümünü tokenın içine doldurmak çoğu zaman kötü bir fikirdir.

Daha iyi yaklaşım, yükte yalnızca kimlik, rol ve süre gibi temel alanları tutmaktır. Ayrıntılı izinleri sunucu tarafında kullanıcı numarasına göre sorgularsınız. Böylece izin değişikliği hemen etkili olur ve token küçük kalır.

İmza doğrulamasının işlemci maliyeti ise çoğu uygulamada her istekte veritabanına gitmenin maliyetinden düşük kalır. Yine de ölçüm yapmadan sonuca varmayın. Kendi sisteminizde yük testi yapıp sonuçlara göre karar verin.

JWT nedir sorusunu öğrendikten sonra kontrol listesi nasıl olmalı?

Aşağıdaki liste, bir projeyi canlıya almadan önce bakmanız gereken noktaları toplar. Hepsi kavramsal düzeydedir; ayrıntılı değerleri sağlayıcınızın ve standartların güncel belgelerinden doğrulayın.

• Her istekte imzayı kontrol ediyor muyum?
• Kabul edilen algoritmaları sunucuda sabitledim mi?
• İmza anahtarları güvenli bir gizli bilgi deposunda mı?
• Her tokenda bitiş zamanı var mı ve erişim token'ı kısa ömürlü mü?
• iss ve aud alanlarını kontrol ediyor muyum?
• Yükte hassas veri yok, yalnızca gereken minimum bilgi var mı?
• Yenileme token'larını sunucuda izliyor ve gerekince iptal edebiliyor muyum?
• Çıkış yapma, parola değişikliği ve hesap kapatma senaryolarını tasarladım mı?
• Tokenı tarayıcıda betiklerin okuyamayacağı biçimde sakladım mı?
• Tüm trafik HTTPS üzerinden mi akıyor?

Son madde için sitenizin sertifikasını SSL sorgulama aracıyla kontrol edebilir, konunun temelini SSL sertifikası rehberimizde okuyabilirsiniz. Çünkü token şifresiz bir bağlantıdan geçerse imza onu korumaz.

Özel yazılım projesinde JWT kararını nasıl ele almalısınız?

Örnek senaryo: Bir işletme web arayüzü, mobil uygulama ve iç yönetim paneli olan bir sistem planlıyor. Üç parça aynı arka uç servislerini kullanacak. Ekibimiz böyle projelerde ilk olarak şu soruyu sorar: kimlik ve yetki akışını kaç ayrı yerde doğrulayacağız ve iptal ne kadar hızlı olmalı?

Cevaba göre karar değişir. Tek bir web uygulaması için sağlam çerez oturumu yeterli olabilir. Birden fazla istemci ve servis varsa kısa ömürlü erişim token'ı ve izlenen yenileme token'ı daha uygundur. Arka uçta bu mantığın nerede durduğunu anlamak için back-end nedir yazımıza bakın.

Kimlik doğrulama, ürünün en kritik parçalarından biridir ve sonradan eklenen bir yama gibi ele alınmamalıdır. Ekibimiz bu kararı mimari aşamada netleştirmeyi önerir. Bu tür bir projeyi birlikte planlamak isterseniz özel yazılım geliştirme hizmetimizi inceleyebilirsiniz.

Son söz: JWT nedir sorusunun dürüst cevabı, iyi bir araç olduğudur, ama araç kullanım biçimiyle güvenli ya da güvensiz olur. Standardı (RFC 7519), en iyi uygulama belgesini (RFC 8725) ve OWASP JWT Cheat Sheet sayfasını düzenli okumak, bilgilerinizi güncel tutmanın en sağlam yoludur.