\n API’lerinizin g\u00fcvenli\u011fini sa\u011flamak, g\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda sadece bir se\u00e7enek de\u011fil, bir zorunluluk haline geldi. Peki, bu g\u00fcvenli\u011fi sa\u011flarken en \u00e7ok kullan\u0131lan y\u00f6ntemlerden biri olan JWT (JSON Web Token) token y\u00f6netimini ne kadar iyi biliyoruz? Bu makale, JWT’nin derinliklerine inerek, onu nas\u0131l g\u00fcvenli bir \u015fekilde y\u00f6netece\u011finizi ve API’lerinizi siber tehditlere kar\u015f\u0131 nas\u0131l daha diren\u00e7li hale getirece\u011finizi ad\u0131m ad\u0131m a\u00e7\u0131kl\u0131yor. Stajyer bir geli\u015ftiriciden deneyimli bir tak\u0131m liderine, freelance \u00e7al\u0131\u015fanlardan bu alana yeni ad\u0131m atmak isteyenlere kadar herkes i\u00e7in yol g\u00f6sterici olacak bu kapsaml\u0131 rehberde, ak\u0131lda kal\u0131c\u0131 \u00f6rnekler ve pratik ipu\u00e7lar\u0131 bulacaks\u0131n\u0131z. Gelin, API g\u00fcvenli\u011fi konusundaki bilgi birikiminizi bir \u00fcst seviyeye ta\u015f\u0131yal\u0131m!\n<\/p>\n
\n G\u00fcn\u00fcm\u00fcz\u00fcn modern yaz\u0131l\u0131m mimarilerinde, \u00f6zellikle mikroservis tabanl\u0131 ve SPA (Single Page Application) yap\u0131lar\u0131nda, kimlik do\u011frulama (authentication) ve yetkilendirme (authorization) mekanizmalar\u0131 kritik bir rol oynar. Geleneksel oturum (session) tabanl\u0131 yakla\u015f\u0131mlar, durum bilgisi (stateful) gerektirdikleri i\u00e7in \u00f6l\u00e7eklenebilirlik ve performans a\u00e7\u0131s\u0131ndan baz\u0131 zorluklar yaratabilir. \u0130\u015fte tam bu noktada, JWT (JSON Web Token) devreye girerek adeta bir kurtar\u0131c\u0131 g\u00f6revi \u00fcstlenir. Peki, nedir bu JWT ve onu bu kadar vazge\u00e7ilmez k\u0131lan \u00f6zellikler nelerdir?\n<\/p>\n
\n Basit\u00e7e ifade etmek gerekirse, JWT, iki taraf aras\u0131nda g\u00fcvenli bir \u015fekilde bilgi aktar\u0131m\u0131n\u0131 sa\u011flayan, JSON format\u0131nda s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f bir tokendir. Bu token, genellikle bir kimlik bilgisi olarak kullan\u0131l\u0131r ve kullan\u0131c\u0131n\u0131n kimli\u011fini do\u011frulamak ve hangi kaynaklara eri\u015febilece\u011fini belirlemek i\u00e7in API’ler taraf\u0131ndan kullan\u0131l\u0131r. JWT’nin en b\u00fcy\u00fck avantajlar\u0131ndan biri, durum bilgisiz (stateless) olmas\u0131d\u0131r. Yani, sunucunun her istekte kullan\u0131c\u0131n\u0131n oturum bilgisini saklamas\u0131na gerek kalmaz. Bunun yerine, token’\u0131n kendisi, kullan\u0131c\u0131 hakk\u0131nda gerekli bilgileri (claim’ler) i\u00e7erir ve bu bilgiler dijital olarak imzalanarak b\u00fct\u00fcnl\u00fc\u011f\u00fc garanti alt\u0131na al\u0131n\u0131r. Bu durum, sunucu y\u00fck\u00fcn\u00fc azalt\u0131r, \u00f6l\u00e7eklenebilirli\u011fi art\u0131r\u0131r ve da\u011f\u0131t\u0131k sistemlerde daha esnek bir yap\u0131 sunar.\n<\/p>\n
\n Bir JWT token \u00fc\u00e7 ana b\u00f6l\u00fcmden olu\u015fur: Header (Ba\u015fl\u0131k), Payload (Y\u00fck) ve Signature (\u0130mza). Header, genellikle token’\u0131n t\u00fcr\u00fcn\u00fc (JWT) ve kullan\u0131lan imzalama algoritmas\u0131n\u0131 (\u00f6rne\u011fin, HS256 veya RS256) belirtir. Payload ise, kullan\u0131c\u0131 kimli\u011fi, roller, izinler gibi \u00e7e\u015fitli “claim”leri i\u00e7erir. Bu claim’ler, standart olanlar (registered claims) veya \u00f6zel olarak tan\u0131mlanabilenler (private claims) olabilir. Son olarak, Signature, header ve payload’\u0131n birle\u015ftirilmesiyle olu\u015fturulur ve sunucunun bildi\u011fi gizli bir anahtar (secret key) veya \u00f6zel\/genel anahtar \u00e7ifti kullan\u0131larak imzalan\u0131r. Bu imza, token’\u0131n de\u011fi\u015ftirilmedi\u011fini ve g\u00fcvenilir bir kaynaktan geldi\u011fini do\u011frulamak i\u00e7in kullan\u0131l\u0131r. Bu yap\u0131sal b\u00fct\u00fcnl\u00fck ve g\u00fcvenlik mekanizmas\u0131, JWT’yi modern API g\u00fcvenli\u011fi i\u00e7in vazge\u00e7ilmez k\u0131lar.\n<\/p>\n
\n JWT tokenlar\u0131n\u0131n nas\u0131l olu\u015fturuldu\u011funu ve bu olu\u015fturma s\u00fcrecinin g\u00fcvenlik a\u00e7\u0131s\u0131ndan ne kadar \u00f6nemli oldu\u011funu anlamak, onlar\u0131 etkin bir \u015fekilde kullanman\u0131n ilk ad\u0131m\u0131d\u0131r. Kimlik do\u011frulama ba\u015far\u0131l\u0131 oldu\u011funda, sunucu, kullan\u0131c\u0131n\u0131n kimli\u011fini ve yetkilerini i\u00e7eren bilgileri bir JSON nesnesine d\u00f6n\u00fc\u015ft\u00fcr\u00fcr. Bu JSON nesnesi, “Payload” olarak adland\u0131r\u0131l\u0131r. Ard\u0131ndan, bu payload, token’\u0131n meta bilgilerini i\u00e7eren “Header” ile birle\u015ftirilir. Header, genellikle kullan\u0131lan imzalama algoritmas\u0131 ve token t\u00fcr\u00fc gibi bilgileri bar\u0131nd\u0131r\u0131r.\n<\/p>\n
\n \u0130\u015fte bu birle\u015ftirilmi\u015f veri, sunucunun gizli anahtar\u0131 (secret key) ile \u015fifrelenir ve bir “Signature” (\u0130mza) olu\u015fturulur. Bu imza, token’\u0131n hem b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc hem de kayna\u011f\u0131n\u0131n do\u011frulu\u011funu garanti eder. Yani, e\u011fer token’\u0131n header veya payload k\u0131sm\u0131nda herhangi bir de\u011fi\u015fiklik yap\u0131l\u0131rsa, bu de\u011fi\u015fiklik imzada hemen fark edilecektir. Bu sayede, istemci taraf\u0131ndan g\u00f6nderilen token’\u0131n manip\u00fcle edilip edilmedi\u011fi kolayca anla\u015f\u0131labilir. Token’\u0131n kendisi Base64 ile kodlanm\u0131\u015f olsa da, bu bir \u015fifreleme y\u00f6ntemi de\u011fildir; sadece verinin okunabilirli\u011fini kolayla\u015ft\u0131ran bir y\u00f6ntemdir. Ger\u00e7ek g\u00fcvenlik, imzalama (signing) i\u015fleminde gizli anahtar\u0131n g\u00fcvenli\u011finde yatar.\n<\/p>\n
\n \u0130mza do\u011frulamas\u0131 ise, token’\u0131 alan sunucu taraf\u0131nda ger\u00e7ekle\u015fir. Sunucu, gelen token’\u0131n header ve payload k\u0131s\u0131mlar\u0131n\u0131 alarak, kendi bildi\u011fi gizli anahtar veya \u00f6zel anahtar\u0131n\u0131 kullanarak ayn\u0131 imzalama i\u015flemini yeniden yapar. Ard\u0131ndan, kendi olu\u015fturdu\u011fu imza ile gelen token’\u0131n imzas\u0131n\u0131 kar\u015f\u0131la\u015ft\u0131r\u0131r. E\u011fer bu iki imza e\u015fle\u015firse, token’\u0131n ge\u00e7erli oldu\u011fu ve de\u011fi\u015ftirilmedi\u011fi do\u011frulanm\u0131\u015f olur. Bu do\u011frulama s\u00fcreci, API’nizin kimli\u011fi do\u011frulanmam\u0131\u015f veya de\u011fi\u015ftirilmi\u015f token’larla gelen isteklere yan\u0131t vermesini engeller. Bu nedenle, imzalama algoritmas\u0131n\u0131n do\u011fru se\u00e7ilmesi ve gizli anahtar\u0131n g\u00fcvenli bir \u015fekilde saklanmas\u0131, JWT g\u00fcvenli\u011finin temel ta\u015flar\u0131ndand\u0131r. Algoritma se\u00e7imi, token’\u0131n ne kadar g\u00fcvenli olaca\u011f\u0131n\u0131 do\u011frudan etkiler.\n<\/p>\n
\n JWT tokenlar\u0131n\u0131 do\u011fru y\u00f6netmek, API g\u00fcvenli\u011finizin temel direklerinden biridir. Bu tokenlar, kullan\u0131c\u0131 kimlik bilgilerini ve yetkilerini ta\u015f\u0131d\u0131\u011f\u0131 i\u00e7in, k\u00f6t\u00fc niyetli ki\u015filerin eline ge\u00e7mesi ciddi g\u00fcvenlik a\u00e7\u0131klar\u0131na yol a\u00e7abilir. Bu nedenle, JWT tokenlar\u0131n\u0131 \u00fcretirken, iletirken ve saklarken titiz davranmak b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. \u00d6ncelikle, token’\u0131n i\u00e7eri\u011fi konusunda dikkatli olmal\u0131y\u0131z. Payload k\u0131sm\u0131na hassas bilgileri (\u015fifreler, kredi kart\u0131 numaralar\u0131 gibi) asla koymamal\u0131y\u0131z. JWT tokenlar\u0131 \u015fifrelenmez, sadece imzalan\u0131r. Bu nedenle, payload’daki t\u00fcm bilgiler a\u00e7\u0131k metin olarak okunabilir. Bu durum, token’\u0131n i\u00e7eri\u011fini gizli tutmak yerine, kimli\u011fini ve yetkilerini g\u00fcvenli bir \u015fekilde iletmek i\u00e7in kullan\u0131lmal\u0131d\u0131r.\n<\/p>\n
\n Token’lar\u0131n \u00f6mr\u00fcn\u00fc y\u00f6netmek de kritik bir konudur. K\u0131sa \u00f6m\u00fcrl\u00fc eri\u015fim tokenlar\u0131 (access tokens) ve daha uzun \u00f6m\u00fcrl\u00fc yenileme tokenlar\u0131 (refresh tokens) kullanmak, g\u00fcvenlik ve kullan\u0131c\u0131 deneyimi a\u00e7\u0131s\u0131ndan dengeli bir yakla\u015f\u0131m sunar. Eri\u015fim tokenlar\u0131 k\u0131sa s\u00fcreli ge\u00e7erli olmal\u0131 ve s\u0131k s\u0131k yenilenmelidir. Yenileme tokenlar\u0131 ise daha uzun \u00f6m\u00fcrl\u00fcd\u00fcr ancak sadece yeni eri\u015fim tokenlar\u0131 almak i\u00e7in kullan\u0131lmal\u0131d\u0131r. Bir eri\u015fim token\u0131 \u00e7al\u0131nsa bile, k\u0131sa \u00f6mr\u00fc sayesinde sald\u0131rgan\u0131n elde edece\u011fi fayda s\u0131n\u0131rl\u0131 kal\u0131r. Token’lar\u0131n g\u00fcvenli bir \u015fekilde iletilmesi i\u00e7in ise HTTPS kullan\u0131m\u0131 \u015fartt\u0131r. HTTP \u00fczerinden g\u00f6nderilen tokenlar, ortadaki adam sald\u0131r\u0131lar\u0131na (man-in-the-middle attacks) kar\u015f\u0131 savunmas\u0131zd\u0131r.\n<\/p>\n
\n Token’lar\u0131n istemci taraf\u0131nda nas\u0131l sakland\u0131\u011f\u0131 da \u00f6nemli bir g\u00fcvenlik fakt\u00f6r\u00fcd\u00fcr. Taray\u0131c\u0131 tabanl\u0131 uygulamalarda, token’lar genellikle localStorage, sessionStorage veya \u00e7erezler (cookies) arac\u0131l\u0131\u011f\u0131yla saklan\u0131r. Her birinin kendine \u00f6zg\u00fc g\u00fcvenlik riskleri vard\u0131r. \u00d6rne\u011fin, localStorage XSS (Cross-Site Scripting) sald\u0131r\u0131lar\u0131na kar\u015f\u0131 daha savunmas\u0131zd\u0131r. \u00c7erezler ise CSRF (Cross-Site Request Forgery) sald\u0131r\u0131lar\u0131na kar\u015f\u0131 korunmal\u0131d\u0131r. Bu nedenle, token’lar\u0131n saklanaca\u011f\u0131 yerin iyi se\u00e7ilmesi ve gerekli g\u00fcvenlik \u00f6nlemlerinin al\u0131nmas\u0131 gerekir. Ayr\u0131ca, kullan\u0131c\u0131 oturumu kapatt\u0131\u011f\u0131nda veya belirli bir s\u00fcre i\u015flem yapmad\u0131\u011f\u0131nda token’lar\u0131n ge\u00e7ersiz k\u0131l\u0131nmas\u0131 (revocation) da g\u00fcvenlik a\u00e7\u0131s\u0131ndan \u00f6nemlidir. Bu, genellikle bir kara liste (blacklist) mekanizmas\u0131 ile veya yeniden yap\u0131land\u0131rma (re-issuance) ile ger\u00e7ekle\u015ftirilir.\n<\/p>\n
\n JWT tokenlar\u0131n\u0131n g\u00fcvenli\u011fini sa\u011flayan en \u00f6nemli unsurlardan biri, kullan\u0131lan imzalama algoritmas\u0131d\u0131r. Do\u011fru algoritmay\u0131 se\u00e7mek, token’\u0131n b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ve g\u00fcvenilirli\u011fini do\u011frudan etkiler. JWT, farkl\u0131 imzalama algoritmalar\u0131n\u0131 destekler ve bu algoritmalar temelde iki ana kategoriye ayr\u0131l\u0131r: simetrik (symmetric) ve asimetrik (asymmetric) algoritmalar.\n<\/p>\n
\n Simetrik algoritmalar, \u00f6rne\u011fin HS256 (HMAC-SHA256), hem imzalama hem de do\u011frulama i\u00e7in ayn\u0131 gizli anahtar\u0131 kullan\u0131r. Bu yakla\u015f\u0131m, uygulamas\u0131 daha kolay ve genellikle daha performansl\u0131d\u0131r. Ancak, gizli anahtar\u0131n hem kimlik do\u011frulama sunucusunda hem de token’\u0131 do\u011frulayacak t\u00fcm servislerde g\u00fcvenli bir \u015fekilde saklanmas\u0131 gerekir. Bu durum, \u00f6zellikle mikroservis mimarilerinde, anahtar y\u00f6netimini karma\u015f\u0131k hale getirebilir. E\u011fer gizli anahtar\u0131n\u0131z ele ge\u00e7irilirse, sald\u0131rganlar sahte token’lar \u00fcretebilir. Bu nedenle, simetrik algoritmalar kullan\u0131l\u0131rken, gizli anahtar\u0131n g\u00fcvenli\u011fi en \u00fcst d\u00fczeyde tutulmal\u0131d\u0131r.\n<\/p>\n
\n Asimetrik algoritmalar ise, \u00f6rne\u011fin RS256 (RSA Signature with SHA-256), bir genel anahtar (public key) ve bir \u00f6zel anahtar (private key) \u00e7ifti kullan\u0131r. \u00d6zel anahtar ile token imzalan\u0131r ve bu imza, herkese a\u00e7\u0131k olan genel anahtar ile do\u011frulan\u0131r. Bu y\u00f6ntem, \u00f6zellikle da\u011f\u0131t\u0131k sistemlerde daha g\u00fcvenli bir \u00e7\u00f6z\u00fcm sunar. \u00c7\u00fcnk\u00fc imzalama i\u015flemi sadece \u00f6zel anahtara sahip olan sunucuda yap\u0131l\u0131rken, do\u011frulama i\u015flemi \u00f6zel anahtara ihtiya\u00e7 duymadan herhangi bir servis taraf\u0131ndan yap\u0131labilir. Bu, anahtar da\u011f\u0131t\u0131m\u0131n\u0131 ve y\u00f6netimini kolayla\u015ft\u0131r\u0131r. Bir asimetrik anahtar \u00e7ifti kullan\u0131ld\u0131\u011f\u0131nda, \u00f6zel anahtar sadece imzalayan sunucuda saklanmal\u0131, genel anahtar ise do\u011frulamay\u0131 yapacak t\u00fcm servislerle payla\u015f\u0131lmal\u0131d\u0131r. Bu, token’\u0131n g\u00fcvenli\u011fini art\u0131r\u0131r \u00e7\u00fcnk\u00fc \u00f6zel anahtar\u0131n ele ge\u00e7irilmesi, token’\u0131n i\u00e7eri\u011fini de\u011fi\u015ftirmeyi veya sahte token \u00fcretmeyi zorla\u015ft\u0131r\u0131r.\n<\/p>\n
\n Algoritma se\u00e7imi, projenizin mimarisine, \u00f6l\u00e7eklenebilirlik gereksinimlerine ve g\u00fcvenlik beklentilerine g\u00f6re yap\u0131lmal\u0131d\u0131r. K\u00fc\u00e7\u00fck ve tek bir servisten olu\u015fan uygulamalar i\u00e7in HS256 yeterli olabilirken, daha b\u00fcy\u00fck ve da\u011f\u0131t\u0131k sistemlerde RS256 gibi asimetrik algoritmalar daha g\u00fcvenli bir se\u00e7enek sunar. Unutmamak gerekir ki, hi\u00e7bir algoritma tek ba\u015f\u0131na mutlak g\u00fcvenlik sa\u011flamaz. G\u00fcvenlik, do\u011fru algoritma se\u00e7imi, gizli anahtar\u0131n g\u00fcvenli y\u00f6netimi ve di\u011fer g\u00fcvenlik \u00f6nlemleriyle birlikte bir b\u00fct\u00fcnd\u00fcr.\n<\/p>\n
\n JWT tokenlar\u0131n\u0131n durum bilgisiz (stateless) yap\u0131s\u0131, \u00f6l\u00e7eklenebilirlik ve performans a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck avantajlar sunsa da, baz\u0131 durumlarda kullan\u0131c\u0131 oturumunu veya token’\u0131 an\u0131nda ge\u00e7ersiz k\u0131lma ihtiyac\u0131 do\u011fabilir. \u00d6rne\u011fin, bir kullan\u0131c\u0131 \u015fifresini de\u011fi\u015ftirdi\u011finde veya bir y\u00f6netici bir kullan\u0131c\u0131n\u0131n hesab\u0131n\u0131 ask\u0131ya ald\u0131\u011f\u0131nda, o kullan\u0131c\u0131ya ait aktif token’lar\u0131n derhal ge\u00e7ersiz k\u0131l\u0131nmas\u0131 gerekir. Ancak, JWT’nin durum bilgisiz do\u011fas\u0131 gere\u011fi, sunucu her gelen token’\u0131 otomatik olarak ge\u00e7erli sayar \u00e7\u00fcnk\u00fc token’\u0131n kendisi ge\u00e7erlilik s\u00fcresi boyunca ge\u00e7erlidir ve sunucunun herhangi bir oturum bilgisiyle kar\u015f\u0131la\u015ft\u0131rmas\u0131na gerek yoktur. Bu durum, token’\u0131n ge\u00e7ersiz k\u0131l\u0131nmas\u0131n\u0131 (revocation) karma\u015f\u0131k hale getirebilir. Peki, bu zorlu\u011fun \u00fcstesinden nas\u0131l gelinebilir?\n<\/p>\n
\n JWT token’lar\u0131n\u0131 ge\u00e7ersiz k\u0131lman\u0131n en yayg\u0131n ve etkili y\u00f6ntemlerinden biri, bir “kara liste” (blacklist) veya “iptal listesi” (revocation list) mekanizmas\u0131 kullanmakt\u0131r. Bu y\u00f6ntemde, ge\u00e7ersiz k\u0131l\u0131nmas\u0131 gereken token’lar \u00f6zel bir veritaban\u0131nda veya bellekte saklan\u0131r. Her istek geldi\u011finde, token’\u0131n ge\u00e7erli olup olmad\u0131\u011f\u0131n\u0131 kontrol etmeden \u00f6nce, \u00f6ncelikle bu kara listede olup olmad\u0131\u011f\u0131 sorgulan\u0131r. E\u011fer token kara listedeyse, istek reddedilir. Bu yakla\u015f\u0131m, token’\u0131n ge\u00e7erlilik s\u00fcresi dolmadan da oturumu sonland\u0131rma imkan\u0131 sunar. Ancak, bu mekanizma, JWT’nin durum bilgisiz \u00f6zelli\u011fini bir miktar zay\u0131flat\u0131r \u00e7\u00fcnk\u00fc sunucu art\u0131k bir d\u0131\u015f veri kayna\u011f\u0131n\u0131 sorgulamak durumunda kal\u0131r. Kara listenin boyutu artt\u0131k\u00e7a, sorgulama s\u00fcresi ve bu listenin y\u00f6netimi de zorla\u015fabilir.\n<\/p>\n
\n Alternatif bir y\u00f6ntem ise, token’lar\u0131n ge\u00e7erlilik s\u00fcresini (expiration time – exp) \u00e7ok k\u0131sa tutmakt\u0131r. Eri\u015fim tokenlar\u0131 genellikle birka\u00e7 dakika veya en fazla birka\u00e7 saat ge\u00e7erli olacak \u015fekilde ayarlan\u0131r. Kullan\u0131c\u0131lar, daha uzun s\u00fcreli oturumlar i\u00e7in yenileme tokenlar\u0131 (refresh tokens) kullan\u0131r. Yenileme tokenlar\u0131 da kendi i\u00e7inde bir veritaban\u0131nda saklanmal\u0131 ve ge\u00e7ersiz k\u0131l\u0131nabilmelidir. Eri\u015fim token\u0131n\u0131n k\u0131sa \u00f6mr\u00fc, \u00e7al\u0131nan bir token’\u0131n kullan\u0131m s\u00fcresini s\u0131n\u0131rlayarak g\u00fcvenlik riskini azalt\u0131r. Ancak, bu durum, kullan\u0131c\u0131lar\u0131n daha s\u0131k token yenilemesi gerekti\u011fi anlam\u0131na gelir, bu da kullan\u0131c\u0131 deneyimini bir miktar etkileyebilir.\n<\/p>\n
\n Bir di\u011fer geli\u015fmi\u015f y\u00f6ntem ise, token’lar\u0131n i\u00e7inde “jti” (JWT ID) gibi benzersiz bir tan\u0131mlay\u0131c\u0131 bulundurmak ve bu ID’leri bir veritaban\u0131nda saklayarak ge\u00e7ersiz k\u0131lmakt\u0131r. Bu, daha gran\u00fcler bir kontrol sa\u011flar ancak y\u00f6netim y\u00fck\u00fcn\u00fc art\u0131r\u0131r. Hangi y\u00f6ntemin se\u00e7ilece\u011fi, projenin \u00f6zel gereksinimlerine, g\u00fcvenlik hassasiyetine ve \u00f6l\u00e7eklenebilirlik hedeflerine ba\u011fl\u0131d\u0131r. \u00d6zetle, token ge\u00e7ersiz k\u0131lma, JWT’nin do\u011fas\u0131 gere\u011fi ek bir katman gerektirse de, g\u00fcvenli\u011fi sa\u011flamak ad\u0131na \u00e7o\u011fu zaman bir zorunluluktur.\n<\/p>\n
\n Her ne kadar JWT g\u00fc\u00e7l\u00fc bir kimlik do\u011frulama mekanizmas\u0131 sunsa da, yanl\u0131\u015f uyguland\u0131\u011f\u0131nda veya dikkatsizce y\u00f6netildi\u011finde ciddi g\u00fcvenlik a\u00e7\u0131klar\u0131na yol a\u00e7abilir. Bu a\u00e7\u0131klar\u0131 anlamak ve bunlardan ka\u00e7\u0131nmak, API’lerinizi g\u00fcvende tutman\u0131n anahtar\u0131d\u0131r. En s\u0131k kar\u015f\u0131la\u015f\u0131lan g\u00fcvenlik a\u00e7\u0131klar\u0131ndan biri, “Algoritma De\u011fi\u015fikli\u011fi” sald\u0131r\u0131s\u0131d\u0131r. Sald\u0131rganlar, token’\u0131n header k\u0131sm\u0131ndaki imzalama algoritmas\u0131n\u0131 “none” olarak de\u011fi\u015ftirerek veya simetrik bir algoritmadan (\u00f6rn. HS256) asimetrik bir algoritmaya (\u00f6rn. RS256) ge\u00e7erek, imza do\u011frulamas\u0131 yap\u0131lmadan token’\u0131 ge\u00e7erli k\u0131lmaya \u00e7al\u0131\u015fabilirler. Bu t\u00fcr sald\u0131r\u0131lar\u0131 \u00f6nlemek i\u00e7in, sunucu taraf\u0131nda token do\u011frulama s\u0131ras\u0131nda, token’\u0131n header’\u0131nda belirtilen algoritman\u0131n beklentilerinizle uyumlu olup olmad\u0131\u011f\u0131n\u0131 kontrol etmelisiniz. \u00d6rne\u011fin, sadece HS256 kullanacaksan\u0131z, RS256 veya none algoritmalar\u0131 ile gelen token’lar\u0131 reddetmelisiniz.\n<\/p>\n
\n Bir di\u011fer \u00f6nemli g\u00fcvenlik a\u00e7\u0131\u011f\u0131, hassas bilgilerin payload k\u0131sm\u0131na yerle\u015ftirilmesidir. Daha \u00f6nce de belirtildi\u011fi gibi, JWT payload’\u0131 \u015fifrelenmez, sadece Base64 ile kodlan\u0131r. Bu nedenle, kullan\u0131c\u0131 ID’si, rol bilgisi gibi bilgiler saklanabilirken, \u015fifre, kredi kart\u0131 numaras\u0131 gibi hassas veriler asla buraya konulmamal\u0131d\u0131r. E\u011fer bu bilgiler gerekiyorsa, bunlar g\u00fcvenli bir \u015fekilde \u015fifrelenmeli veya farkl\u0131 bir mekanizma ile y\u00f6netilmelidir. Ayr\u0131ca, token’\u0131n ge\u00e7erlilik s\u00fcresi (expiration time – exp) do\u011fru ayarlanmal\u0131 ve token’lar asla s\u00fcresiz olarak ge\u00e7erli b\u0131rak\u0131lmamal\u0131d\u0131r. K\u0131sa \u00f6m\u00fcrl\u00fc token’lar, \u00e7al\u0131nma durumunda sald\u0131rgan\u0131n kullanabilece\u011fi s\u00fcreyi s\u0131n\u0131rlar.\n<\/p>\n
\n Ayr\u0131ca, “Brute-force” sald\u0131r\u0131lar\u0131 da JWT g\u00fcvenli\u011fini tehdit edebilir. \u00d6zellikle simetrik algoritmalar kullan\u0131ld\u0131\u011f\u0131nda, e\u011fer gizli anahtar zay\u0131f bir \u015fifreyle korunuyorsa, sald\u0131rganlar deneme yan\u0131lma yoluyla bu anahtar\u0131 ele ge\u00e7irebilirler. Bu nedenle, gizli anahtarlar\u0131n\u0131z\u0131n g\u00fc\u00e7l\u00fc ve rastgele se\u00e7ilmi\u015f olmas\u0131, d\u00fczenli olarak de\u011fi\u015ftirilmesi ve asla kod taban\u0131na veya istemci taraf\u0131na do\u011frudan eklenmemesi b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Anahtar y\u00f6netimi i\u00e7in ortam de\u011fi\u015fkenleri veya g\u00fcvenli anahtar y\u00f6netim servisleri kullan\u0131lmal\u0131d\u0131r. Son olarak, token’lar\u0131n iletimi s\u0131ras\u0131nda HTTPS kullanmak, “Man-in-the-Middle” sald\u0131r\u0131lar\u0131n\u0131 \u00f6nleyerek token’lar\u0131n a\u011f \u00fczerinde ele ge\u00e7irilmesini engeller. Bu temel g\u00fcvenlik \u00f6nlemlerini uygulayarak, JWT tokenlar\u0131n\u0131z\u0131n g\u00fcvenli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilirsiniz.\n<\/p>\n
Hay\u0131r, JWT tokenlar\u0131 \u015fifrelenmez, sadece imzalan\u0131r. Header ve Payload k\u0131s\u0131mlar\u0131 Base64 ile kodland\u0131\u011f\u0131 i\u00e7in okunabilir durumdad\u0131r. G\u00fcvenlik, imzalama i\u015flemi ve gizli anahtar\u0131n g\u00fcvenli\u011finde yatar.<\/p>\n<\/li>\n
Eri\u015fim tokenlar\u0131 (access tokens) i\u00e7in k\u0131sa ge\u00e7erlilik s\u00fcreleri (birka\u00e7 dakika veya saat) \u00f6nerilir. Yenileme tokenlar\u0131 (refresh tokens) ise daha uzun s\u00fcreli olabilir ancak onlar da belirli bir s\u00fcre sonra ge\u00e7ersiz k\u0131l\u0131nmal\u0131d\u0131r.<\/p>\n<\/li>\n
E\u011fer uygulaman\u0131z\u0131n durum bilgisi (stateful) tutmas\u0131 gerekiyorsa veya \u00e7ok s\u0131k token ge\u00e7ersiz k\u0131lma ihtiyac\u0131n\u0131z varsa, geleneksel oturum tabanl\u0131 y\u00f6ntemler veya farkl\u0131 kimlik do\u011frulama mekanizmalar\u0131 daha uygun olabilir. Ancak, do\u011fru stratejilerle JWT, bu senaryolarda da kullan\u0131labilir.<\/p>\n<\/li>\n
G\u00fcvenlik gereksinimlerine ba\u011fl\u0131 olarak localStorage, sessionStorage veya HttpOnly \u00e7erezler kullan\u0131labilir. Her birinin kendine \u00f6zg\u00fc g\u00fcvenlik riskleri vard\u0131r ve bunlara kar\u015f\u0131 \u00f6nlemler al\u0131nmal\u0131d\u0131r. HttpOnly \u00e7erezler, XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 daha g\u00fcvenli bir se\u00e7enek olabilir.<\/p>\n<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"API’lerinizin g\u00fcvenli\u011fini sa\u011flamak, g\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda sadece bir se\u00e7enek de\u011fil, bir zorunluluk haline geldi. Peki, bu g\u00fcvenli\u011fi sa\u011flarken…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1513,1],"tags":[],"class_list":{"0":"post-45508","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-dusunsel-ve-kisisel","7":"category-genel","8":"cs-entry","9":"cs-video-wrap"},"yoast_head":"\n