Web uygulamalar\u0131nda kullan\u0131c\u0131 deneyimini zenginle\u015ftirmenin ve g\u00fcvenli\u011fi sa\u011flaman\u0131n anahtarlar\u0131ndan biri oturum y\u00f6netimidir. HTTP protokol\u00fcn\u00fcn do\u011fas\u0131 gere\u011fi durumsuz olmas\u0131, her iste\u011fin birbirinden ba\u011f\u0131ms\u0131z de\u011ferlendirilmesi anlam\u0131na gelirken, modern uygulamalar kullan\u0131c\u0131lar\u0131 tan\u0131mak, oturumlar\u0131n\u0131 s\u00fcrd\u00fcrmek ve ki\u015fiselle\u015ftirilmi\u015f deneyimler sunmak zorundad\u0131r. Peki, bir kullan\u0131c\u0131 sisteme giri\u015f yapt\u0131\u011f\u0131nda, web sunucusu onu sonraki taleplerde nas\u0131l tan\u0131r ve bilgilerini nas\u0131l korur? Bu makale, \u00e7erezlerden sunucu tarafl\u0131 oturumlara ve modern JWT (JSON Web Tokens) yakla\u015f\u0131mlar\u0131na kadar oturum y\u00f6netiminin temel ta\u015flar\u0131n\u0131, g\u00fcvenlik zafiyetlerini ve en iyi uygulama y\u00f6ntemlerini derinlemesine inceleyecektir. Amac\u0131m\u0131z, uygulaman\u0131z i\u00e7in en uygun oturum y\u00f6netim stratejisini belirlemenize yard\u0131mc\u0131 olmakt\u0131r.<\/p>\n
G\u00fcn\u00fcm\u00fcz dijital d\u00fcnyas\u0131nda, internet \u00fczerindeki etkile\u015fimlerimizin b\u00fcy\u00fck bir k\u0131sm\u0131 s\u00fcrekli bir “kimlik” alg\u0131s\u0131yla \u015fekillenir. Bir e-ticaret sitesine giri\u015f yapt\u0131\u011f\u0131n\u0131zda sepetinize \u00fcr\u00fcn eklemeniz, sosyal medyada ak\u0131\u015f\u0131n\u0131z\u0131 kayd\u0131rman\u0131z veya bir bankac\u0131l\u0131k uygulamas\u0131nda i\u015flem yapman\u0131z, sistemin sizi tan\u0131mas\u0131 ve \u00f6nceki eylemlerinizi hat\u0131rlamas\u0131 sayesinde m\u00fcmk\u00fcn olur. Ancak, internetin temel protokol\u00fc olan HTTP (Hypertext Transfer Protocol), do\u011fas\u0131 gere\u011fi “durumsuz” (stateless) bir yap\u0131ya sahiptir. Bu ne anlama geliyor? Basit\u00e7e ifade etmek gerekirse, her HTTP iste\u011fi, bir \u00f6ncekini veya sonrakini bilmez; her biri sunucu i\u00e7in yeni ve ba\u011f\u0131ms\u0131z bir taleptir. Bir kullan\u0131c\u0131 ad\u0131 ve \u015fifre ile giri\u015f yapt\u0131ktan hemen sonra yapaca\u011f\u0131 bir ba\u015fka i\u015flem i\u00e7in tekrar kimlik do\u011frulamas\u0131 yapmas\u0131 gerekseydi, kullan\u0131c\u0131 deneyimi dayan\u0131lmaz hale gelirdi. \u0130\u015fte tam bu noktada “oturum y\u00f6netimi” kavram\u0131 devreye girer ve durumsuz HTTP’yi durum bilgisi olan, ki\u015fiselle\u015ftirilmi\u015f bir deneyime d\u00f6n\u00fc\u015ft\u00fcr\u00fcr.<\/p>\n
Oturum y\u00f6netimi, bir kullan\u0131c\u0131n\u0131n web uygulamas\u0131yla etkile\u015fimde bulundu\u011fu s\u00fcre boyunca kimli\u011fini koruma ve bu etkile\u015fimin durumunu s\u00fcrd\u00fcrme s\u00fcrecidir. Bu s\u00fcre\u00e7, kullan\u0131c\u0131n\u0131n sisteme giri\u015f yapmas\u0131ndan (kimlik do\u011frulama) \u00e7\u0131k\u0131\u015f yapmas\u0131na kadar ge\u00e7en s\u00fcreyi kapsar. Oturum y\u00f6netimi sadece kullan\u0131c\u0131 deneyimini iyile\u015ftirmekle kalmaz, ayn\u0131 zamanda uygulaman\u0131n g\u00fcvenli\u011fi i\u00e7in de kritik bir rol oynar. Yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f veya zay\u0131f bir oturum y\u00f6netimi, uygulaman\u0131z\u0131 kimlik av\u0131, oturum ka\u00e7\u0131rma, yetkisiz eri\u015fim gibi ciddi g\u00fcvenlik a\u00e7\u0131klar\u0131na kar\u015f\u0131 savunmas\u0131z hale getirebilir. Dolay\u0131s\u0131yla, bu mekanizmalar\u0131 do\u011fru bir \u015fekilde anlamak ve uygulamak, modern web geli\u015ftirmenin temel direklerinden biridir. Bu b\u00f6l\u00fcmde, oturum y\u00f6netiminin neden bu kadar kritik oldu\u011funu ve bu hayati ihtiyaca farkl\u0131 yakla\u015f\u0131mlar\u0131n nas\u0131l \u00e7\u00f6z\u00fcm sundu\u011funu ele alaca\u011f\u0131z. Bir e-ticaret sitesindeki al\u0131\u015fveri\u015f sepeti \u00f6rne\u011fini d\u00fc\u015f\u00fcnelim: Kullan\u0131c\u0131 sisteme giri\u015f yapar, sepete \u00fcr\u00fcnler ekler ve belki birka\u00e7 saat sonra tekrar gelip al\u0131\u015fveri\u015fini tamamlar. Uygulaman\u0131n bu s\u00fcre\u00e7te kullan\u0131c\u0131n\u0131n kimli\u011fini ve sepetinin i\u00e7eri\u011fini nas\u0131l hat\u0131rlad\u0131\u011f\u0131n\u0131 anlamak, oturum y\u00f6netiminin temel prensiplerini kavramakla ba\u015flar. Bu, hem kullan\u0131\u015fl\u0131l\u0131k hem de g\u00fcvenlik a\u00e7\u0131s\u0131ndan \u00fczerinde durulmas\u0131 gereken \u00f6nemli bir konudur. \u00c7\u00fcnk\u00fc bir oturum kimli\u011finin k\u00f6t\u00fc niyetli ki\u015filerin eline ge\u00e7mesi, kullan\u0131c\u0131n\u0131n t\u00fcm hesap bilgilerine eri\u015fimini sa\u011flayabilir. Bu nedenle, oturum y\u00f6netimi sadece bir kolayl\u0131k de\u011fil, ayn\u0131 zamanda bir zorunluluktur.<\/p>\n
Oturum y\u00f6netiminin kalbinde yer alan ve belki de en eski, en yayg\u0131n kullan\u0131lan mekanizma \u00e7erezlerdir (cookies). HTTP’nin durumsuz yap\u0131s\u0131n\u0131 a\u015fmak i\u00e7in geli\u015ftirilen \u00e7erezler, sunucunun kullan\u0131c\u0131ya \u00f6zel bilgileri kullan\u0131c\u0131n\u0131n web taray\u0131c\u0131s\u0131nda depolamas\u0131na olanak tan\u0131r. Bir kullan\u0131c\u0131 bir web sitesini ziyaret etti\u011finde, sunucu taray\u0131c\u0131ya k\u00fc\u00e7\u00fck bir veri par\u00e7ac\u0131\u011f\u0131 g\u00f6nderir ve bu par\u00e7ac\u0131k taray\u0131c\u0131 taraf\u0131ndan depolan\u0131r. Kullan\u0131c\u0131 ayn\u0131 sunucuya sonraki taleplerde bulundu\u011funda, taray\u0131c\u0131 bu \u00e7erezleri otomatik olarak sunucuya geri g\u00f6nderir. Bu sayede sunucu, her iste\u011fi ba\u011f\u0131ms\u0131z bir varl\u0131k olarak g\u00f6rmek yerine, belirli bir kullan\u0131c\u0131yla ili\u015fkilendirebilir ve kullan\u0131c\u0131n\u0131n \u00f6nceki eylemlerini “hat\u0131rlayabilir”.<\/p>\n
\u00c7erezler genellikle anahtar-de\u011fer \u00e7iftleri \u015feklinde depolan\u0131r ve son kullanma tarihi, yolu, alan ad\u0131 gibi ek \u00f6zniteliklere sahiptir. \u00d6rne\u011fin, bir web sitesi sizin dil tercihinizi veya tema se\u00e7iminizi bir \u00e7erezde depolayabilir. \u00c7erezler iki ana kategoriye ayr\u0131l\u0131r:<\/p>\n
\u00c7erezlerin sunucu ve taray\u0131c\u0131 aras\u0131ndaki ak\u0131\u015f\u0131 bir \u00f6rnekle a\u00e7\u0131klayal\u0131m:<\/p>\n
Set-Cookie<\/code> ba\u015fl\u0131\u011f\u0131 ile bir \u00e7erez olu\u015fturur ve taray\u0131c\u0131ya g\u00f6nderir. \u00d6rne\u011fin: Set-Cookie: sessionId=abc123xyz; Expires=Wed, 21 Oct 2024 07:28:00 GMT; Path=\/; HttpOnly; Secure<\/code><\/li>\n- Taray\u0131c\u0131, bu \u00e7erezi kendi depolama alan\u0131na kaydeder.<\/li>\n
- Kullan\u0131c\u0131 ayn\u0131 siteye sonraki t\u00fcm isteklerinde, taray\u0131c\u0131 depolad\u0131\u011f\u0131
sessionId=abc123xyz<\/code> \u00e7erezini otomatik olarak sunucuya g\u00f6nderir.<\/li>\n- Sunucu, gelen \u00e7erezi okuyarak kullan\u0131c\u0131n\u0131n kimli\u011fini veya oturum durumunu belirler.<\/li>\n<\/ol>\n
\u00c7erezlerin kullan\u0131m alanlar\u0131 olduk\u00e7a geni\u015ftir. En belirgin \u00f6rnek, bir kullan\u0131c\u0131n\u0131n sisteme giri\u015f yapt\u0131\u011f\u0131nda kimlik do\u011frulama bilgisini i\u00e7eren bir oturum kimli\u011fini (session ID) depolamakt\u0131r. Ancak \u00e7erezler, ayn\u0131 zamanda al\u0131\u015fveri\u015f sepetlerini, dil tercihlerini, kullan\u0131c\u0131 izleme bilgilerini ve reklam hedeflemelerini de y\u00f6netmek i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, bir web sitesine girip dil ayar\u0131n\u0131 \u0130ngilizce’den T\u00fcrk\u00e7e’ye \u00e7evirdi\u011finizde, bu tercih genellikle bir \u00e7erezde saklan\u0131r, b\u00f6ylece siteyi bir sonraki ziyaretinizde tercihiniz hat\u0131rlan\u0131r.<\/p>\n
\u00c7erezlerin y\u00f6netimi taray\u0131c\u0131lar taraf\u0131ndan otomatik olarak yap\u0131lsa da, geli\u015ftiricilerin g\u00fcvenlik a\u00e7\u0131s\u0131ndan dikkat etmesi gereken \u00f6nemli noktalar vard\u0131r. \u00d6zellikle HttpOnly<\/code> (JavaScript eri\u015fimine kapal\u0131) ve Secure<\/code> (sadece HTTPS \u00fczerinden g\u00f6nderilir) gibi \u00f6znitelikler, \u00e7erezlerin \u00e7al\u0131nma riskini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r. Bu \u00f6znitelikleri do\u011fru bir \u015fekilde kullanmak, oturum y\u00f6netiminin temel g\u00fcvenlik katmanlar\u0131ndan birini olu\u015fturur. \u00d6rne\u011fin, bir oturum \u00e7erezinin HttpOnly<\/code> olarak i\u015faretlenmesi, XSS (Cross-Site Scripting) sald\u0131r\u0131lar\u0131nda bile sald\u0131rgan\u0131n \u00e7ereze JavaScript \u00fczerinden eri\u015fmesini engeller. Bu detaylar, \u00e7erezlerin basit bir veri depolama arac\u0131 olmaktan \u00e7ok daha fazlas\u0131 oldu\u011funu g\u00f6sterir.<\/p>\nSunucu Tarafl\u0131 Oturumlar (Sessions): G\u00fcvenli\u011fi Art\u0131rman\u0131n Yolu Nedir?<\/h2>\n
\u00c7erezler, kullan\u0131c\u0131n\u0131n kimli\u011fini hat\u0131rlamak i\u00e7in harika bir temel sa\u011flasa da, yaln\u0131zca \u00e7erezlerde hassas bilgileri depolamak g\u00fcvenli de\u011fildir. \u00c7\u00fcnk\u00fc \u00e7erezler istemci taraf\u0131nda depolan\u0131r ve potansiyel olarak k\u00f6t\u00fc niyetli kullan\u0131c\u0131lar taraf\u0131ndan manip\u00fcle edilebilir veya ele ge\u00e7irilebilir. \u0130\u015fte bu noktada sunucu tarafl\u0131 oturumlar (server-side sessions) devreye girer. Sunucu tarafl\u0131 oturumlar, oturum y\u00f6netiminin g\u00fcvenli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131ran bir yakla\u015f\u0131md\u0131r. Bu y\u00f6ntemde, hassas kullan\u0131c\u0131 bilgileri (kullan\u0131c\u0131 kimli\u011fi, yetki seviyesi, sepet i\u00e7eri\u011fi vb.) do\u011frudan taray\u0131c\u0131ya g\u00f6nderilmek yerine, sunucuda g\u00fcvenli bir \u015fekilde depolan\u0131r.<\/p>\n
Sunucu tarafl\u0131 oturum mekanizmas\u0131 \u015fu \u015fekilde i\u015fler:<\/p>\n
\n- Kullan\u0131c\u0131 kimlik do\u011frulamas\u0131 yapar (giri\u015f yapar).<\/li>\n
- Sunucu, bu kullan\u0131c\u0131 i\u00e7in benzersiz bir “oturum kimli\u011fi” (session ID) olu\u015fturur.<\/li>\n
- Sunucu, kullan\u0131c\u0131n\u0131n t\u00fcm oturum verilerini (\u00f6rne\u011fin, kullan\u0131c\u0131 ad\u0131, yetkilendirme bilgileri, al\u0131\u015fveri\u015f sepeti i\u00e7eri\u011fi) bu oturum kimli\u011fiyle ili\u015fkilendirerek kendi belle\u011finde, veritaban\u0131nda veya ba\u015fka bir depolama biriminde (Redis, Memcached gibi) saklar.<\/li>\n
- Bu oturum kimli\u011fi, genellikle bir \u00e7erez (HTTPOnly ve Secure bayraklar\u0131yla birlikte) arac\u0131l\u0131\u011f\u0131yla istemciye g\u00f6nderilir. \u0130stemcinin taray\u0131c\u0131s\u0131 yaln\u0131zca bu kimli\u011fi saklar, ger\u00e7ek oturum verilerini de\u011fil.<\/li>\n
- Kullan\u0131c\u0131 sonraki her iste\u011finde, taray\u0131c\u0131 bu oturum kimli\u011fi \u00e7erezini sunucuya geri g\u00f6nderir.<\/li>\n
- Sunucu, gelen oturum kimli\u011fini kullanarak depolad\u0131\u011f\u0131 oturum verilerini bulur ve kullan\u0131c\u0131n\u0131n durumunu tan\u0131r.<\/li>\n<\/ol>\n
Bu yakla\u015f\u0131m\u0131n en b\u00fcy\u00fck avantaj\u0131 g\u00fcvenliktir. Hassas veriler asla istemciye a\u00e7\u0131k bir \u015fekilde g\u00f6nderilmez. \u0130stemci, sadece bir referans noktas\u0131 olan oturum kimli\u011fini tutar. Bir sald\u0131rgan \u00e7erezleri ele ge\u00e7irse bile, sadece oturum kimli\u011fine eri\u015fmi\u015f olur, do\u011frudan kullan\u0131c\u0131 bilgilerine de\u011fil. Sunucu, bu kimli\u011fin ge\u00e7erlili\u011fini kontrol edebilir ve \u015f\u00fcpheli durumlarda oturumu sonland\u0131rabilir.<\/p>\n
Vaka Analizi: E-ticaret Sepeti<\/strong>
\n Bir e-ticaret uygulamas\u0131n\u0131 d\u00fc\u015f\u00fcnelim. Kullan\u0131c\u0131 sisteme giri\u015f yapar ve \u00fcr\u00fcnleri sepetine ekler. E\u011fer sepet i\u00e7eri\u011fi do\u011frudan bir \u00e7erezde depolansa, kullan\u0131c\u0131 taray\u0131c\u0131 \u00e7erezlerini manip\u00fcle ederek sepete olmayan \u00fcr\u00fcnleri ekleyebilir veya fiyatlar\u0131 de\u011fi\u015ftirebilir. Ancak sunucu tarafl\u0131 oturum kullan\u0131ld\u0131\u011f\u0131nda:<\/p>\n\n- Kullan\u0131c\u0131 giri\u015f yapt\u0131\u011f\u0131nda sunucu ona bir oturum kimli\u011fi verir (\u00f6rne\u011fin,
sessionid=xyz789<\/code>).<\/li>\n- Kullan\u0131c\u0131 sepete bir \u00fcr\u00fcn ekledi\u011finde, bu \u00fcr\u00fcn bilgisi sunucudaki
xyz789<\/code> oturumuyla ili\u015fkilendirilir.<\/li>\n- Kullan\u0131c\u0131 farkl\u0131 bir sayfaya gitti\u011finde, taray\u0131c\u0131
sessionid=xyz789<\/code> \u00e7erezini g\u00f6nderir.<\/li>\n- Sunucu, bu ID ile ili\u015fkili olan sepetteki \u00fcr\u00fcnleri getirir ve g\u00f6sterir.<\/li>\n<\/ul>\n
Bu sayede sepet i\u00e7eri\u011fi g\u00fcvenli bir \u015fekilde sunucuda kal\u0131r ve istemci taraf\u0131nda manip\u00fcle edilemez. Ayr\u0131ca, sunucu taraf\u0131nda oturumlar sayesinde, kullan\u0131c\u0131 uygulamadan \u00e7\u0131ksa bile (taray\u0131c\u0131y\u0131 kapatsa bile, e\u011fer kal\u0131c\u0131 bir \u00e7erezle birlikte kullan\u0131l\u0131yorsa) oturum bilgileri belli bir s\u00fcre saklanabilir. Kullan\u0131c\u0131 geri d\u00f6nd\u00fc\u011f\u00fcnde, e\u011fer oturum hala ge\u00e7erliyse, kald\u0131\u011f\u0131 yerden devam edebilir.<\/p>\n
Ancak sunucu tarafl\u0131 oturumlar\u0131n dezavantajlar\u0131 da vard\u0131r. \u00d6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli uygulamalarda ve da\u011f\u0131t\u0131k sistemlerde (microservices gibi), oturum verilerinin farkl\u0131 sunucular aras\u0131nda payla\u015f\u0131lmas\u0131 veya senkronize edilmesi karma\u015f\u0131k hale gelebilir. Her sunucunun kendi oturum deposu varsa, bir kullan\u0131c\u0131n\u0131n iste\u011fi farkl\u0131 bir sunucuya y\u00f6nlendirildi\u011finde oturum bilgisi kaybolabilir. Bu durumu a\u015fmak i\u00e7in “yap\u0131\u015fkan oturumlar” (sticky sessions) veya merkezi oturum depolama (\u00f6rne\u011fin, Redis) gibi \u00e7\u00f6z\u00fcmler kullan\u0131l\u0131r. Yap\u0131\u015fkan oturumlar, bir kullan\u0131c\u0131n\u0131n t\u00fcm isteklerinin ayn\u0131 sunucuya y\u00f6nlendirilmesini sa\u011flarken, merkezi oturum depolama ise t\u00fcm sunucular\u0131n ayn\u0131 oturum veritaban\u0131n\u0131 kullanmas\u0131na olanak tan\u0131r. Bu yakla\u015f\u0131mlar, sunucu tarafl\u0131 oturumlar\u0131n \u00f6l\u00e7eklenebilirlik zorluklar\u0131n\u0131 \u00e7\u00f6zmek i\u00e7in \u00f6nemlidir.<\/p>\n
Modern Oturum Y\u00f6netimi: JWT (JSON Web Tokens) Nedir ve Nas\u0131l Kullan\u0131l\u0131r?<\/h2>\n
Geleneksel sunucu tarafl\u0131 oturumlar baz\u0131 \u00f6l\u00e7eklenebilirlik sorunlar\u0131na yol a\u00e7abilirken, \u00f6zellikle API odakl\u0131 uygulamalar, mikroservis mimarileri ve mobil uygulamalar i\u00e7in daha esnek ve hafif bir alternatif olan JSON Web Tokens (JWT) pop\u00fclerlik kazanm\u0131\u015ft\u0131r. JWT, istemci-sunucu ileti\u015fimi i\u00e7in kompakt, URL a\u00e7\u0131s\u0131ndan g\u00fcvenli bir \u015fekilde bilgi al\u0131\u015fveri\u015fi yapman\u0131n bir yoludur. Temel fark, JWT ile oturum bilgisinin sunucuda depolanmak yerine, token’\u0131n kendisinde \u015fifrelenmi\u015f veya imzalanm\u0131\u015f olarak ta\u015f\u0131nmas\u0131d\u0131r.<\/p>\n
Bir JWT temelde \u00fc\u00e7 b\u00f6l\u00fcmden olu\u015fur, her biri bir nokta (.) ile ayr\u0131l\u0131r:<\/p>\n
\n- Ba\u015fl\u0131k (Header):<\/strong> Token t\u00fcr\u00fcn\u00fc (JWT) ve kullan\u0131lan imzalama algoritmas\u0131n\u0131 (HMAC SHA256 veya RSA gibi) i\u00e7erir. Bu k\u0131s\u0131m Base64url ile kodlan\u0131r.<\/li>\n
- Y\u00fck (Payload\/Claims):<\/strong> Bu b\u00f6l\u00fcm, kullan\u0131c\u0131n\u0131n kimli\u011fi, yetkilendirme rolleri, token’\u0131n s\u00fcresi (expiration time) gibi asl\u0131nda oturum bilgilerini ta\u015f\u0131yan verileri i\u00e7erir. Bunlara “claim” denir ve genellikle JSON format\u0131ndad\u0131r. Bu k\u0131s\u0131m da Base64url ile kodlan\u0131r.<\/li>\n
- \u0130mza (Signature):<\/strong> Ba\u015fl\u0131k ve y\u00fck Base64url ile kodland\u0131ktan sonra, gizli bir anahtar kullan\u0131larak bu iki b\u00f6l\u00fcm\u00fcn birle\u015fimiyle hesaplanan bir hash de\u011feridir. \u0130mza, token’\u0131n b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc do\u011frulamak ve i\u00e7eri\u011finin de\u011fi\u015ftirilip de\u011fi\u015ftirilmedi\u011fini kontrol etmek i\u00e7in kullan\u0131l\u0131r. Sunucu, bu imza sayesinde token’\u0131n ge\u00e7erli ve g\u00fcvenilir olup olmad\u0131\u011f\u0131n\u0131 anlar.<\/li>\n<\/ol>\n
Bir JWT’nin ak\u0131\u015f\u0131 \u015f\u00f6yledir:<\/p>\n
\n- Kullan\u0131c\u0131 kimlik do\u011frulamas\u0131 yapar (kullan\u0131c\u0131 ad\u0131 ve \u015fifre g\u00f6nderir).<\/li>\n
- Sunucu, kimlik do\u011frulaman\u0131n ba\u015far\u0131l\u0131 oldu\u011funu do\u011frular ve kullan\u0131c\u0131ya \u00f6zel bilgilerle (\u00f6rne\u011fin, kullan\u0131c\u0131 ID’si, rolleri) bir JWT olu\u015fturur.<\/li>\n
- Bu JWT, sunucu taraf\u0131ndan istemciye (genellikle bir HTTP yan\u0131t ba\u015fl\u0131\u011f\u0131nda veya yan\u0131t g\u00f6vdesinde) g\u00f6nderilir.<\/li>\n
- \u0130stemci, bu JWT’yi taray\u0131c\u0131n\u0131n yerel depolamas\u0131nda (localStorage, sessionStorage) veya bir \u00e7erezde saklar.<\/li>\n
- Kullan\u0131c\u0131 sonraki her iste\u011finde, bu JWT’yi
Authorization<\/code> ba\u015fl\u0131\u011f\u0131 alt\u0131nda (Bearer token<\/code> format\u0131nda) sunucuya geri g\u00f6nderir.<\/li>\n- Sunucu, gelen JWT’nin imzas\u0131n\u0131 gizli anahtar\u0131yla do\u011frular. \u0130mza ge\u00e7erliyse, token’\u0131n i\u00e7eri\u011findeki bilgilere (payload) g\u00fcvenilir ve kullan\u0131c\u0131n\u0131n kimli\u011fini veya yetkilerini belirler.<\/li>\n<\/ol>\n
Bir JWT \u00f6rne\u011fi \u015f\u00f6yle g\u00f6r\u00fcnebilir:<\/p>\n
\neyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.\neyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFuYSBVc2VyIiwiaWF0IjoxNTE2MjM5MDIyfQ.\nSflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c\n <\/pre>\n<\/code><\/p>\n
JWT'lerin en b\u00fcy\u00fck avantaj\u0131, \"durumsuz\" (stateless) olmalar\u0131d\u0131r. Sunucu, kullan\u0131c\u0131n\u0131n oturum bilgilerini kendi taraf\u0131nda depolamak zorunda kalmaz. Her istekte g\u00f6nderilen JWT, kullan\u0131c\u0131n\u0131n kimlik ve yetki bilgilerini kendi i\u00e7inde bar\u0131nd\u0131rd\u0131\u011f\u0131 i\u00e7in, sunucunun veritaban\u0131na her seferinde sorgu g\u00f6ndermesi veya merkezi bir oturum deposuna ba\u011flanmas\u0131 gerekmez. Bu, \u00f6zellikle yatay \u00f6l\u00e7eklenebilirlik (horizontal scaling) a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck bir fayda sa\u011flar, \u00e7\u00fcnk\u00fc herhangi bir sunucu gelen token'\u0131 do\u011frulayabilir ve i\u015fleyebilir. Mikroservis mimarilerinde veya mobil API'lerinde bu \u00f6zellik vazge\u00e7ilmezdir.<\/p>\n
Ancak JWT'lerin de dezavantajlar\u0131 vard\u0131r. En \u00f6nemlisi, bir token olu\u015fturulduktan sonra s\u00fcresi dolana kadar iptal edilmesinin zor olmas\u0131d\u0131r. Bir kullan\u0131c\u0131n\u0131n \u015fifresi de\u011fi\u015fse veya hesab\u0131 kilitlense bile, elindeki JWT ge\u00e7erlili\u011fini korur. Bu sorunu \u00e7\u00f6zmek i\u00e7in \"refresh token\" mekanizmalar\u0131 kullan\u0131l\u0131r. Ayr\u0131ca, token'\u0131n boyutu \u00e7erezlerden daha b\u00fcy\u00fck olabilir ve her istekle birlikte g\u00f6nderilmesi bant geni\u015fli\u011fi \u00fczerinde k\u00fc\u00e7\u00fck bir etki yaratabilir. G\u00fcvenlik a\u00e7\u0131s\u0131ndan, gizli anahtar\u0131n \u00e7al\u0131nmamas\u0131 ve token'\u0131n depoland\u0131\u011f\u0131 istemci taraf\u0131 ortam\u0131n (\u00f6rne\u011fin localStorage) XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 korunmas\u0131 hayati \u00f6nem ta\u015f\u0131r.<\/p>\n
Oturum Y\u00f6netiminde G\u00fcvenlik Zafiyetleri Nelerdir ve Nas\u0131l \u00d6nlenir?<\/h2>\n
Oturum y\u00f6netimi, bir web uygulamas\u0131n\u0131n g\u00fcvenlik mimarisinin en kritik bile\u015fenlerinden biridir. G\u00fcvenli bir oturum y\u00f6netimi olmadan, di\u011fer t\u00fcm g\u00fcvenlik \u00f6nlemleri etkisiz kalabilir. Ne yaz\u0131k ki, oturum mekanizmalar\u0131 s\u0131kl\u0131kla sald\u0131rganlar\u0131n hedefi haline gelen \u00e7e\u015fitli zafiyetlere sahiptir. Bu zafiyetleri anlamak ve bunlara kar\u015f\u0131 \u00f6nlemler almak, kullan\u0131c\u0131 verilerini ve uygulama b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc korumak i\u00e7in hayati \u00f6nem ta\u015f\u0131r.<\/p>\n
Yayg\u0131n Oturum Y\u00f6netimi G\u00fcvenlik Zafiyetleri:<\/h3>\n\n- Oturum Ka\u00e7\u0131rma (Session Hijacking):<\/strong> Bir sald\u0131rgan\u0131n ge\u00e7erli bir oturum kimli\u011fini (session ID) \u00e7alarak, o kullan\u0131c\u0131ym\u0131\u015f gibi uygulamaya eri\u015fmesidir. Bu genellikle \u00e7erezlerin \u00e7al\u0131nmas\u0131yla ger\u00e7ekle\u015fir.<\/li>\n
- \u00c7apraz Site Betik \u00c7al\u0131\u015ft\u0131rma (Cross-Site Scripting - XSS):<\/strong> Sald\u0131rgan\u0131n web uygulamas\u0131na k\u00f6t\u00fc niyetli istemci taraf\u0131 betik kodlar\u0131 enjekte etmesiyle olur. Bu kodlar, kullan\u0131c\u0131lar\u0131n oturum \u00e7erezlerini okuyabilir ve sald\u0131rgana g\u00f6nderebilir.<\/li>\n
- \u00c7apraz Site \u0130stek Sahtecili\u011fi (Cross-Site Request Forgery - CSRF):<\/strong> Sald\u0131rgan\u0131n, kullan\u0131c\u0131n\u0131n kimlik do\u011frulamas\u0131 yap\u0131lm\u0131\u015f oturumundan, kullan\u0131c\u0131n\u0131n bilgisi veya r\u0131zas\u0131 olmadan i\u015flem yapmas\u0131n\u0131 sa\u011flamas\u0131d\u0131r. \u00d6rne\u011fin, kullan\u0131c\u0131n\u0131n bankac\u0131l\u0131k sitesinde para transferi yapmas\u0131n\u0131 sa\u011flayan bir istek g\u00f6ndermesi.<\/li>\n
- Oturum Sabitleme (Session Fixation):<\/strong> Sald\u0131rgan\u0131n, kullan\u0131c\u0131 kimlik do\u011frulamas\u0131 yapmadan \u00f6nce bir oturum kimli\u011fi belirlemesi ve bu kimli\u011fi kullan\u0131c\u0131ya kabul ettirmesidir. Kullan\u0131c\u0131 bu kimlikle giri\u015f yapt\u0131\u011f\u0131nda, sald\u0131rgan ayn\u0131 kimli\u011fi kullanarak oturumu ele ge\u00e7irebilir.<\/li>\n
- Kaba Kuvvet (Brute Force) ve Tahmin Edilebilir Oturum Kimlikleri:<\/strong> Zay\u0131f veya tahmin edilebilir oturum kimlikleri (\u00f6rne\u011fin, ard\u0131\u015f\u0131k say\u0131lar), sald\u0131rganlar\u0131n ge\u00e7erli bir oturum kimli\u011fini kolayca tahmin etmesine olanak tan\u0131r.<\/li>\n
- Token A\u00e7\u0131\u011fa \u00c7\u0131kmas\u0131 (JWT \u00d6zel):<\/strong> JWT'nin bir \u015fekilde ele ge\u00e7irilmesi durumunda, s\u00fcresi dolana kadar yetkisiz eri\u015fim sa\u011flayabilir. \u0130ptal mekanizmalar\u0131n\u0131n eksikli\u011fi risk olu\u015fturur.<\/li>\n<\/ol>\n
Oturum Y\u00f6netiminde En \u0130yi Uygulamalar ve \u00d6nlemler:<\/h3>\n
Bu zafiyetlere kar\u015f\u0131 koymak i\u00e7in bir dizi g\u00fcvenlik \u00f6nlemi al\u0131nmal\u0131d\u0131r:<\/p>\n
\n- HTTPS Kullan\u0131m\u0131:<\/strong> T\u00fcm ileti\u015fimde HTTPS (Secure Sockets Layer\/Transport Layer Security) kullanmak zorunludur. Bu, oturum kimliklerinin a\u011f \u00fczerinden \u015fifresiz olarak g\u00f6nderilmesini ve dolay\u0131s\u0131yla dinlenmesini (eavesdropping) engeller. \u00c7erezler i\u00e7in
Secure<\/code> bayra\u011f\u0131n\u0131 kullanmak, \u00e7erezlerin yaln\u0131zca HTTPS \u00fczerinden g\u00f6nderilmesini sa\u011flar.<\/li>\n- HttpOnly \u00c7erez Bayra\u011f\u0131:<\/strong> Oturum kimliklerini ta\u015f\u0131yan \u00e7erezler i\u00e7in
HttpOnly<\/code> bayra\u011f\u0131n\u0131 kullan\u0131n. Bu bayrak, istemci taraf\u0131 betiklerinin (JavaScript) \u00e7erezlere eri\u015fmesini engeller ve XSS sald\u0131r\u0131lar\u0131nda \u00e7erez \u00e7al\u0131nmas\u0131 riskini azalt\u0131r.<\/li>\n- G\u00fc\u00e7l\u00fc ve Rastgele Oturum Kimlikleri:<\/strong> Oturum kimlikleri yeterince uzun, rastgele ve tahmin edilemez olmal\u0131d\u0131r. Kriptografik olarak g\u00fcvenli rastgele say\u0131 \u00fcrete\u00e7leri kullan\u0131lmal\u0131d\u0131r.<\/li>\n
- Oturum S\u00fcreleri ve Yenileme:<\/strong>\n
\n- Oturumlar\u0131n makul bir ya\u015fam s\u00fcresi olmal\u0131d\u0131r. Etkin olmayan oturumlar otomatik olarak sona erdirilmelidir (idle timeout).<\/li>\n
- Hassas i\u015flemlerden (\u015fifre de\u011fi\u015ftirme, para transferi) sonra oturum kimli\u011fi mutlaka yenilenmelidir (session regeneration). Bu, oturum sabitleme sald\u0131r\u0131lar\u0131n\u0131 \u00f6nler.<\/li>\n
- JWT kullan\u0131l\u0131yorsa, k\u0131sa \u00f6m\u00fcrl\u00fc eri\u015fim tokenlar\u0131 ve daha uzun \u00f6m\u00fcrl\u00fc ancak tek kullan\u0131ml\u0131k yenileme tokenlar\u0131 (refresh tokens) kombinasyonu kullan\u0131lmal\u0131d\u0131r. Yenileme tokenlar\u0131, kullan\u0131c\u0131 kimlik do\u011frulamas\u0131 gerektirmeden yeni bir eri\u015fim token\u0131 almak i\u00e7in kullan\u0131l\u0131r ve tek seferlik kullan\u0131mdan sonra veya \u015f\u00fcpheli durumlarda iptal edilebilir olmal\u0131d\u0131r.<\/li>\n<\/ul>\n<\/li>\n
- CSRF Korumas\u0131:<\/strong> CSRF sald\u0131r\u0131lar\u0131na kar\u015f\u0131, her hassas i\u015flem i\u00e7in benzersiz ve rastgele CSRF tokenlar\u0131 kullan\u0131lmal\u0131d\u0131r. Bu tokenlar, formlar i\u00e7inde gizli alanlar olarak veya HTTP ba\u015fl\u0131klar\u0131nda g\u00f6nderilebilir ve sunucu taraf\u0131ndan do\u011frulan\u0131r.<\/li>\n
- XSS Korumas\u0131:<\/strong> Kullan\u0131c\u0131 girdilerini her zaman sanitize edin (temizleyin) ve \u00e7\u0131k\u0131\u015f kodlamas\u0131 (output encoding) uygulay\u0131n. \u0130\u00e7erik G\u00fcvenlik Politikas\u0131 (Content Security Policy - CSP) gibi mekanizmalarla XSS riskini azalt\u0131n.<\/li>\n
- G\u00fcvenli Depolama (JWT i\u00e7in):<\/strong> JWT'ler istemci taraf\u0131nda depolan\u0131rken, \u00f6zellikle taray\u0131c\u0131n\u0131n
localStorage<\/code>'\u0131 XSS'e kar\u015f\u0131 savunmas\u0131z olabilir. G\u00fcvenlik kayg\u0131s\u0131 olan uygulamalarda, tokenlar\u0131 HttpOnly<\/code> \u00e7erezlerinde saklamak daha g\u00fcvenli bir alternatif olabilir. Ancak bu, CSRF sald\u0131r\u0131lar\u0131na kar\u015f\u0131 ek koruma gerektirir.<\/li>\n- Oturum \u0130ptali (Logout):<\/strong> Kullan\u0131c\u0131 \u00e7\u0131k\u0131\u015f yapt\u0131\u011f\u0131nda sunucu taraf\u0131nda oturum kimli\u011fi derhal ge\u00e7ersiz k\u0131l\u0131nmal\u0131d\u0131r. JWT tabanl\u0131 sistemlerde, token'\u0131n sunucu taraf\u0131ndaki bir kara listede (blacklist) i\u015faretlenmesi veya yenileme token\u0131n\u0131n iptali sa\u011flanmal\u0131d\u0131r.<\/li>\n<\/ul>\n\n Uzman \u0130pucu:<\/strong> JWT kullan\u0131rken, eri\u015fim tokenlar\u0131n\u0131z\u0131n k\u0131sa \u00f6m\u00fcrl\u00fc oldu\u011fundan emin olun (\u00f6rne\u011fin, 15-30 dakika). Daha uzun s\u00fcreli oturumlar i\u00e7in,
HttpOnly<\/code> ve Secure<\/code> bayraklar\u0131yla i\u015faretlenmi\u015f, tek kullan\u0131ml\u0131k ve sunucu taraf\u0131nda iptal edilebilir yenileme tokenlar\u0131 (refresh tokens) kullan\u0131n. Bu strateji, ele ge\u00e7irilen bir eri\u015fim token\u0131n\u0131n k\u00f6t\u00fcye kullan\u0131m s\u00fcresini s\u0131n\u0131rlar ve token iptalini m\u00fcmk\u00fcn k\u0131lar.\n <\/div>\nBu g\u00fcvenlik \u00f6nlemleri, web uygulamalar\u0131n\u0131zdaki oturum y\u00f6netimini \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirecek ve kullan\u0131c\u0131lar\u0131n\u0131z\u0131n verilerini k\u00f6t\u00fc niyetli sald\u0131r\u0131lardan korumaya yard\u0131mc\u0131 olacakt\u0131r. G\u00fcvenlik, tek seferlik bir i\u015flemden ziyade s\u00fcrekli bir s\u00fcre\u00e7tir ve d\u00fczenli denetimler ve g\u00fcncellemeler gerektirir.<\/p>\n
Mobil Uygulamalar \u0130\u00e7in Oturum Y\u00f6netimi Stratejileri Nas\u0131l Belirlenir?<\/h2>\n
Mobil uygulamalar, web tabanl\u0131 uygulamalardan farkl\u0131 bir ortamda \u00e7al\u0131\u015ft\u0131klar\u0131 i\u00e7in oturum y\u00f6netimi stratejileri de kendine \u00f6zg\u00fc dinamiklere sahiptir. Web taray\u0131c\u0131s\u0131n\u0131n \u00e7erezleri otomatik y\u00f6netme kolayl\u0131\u011f\u0131 mobil platformlarda genellikle mevcut de\u011fildir ve mobil uygulamalar\u0131n API'ler \u00fczerinden sunucularla daha yo\u011fun etkile\u015fimde bulunmas\u0131, token tabanl\u0131 \u00e7\u00f6z\u00fcmleri \u00f6n plana \u00e7\u0131kar\u0131r. Bu b\u00f6l\u00fcmde mobil uygulamalar i\u00e7in en uygun oturum y\u00f6netimi stratejilerini ve dikkat edilmesi gereken noktalar\u0131 ele alaca\u011f\u0131z.<\/p>\n
Mobil Ortam\u0131n \u00d6zellikleri ve Oturum Y\u00f6netimine Etkileri:<\/h3>\n\n- \u00c7erez Y\u00f6netimi:<\/strong> Mobil uygulamalarda, yerel taray\u0131c\u0131 (WebView) d\u0131\u015f\u0131nda do\u011frudan \u00e7erez y\u00f6netimi genellikle geli\u015ftiricinin sorumlulu\u011fundad\u0131r. Baz\u0131 mobil platformlar \u00e7erez depolar\u0131 sunsa da, web'deki kadar entegre ve \u015feffaf de\u011fildir. Bu nedenle, oturum kimli\u011fini bir \u00e7erezde saklamak yerine, do\u011frudan tokenlar \u00fczerinde \u00e7al\u0131\u015fmak daha yayg\u0131nd\u0131r.<\/li>\n
- API Odakl\u0131 \u0130leti\u015fim:<\/strong> Mobil uygulamalar genellikle bir arka u\u00e7 (backend) API'si ile ileti\u015fim kurar. Bu API'ler durumsuz olma e\u011filimindedir ve her istekte kimlik do\u011frulama\/yetkilendirme bilgisini bekler.<\/li>\n
- G\u00fcvenli Depolama:<\/strong> Mobil cihazlarda tokenlar\u0131n veya kimlik bilgilerinin g\u00fcvenli bir \u015fekilde depolanmas\u0131 kritik \u00f6neme sahiptir. Uygulama i\u00e7i depolama alanlar\u0131 (
SharedPreferences<\/code> Android'de, UserDefaults<\/code> iOS'ta) k\u00f6t\u00fcye kullan\u0131ma a\u00e7\u0131k olabilir. G\u00fcvenli depolama mekanizmalar\u0131 (\u00f6rn. Android Keystore, iOS Keychain) kullan\u0131lmal\u0131d\u0131r.<\/li>\n- Offline \u00c7al\u0131\u015fma:<\/strong> Baz\u0131 mobil uygulamalar \u00e7evrimd\u0131\u015f\u0131 \u00e7al\u0131\u015fabilme yetene\u011fine sahiptir. Bu durum, oturum bilgilerinin nas\u0131l y\u00f6netilece\u011fi ve \u00e7evrimd\u0131\u015f\u0131 kimlik do\u011frulaman\u0131n nas\u0131l sa\u011flanaca\u011f\u0131 konusunda ek karma\u015f\u0131kl\u0131klar getirir.<\/li>\n<\/ul>\n
Mobil Uygulamalarda Oturum Y\u00f6netimi \u0130\u00e7in Pop\u00fcler Stratejiler:<\/h3>\n
1. JWT (JSON Web Tokens) ve Yenileme Tokenlar\u0131 (Refresh Tokens):<\/strong>
\n Mobil uygulamalar i\u00e7in en yayg\u0131n ve \u00f6nerilen y\u00f6ntem JWT kullan\u0131m\u0131d\u0131r. Ancak tek ba\u015f\u0131na JWT'ler, ele ge\u00e7irildiklerinde iptal edilmeleri zor oldu\u011fu i\u00e7in risk ta\u015f\u0131r. Bu nedenle, k\u0131sa \u00f6m\u00fcrl\u00fc bir Eri\u015fim Token\u0131 (Access Token)<\/strong> ile daha uzun \u00f6m\u00fcrl\u00fc bir Yenileme Token\u0131 (Refresh Token)<\/strong> kombinasyonu kullan\u0131l\u0131r:<\/p>\n\n- Eri\u015fim Token\u0131 (Access Token):<\/strong> K\u0131sa bir s\u00fcre i\u00e7in (\u00f6rne\u011fin 15-30 dakika) ge\u00e7erlidir ve API isteklerinde kimlik do\u011frulamas\u0131 i\u00e7in kullan\u0131l\u0131r. Bu token, HTTP
Authorization<\/code> ba\u015fl\u0131\u011f\u0131nda (Bearer<\/code> \u015femas\u0131yla) her istekte g\u00f6nderilir.<\/li>\n- Yenileme Token\u0131 (Refresh Token):<\/strong> Daha uzun bir \u00f6mre sahiptir (\u00f6rne\u011fin g\u00fcnler, haftalar). Eri\u015fim token\u0131 s\u00fcresi doldu\u011funda, mobil uygulama yeni bir eri\u015fim token\u0131 almak i\u00e7in bu yenileme token\u0131n\u0131 sunucuya g\u00f6nderir. Yenileme tokenlar\u0131, sadece yeni eri\u015fim tokenlar\u0131 almak i\u00e7in kullan\u0131l\u0131r ve API istekleri i\u00e7in kullan\u0131lmazlar.<\/li>\n<\/ul>\n
Bu Yap\u0131n\u0131n Avantajlar\u0131:<\/strong><\/p>\n\n- Eri\u015fim tokenlar\u0131 k\u0131sa \u00f6m\u00fcrl\u00fc oldu\u011fu i\u00e7in, ele ge\u00e7irilseler bile k\u00f6t\u00fcye kullan\u0131m s\u00fcresi s\u0131n\u0131rl\u0131d\u0131r.<\/li>\n
- Yenileme tokenlar\u0131, kullan\u0131c\u0131n\u0131n tekrar giri\u015f yapmas\u0131na gerek kalmadan uzun s\u00fcreli oturumlar sa\u011flar.<\/li>\n
- Yenileme tokenlar\u0131, sunucu taraf\u0131nda depolanabilir ve \u015f\u00fcpheli durumlarda iptal edilebilir, bu da token iptali sorununu \u00e7\u00f6zer.<\/li>\n<\/ul>\n
Depolama ve G\u00fcvenlik:<\/strong><\/p>\n\n- Eri\u015fim Token\u0131:<\/strong> Genellikle uygulama belle\u011finde saklan\u0131r. Uygulama kapat\u0131ld\u0131\u011f\u0131nda veya yeniden ba\u015flat\u0131ld\u0131\u011f\u0131nda kaybolabilir.<\/li>\n
- Yenileme Token\u0131:<\/strong> Mutlaka g\u00fcvenli bir depolama alan\u0131nda (\u00f6rn. Android Keystore, iOS Keychain) saklanmal\u0131d\u0131r. Bu mekanizmalar, tokenlar\u0131 \u015fifrelenmi\u015f olarak depolan\u0131r ve di\u011fer uygulamalar\u0131n veya k\u00f6t\u00fc niyetli yaz\u0131l\u0131mlar\u0131n eri\u015fmesini engeller.<\/li>\n<\/ul>\n
\u00d6rnek Ak\u0131\u015f:<\/strong><\/p>\n\n\/\/ 1. Kullan\u0131c\u0131 Giri\u015fi\nasync function login(username, password) {\n const response = await fetch('\/api\/login', {\n method: 'POST',\n body: JSON.stringify({ username, password })\n });\n const data = await response.json();\n \/\/ Sunucudan access_token ve refresh_token al\u0131n\u0131r\n secureStore.save('accessToken', data.accessToken); \/\/ Bellekte veya h\u0131zl\u0131 eri\u015fim deposunda\n secureStore.save('refreshToken', data.refreshToken); \/\/ G\u00fcvenli depolamada\n}\n\n\/\/ 2. API \u0130ste\u011fi\nasync function fetchData(url) {\n let accessToken = secureStore.get('accessToken');\n const response = await fetch(url, {\n headers: { 'Authorization': Bearer ${accessToken}<\/code> }\n });\n\n if (response.status === 401) { \/\/ Eri\u015fim token\u0131 s\u00fcresi dolmu\u015f\n const newAccessToken = await refreshAccessToken();\n if (newAccessToken) {\n accessToken = newAccessToken;\n \/\/ Yeni token ile iste\u011fi tekrar dene\n return fetch(url, {\n headers: { 'Authorization': Bearer ${accessToken}<\/code> }\n });\n } else {\n \/\/ Yenileme token\u0131 da ge\u00e7ersiz, kullan\u0131c\u0131y\u0131 \u00e7\u0131k\u0131\u015f yapmaya zorla\n logout();\n }\n }\n return response.json();\n}\n\n\/\/ 3. Eri\u015fim Token\u0131n\u0131 Yenileme\nasync function refreshAccessToken() {\n const refreshToken = secureStore.get('refreshToken');\n if (!refreshToken) return null;\n\n const response = await fetch('\/api\/refresh-token', {\n method: 'POST',\n body: JSON.stringify({ refreshToken })\n });\n if (response.ok) {\n const data = await response.json();\n secureStore.save('accessToken', data.accessToken);\n return data.accessToken;\n }\n return null;\n}\n <\/pre>\n<\/code><\/p>\n
Bu kod blo\u011fu, mobil uygulamalarda JWT ve refresh tokenlar\u0131n nas\u0131l kullan\u0131laca\u011f\u0131na dair basit bir ak\u0131\u015f\u0131 g\u00f6stermektedir. secureStore<\/code>, cihaz\u0131n g\u00fcvenli depolama mekanizmalar\u0131n\u0131 temsil eder.<\/p>\n2. \u00c7erez Tabanl\u0131 Oturumlar (Geleneksel Web G\u00f6r\u00fcn\u00fcmleri \u0130\u00e7in):<\/strong>
\n E\u011fer mobil uygulaman\u0131z i\u00e7inde WebView kullanarak web i\u00e7eri\u011fi g\u00f6steriyorsan\u0131z, bu webview'ler genellikle geleneksel \u00e7erez tabanl\u0131 oturumlar\u0131 destekleyebilir. Ancak bu, native mobil deneyimden farkl\u0131d\u0131r ve WebView'in kendi g\u00fcvenlik ba\u011flam\u0131n\u0131 y\u00f6netmek ek dikkat gerektirebilir.<\/p>\nMobil uygulamalar i\u00e7in oturum y\u00f6netimi stratejisi belirlenirken, uygulaman\u0131n g\u00fcvenlik ihtiya\u00e7lar\u0131, kullan\u0131c\u0131 deneyimi beklentileri ve platformun sundu\u011fu \u00f6zellikler g\u00f6z \u00f6n\u00fcnde bulundurulmal\u0131d\u0131r. Genel olarak, JWT ve yenileme tokenlar\u0131 kombinasyonu, modern mobil uygulamalar i\u00e7in en sa\u011flam ve \u00f6l\u00e7eklenebilir \u00e7\u00f6z\u00fcm\u00fc sunar.<\/p>\n
B\u00fcy\u00fck Sistemlerde Oturum Y\u00f6netimi: Performans ve \u00d6l\u00e7eklenebilirlik Nas\u0131l Sa\u011flan\u0131r?<\/h2>\n
Bir web uygulamas\u0131 kullan\u0131c\u0131 say\u0131s\u0131yla birlikte b\u00fcy\u00fcd\u00fc\u011f\u00fcnde, oturum y\u00f6netiminin performans\u0131 ve \u00f6l\u00e7eklenebilirli\u011fi kritik bir hale gelir. Y\u00fcksek trafikli sistemlerde, binlerce veya milyonlarca e\u015fzamanl\u0131 kullan\u0131c\u0131n\u0131n oturumunu verimli bir \u015fekilde y\u00f6netmek, uygulaman\u0131n genel yan\u0131t s\u00fcresini ve g\u00fcvenilirli\u011fini do\u011frudan etkiler. Bu b\u00f6l\u00fcmde, b\u00fcy\u00fck \u00f6l\u00e7ekli sistemlerde oturum y\u00f6netiminde kar\u015f\u0131la\u015f\u0131lan zorluklar\u0131 ve bunlar\u0131 a\u015fmak i\u00e7in kullan\u0131lan stratejileri inceleyece\u011fiz.<\/p>\n
\u00d6l\u00e7eklenebilirlik Sorunlar\u0131:<\/h3>\n
Geleneksel sunucu tarafl\u0131 oturumlar (session-based) i\u00e7in temel \u00f6l\u00e7eklenebilirlik sorunu, oturum verilerinin sunucu belle\u011finde veya yerel diskinde depolanmas\u0131ndan kaynaklan\u0131r. \u00c7ok say\u0131da sunucunun oldu\u011fu bir ortamda, bir kullan\u0131c\u0131n\u0131n her iste\u011fi farkl\u0131 bir sunucuya d\u00fc\u015febilir. E\u011fer oturum verileri yaln\u0131zca tek bir sunucuda depolan\u0131yorsa, kullan\u0131c\u0131 farkl\u0131 bir sunucuya y\u00f6nlendirildi\u011finde oturum bilgileri kaybolur ve kullan\u0131c\u0131n\u0131n tekrar kimlik do\u011frulamas\u0131 yapmas\u0131 gerekir. Bu da k\u00f6t\u00fc bir kullan\u0131c\u0131 deneyimine ve sunucu taraf\u0131nda ek y\u00fcke yol a\u00e7ar.<\/p>\n
\u00d6l\u00e7eklenebilir Oturum Y\u00f6netimi Stratejileri:<\/h3>\n
1. Merkezi Oturum Depolama (Centralized Session Storage):<\/strong>
\n Bu yakla\u015f\u0131m, t\u00fcm oturum verilerini ayr\u0131, merkezi bir depolama sisteminde tutar. Bu sayede, uygulaman\u0131n farkl\u0131 sunucular\u0131 (web sunucular\u0131 veya API gateway'ler) ayn\u0131 oturum veritaban\u0131na eri\u015febilir ve herhangi bir sunucu kullan\u0131c\u0131n\u0131n oturumunu tan\u0131yabilir. Pop\u00fcler merkezi oturum depolama \u00e7\u00f6z\u00fcmleri \u015funlard\u0131r:<\/p>\n\n- Redis:<\/strong> Y\u00fcksek performansl\u0131, bellek i\u00e7i bir anahtar-de\u011fer deposudur. Oturum verilerini \u00f6nbelle\u011fe almak i\u00e7in idealdir. D\u00fc\u015f\u00fck gecikme s\u00fcresi ve y\u00fcksek verim sunar.<\/li>\n
- Memcached:<\/strong> Redis'e benzer \u015fekilde bellek i\u00e7i \u00f6nbellekleme sistemidir. Daha basit bir yap\u0131ya sahiptir ve oturum verileri gibi ge\u00e7ici veriler i\u00e7in kullan\u0131labilir.<\/li>\n
- Veritabanlar\u0131 (Database):<\/strong> Baz\u0131 durumlarda, daha kal\u0131c\u0131 veya karma\u015f\u0131k oturum verileri i\u00e7in geleneksel ili\u015fkisel (PostgreSQL, MySQL) veya NoSQL (MongoDB, Cassandra) veritabanlar\u0131 kullan\u0131labilir. Ancak, bu genellikle Redis gibi \u00f6nbellek \u00e7\u00f6z\u00fcmlerinden daha yava\u015f olabilir.<\/li>\n<\/ul>\n
Merkezi Depolama Avantajlar\u0131:<\/strong><\/p>\n\n- Y\u00fcksek \u00d6l\u00e7eklenebilirlik:<\/strong> Uygulama sunucular\u0131 durumsuz hale gelir, bu da kolayca yatay olarak \u00f6l\u00e7eklenebilecekleri anlam\u0131na gelir.<\/li>\n
- Y\u00fcksek Eri\u015filebilirlik:<\/strong> Merkezi depolama sistemleri genellikle yedekli ve da\u011f\u0131t\u0131k olarak yap\u0131land\u0131r\u0131labilir, bu da oturum verilerinin kaybolma riskini azalt\u0131r.<\/li>\n<\/ul>\n
2. Yap\u0131\u015fkan Oturumlar (Sticky Sessions):<\/strong>
\n Bu y\u00f6ntem, bir y\u00fck dengeleyicinin (load balancer) ayn\u0131 kullan\u0131c\u0131n\u0131n sonraki t\u00fcm isteklerini, oturumunu ba\u015flatt\u0131\u011f\u0131 ayn\u0131 sunucuya y\u00f6nlendirmesini sa\u011flar. B\u00f6ylece, oturum verileri yaln\u0131zca o sunucunun belle\u011finde depolansa bile tutarl\u0131l\u0131k sa\u011flan\u0131r. Y\u00fck dengeleyici, kullan\u0131c\u0131n\u0131n ilk iste\u011findeki oturum kimli\u011fini veya IP adresini kullanarak bu \"yap\u0131\u015fkanl\u0131\u011f\u0131\" sa\u011flar.<\/p>\nYap\u0131\u015fkan Oturumlar Avantajlar\u0131:<\/strong><\/p>\n\n- Uygulama kodunda de\u011fi\u015fiklik gerektirmez, mevcut oturum y\u00f6netimini kullanabilir.<\/li>\n
- Ek bir merkezi depolama sistemi kurma ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r.<\/li>\n<\/ul>\n
Dezavantajlar\u0131:<\/strong><\/p>\n\n- Y\u00fck Dengesizli\u011fi:<\/strong> Baz\u0131 sunuculara daha fazla y\u00fck binebilir.<\/li>\n
- Sunucu Hatas\u0131:<\/strong> E\u011fer yap\u0131\u015fkan oturumun bulundu\u011fu sunucu \u00e7\u00f6kerse, kullan\u0131c\u0131 oturumunu kaybeder ve tekrar giri\u015f yapmak zorunda kal\u0131r.<\/li>\n<\/ul>\n
3. JWT (JSON Web Tokens) Kullan\u0131m\u0131:<\/strong>
\n Daha \u00f6nce de bahsedildi\u011fi gibi, JWT'ler varsay\u0131lan olarak durumsuz bir oturum y\u00f6netim yakla\u015f\u0131m\u0131 sunar. Oturum bilgisi do\u011frudan token i\u00e7inde ta\u015f\u0131nd\u0131\u011f\u0131 i\u00e7in, sunucular\u0131n oturum verilerini depolamas\u0131na gerek kalmaz. Herhangi bir sunucu gelen token'\u0131 do\u011frulayabilir ve i\u015fleyebilir.<\/p>\nJWT Avantajlar\u0131:<\/strong><\/p>\n\n- Do\u011fal \u00d6l\u00e7eklenebilirlik:<\/strong> Herhangi bir sunucu token'\u0131 i\u015fleyebilir, bu da yatay \u00f6l\u00e7eklemeyi \u00e7ok kolayla\u015ft\u0131r\u0131r.<\/li>\n
- Azalt\u0131lm\u0131\u015f Sunucu Y\u00fck\u00fc:<\/strong> Veritaban\u0131 veya \u00f6nbellek sorgular\u0131na gerek kalmaz.<\/li>\n
- Mikroservisler \u0130\u00e7in \u0130deal:<\/strong> Farkl\u0131 servisler ayn\u0131 token'\u0131 kullanarak kullan\u0131c\u0131n\u0131n kimli\u011fini do\u011frulayabilir.<\/li>\n<\/ul>\n
JWT Dezavantajlar\u0131:<\/strong><\/p>\n\n- Token iptali zordur (refresh token mekanizmas\u0131 ile \u00e7\u00f6z\u00fcl\u00fcr).<\/li>\n
- Token boyutu her istekle birlikte g\u00f6nderildi\u011fi i\u00e7in bant geni\u015fli\u011fini etkileyebilir (genellikle ihmal edilebilir).<\/li>\n<\/ul>\n
B\u00fcy\u00fck bir sistemde, bu stratejilerin bir kombinasyonu kullan\u0131labilir. \u00d6rne\u011fin, API'ler i\u00e7in JWT, daha geleneksel web tabanl\u0131 oturumlar i\u00e7in merkezi Redis tabanl\u0131 bir depolama. Hatta baz\u0131 sistemlerde, k\u0131sa \u00f6m\u00fcrl\u00fc JWT'ler ile birlikte, Redis'te tutulan refresh tokenlar\u0131 kullan\u0131larak hem \u00f6l\u00e7eklenebilirlik hem de token iptali kontrol\u00fc sa\u011flan\u0131r. Se\u00e7im, uygulaman\u0131n mimarisine, g\u00fcvenlik gereksinimlerine, trafik yo\u011funlu\u011funa ve mevcut altyap\u0131ya ba\u011fl\u0131d\u0131r. Ancak temel ama\u00e7, her kullan\u0131c\u0131n\u0131n oturumunu h\u0131zl\u0131, g\u00fcvenli ve tutarl\u0131 bir \u015fekilde y\u00f6netirken, sistemin performans\u0131n\u0131 ve \u00f6l\u00e7eklenebilirli\u011fini optimize etmektir.<\/p>\n
Vaka Analizi: B\u00fcy\u00fck \u00d6l\u00e7ekli Bir Uygulamada Oturum Y\u00f6netimi<\/h2>\nGer\u00e7ek Bir Senaryoda Oturum Y\u00f6netimi: E-ticaret Platformu \u00d6rne\u011fi<\/h3>\n
Bir e-ticaret platformunun b\u00fcy\u00fcme yolculu\u011funu ve oturum y\u00f6netimi kararlar\u0131n\u0131 ele alal\u0131m. Ba\u015flang\u0131\u00e7ta k\u00fc\u00e7\u00fck bir proje olarak yola \u00e7\u0131kan bu platform, zamanla milyonlarca kullan\u0131c\u0131ya hizmet veren devasa bir yap\u0131ya d\u00f6n\u00fc\u015ft\u00fc. \u0130lk a\u015famalarda basit bir oturum y\u00f6netim sistemi yeterliyken, kullan\u0131c\u0131 say\u0131s\u0131 artt\u0131k\u00e7a ve yeni \u00f6zellikler eklendik\u00e7e, daha karma\u015f\u0131k ve sa\u011flam bir stratejiye ihtiya\u00e7 duyuldu.<\/p>\n
Ba\u015flang\u0131\u00e7: Sunucu Tarafl\u0131 Oturumlar ve \u00c7erezler<\/h4>\n
Platformun ilk versiyonlar\u0131nda, geleneksel sunucu tarafl\u0131 oturumlar<\/strong> kullan\u0131ld\u0131. Kullan\u0131c\u0131 sisteme giri\u015f yapt\u0131\u011f\u0131nda, sunucu bir session ID<\/code> olu\u015fturuyor ve bu ID'yi HttpOnly<\/code> ve Secure<\/code> bayraklar\u0131yla i\u015faretlenmi\u015f bir \u00e7erez arac\u0131l\u0131\u011f\u0131yla taray\u0131c\u0131ya g\u00f6nderiyordu. Kullan\u0131c\u0131n\u0131n sepet bilgileri, kimlik do\u011frulama durumu ve ki\u015fisel ayarlar\u0131, sunucunun yerel dosya sisteminde depolanan oturum dosyalar\u0131 veya bir ili\u015fkisel veritaban\u0131 (MySQL) \u00fczerinde tutuluyordu.<\/p>\nAvantajlar\u0131:<\/strong> Uygulamas\u0131 kolay, g\u00fcvenlik y\u00f6netimi sunucu taraf\u0131nda merkeziydi.
\n Dezavantajlar\u0131:<\/strong> Platform b\u00fcy\u00fcd\u00fck\u00e7e, y\u00fck dengeleyicinin arkas\u0131na ek sunucular eklendi\u011finde \"yap\u0131\u015fkan oturumlar\" kullanmak zorunda kal\u0131nd\u0131. Bu, sunucu ar\u0131zalar\u0131nda oturum kayb\u0131na ve y\u00fck dengesizli\u011fine yol a\u00e7\u0131yordu. Ayr\u0131ca, her sunucunun kendi oturumunu y\u00f6netmesi, genel performans\u0131 d\u00fc\u015f\u00fcrmeye ba\u015flad\u0131.<\/p>\nGeli\u015fim: Merkezi Oturum Depolama ile \u00d6l\u00e7eklenebilirlik<\/h4>\n
Kullan\u0131c\u0131 taban\u0131 ve trafik artt\u0131k\u00e7a, yap\u0131\u015fkan oturumlar\u0131n dezavantajlar\u0131 belirginle\u015fti. Platform, merkezi oturum depolama<\/strong> stratejisine ge\u00e7meye karar verdi. MySQL yerine, y\u00fcksek performansl\u0131 ve bellek i\u00e7i bir anahtar-de\u011fer deposu olan Redis<\/strong>, oturum verilerini depolamak i\u00e7in kullan\u0131ld\u0131. T\u00fcm uygulama sunucular\u0131, oturum kimli\u011fi ile ili\u015fkilendirilmi\u015f kullan\u0131c\u0131 verilerini Redis'ten okuyup yazabiliyordu.<\/p>\nAvantajlar\u0131:<\/strong> Uygulama sunucular\u0131 art\u0131k tamamen durumsuz hale geldi ve yatay olarak kolayca \u00f6l\u00e7eklenebilir hale geldi. Herhangi bir sunucu, kullan\u0131c\u0131n\u0131n oturumunu tan\u0131yabildi\u011fi i\u00e7in y\u00fck dengeleme daha verimli hale geldi. Sunucu ar\u0131zalar\u0131, Redis'in y\u00fcksek eri\u015filebilirlik (HA) yap\u0131s\u0131 sayesinde oturum kayb\u0131na neden olmad\u0131.
\n Dezavantajlar\u0131:<\/strong> Redis sunucular\u0131n\u0131n y\u00f6netimi ve yedeklemesi i\u00e7in ek bir operasyonel y\u00fck olu\u015ftu. Her istekte Redis'e yap\u0131lan \u00e7a\u011fr\u0131lar, a\u011f gecikmesine ve Redis sunucular\u0131n\u0131n yo\u011funlu\u011funa ba\u011fl\u0131 olarak k\u00fc\u00e7\u00fck bir performans maliyeti olu\u015fturabilirdi.<\/p>\nModernizasyon: Mikroservisler ve Mobil API'ler \u0130\u00e7in JWT<\/h4>\n
Platform, mobil uygulama ve mikroservis mimarisine ge\u00e7i\u015f yapt\u0131\u011f\u0131nda, geleneksel sunucu tarafl\u0131 oturumlar yetersiz kalmaya ba\u015flad\u0131. Mikroservisler aras\u0131nda kimlik do\u011frulama ve yetkilendirme bilgilerini ta\u015f\u0131mak, merkezi oturum depolama ile bile ek karma\u015f\u0131kl\u0131k getiriyordu. Bu a\u015famada, JWT (JSON Web Tokens)<\/strong> devreye girdi.<\/p>\nUygulama:<\/strong><\/p>\n\n- Kullan\u0131c\u0131lar web veya mobil uygulama \u00fczerinden giri\u015f yapt\u0131klar\u0131nda, yetkilendirme servisi k\u0131sa \u00f6m\u00fcrl\u00fc bir Eri\u015fim Token\u0131<\/strong> (\u00f6rne\u011fin 15 dakika) ve daha uzun \u00f6m\u00fcrl\u00fc,
HttpOnly<\/code> ve Secure<\/code> i\u015faretli bir \u00e7erezde saklanan bir Yenileme Token\u0131<\/strong> (\u00f6rne\u011fin 7 g\u00fcn) veriyordu.<\/li>\n- Mobil uygulamalar, eri\u015fim token\u0131n\u0131 cihaz\u0131n g\u00fcvenli depolama alan\u0131nda (\u00f6rn. Keychain\/Keystore) saklarken, web taraf\u0131 eri\u015fim token\u0131n\u0131
localStorage<\/code>'da (dikkatle ve XSS korumas\u0131 ile) tutuyordu.<\/li>\n- Her API iste\u011fi,
Authorization: Bearer [Access Token]<\/code> ba\u015fl\u0131\u011f\u0131 ile g\u00f6nderiliyordu.<\/li>\n- Yetkilendirme kap\u0131s\u0131 (API Gateway), gelen her iste\u011fin JWT'sini do\u011fruluyor ve token ge\u00e7erliyse iste\u011fi ilgili mikroservise y\u00f6nlendiriyordu. Mikroservisler, tekrar veritaban\u0131na sorgu yapmadan kullan\u0131c\u0131n\u0131n kimlik ve yetki bilgilerini JWT \u00fczerinden okuyabiliyordu.<\/li>\n
- Eri\u015fim token\u0131 s\u00fcresi doldu\u011funda, istemci (mobil veya web) yenileme token\u0131n\u0131 kullanarak yetkilendirme servisinden yeni bir eri\u015fim token\u0131 talep ediyordu. Yenileme tokenlar\u0131 Redis'te tutuluyor ve gerekirse kara listeye al\u0131narak iptal edilebiliyordu.<\/li>\n<\/ul>\n
Avantajlar\u0131:<\/strong><\/p>\n\n- Mikroservis Entegrasyonu:<\/strong> Servisler aras\u0131 kimlik do\u011frulama ve yetkilendirme sorunsuz hale geldi. Her servis, token'\u0131 ba\u011f\u0131ms\u0131z olarak do\u011frulayabiliyordu.<\/li>\n
- Y\u00fcksek Performans ve \u00d6l\u00e7eklenebilirlik:<\/strong> Her istek i\u00e7in veritaban\u0131 veya Redis sorgusu yapma ihtiyac\u0131 azald\u0131 (sadece yenileme tokenlar\u0131 i\u00e7in Redis kullan\u0131l\u0131yordu), bu da API yan\u0131t s\u00fcrelerini d\u00fc\u015f\u00fcrd\u00fc ve sistemin yatay olarak daha fazla \u00f6l\u00e7eklenmesini sa\u011flad\u0131.<\/li>\n
- Mobil Deste\u011fi:<\/strong> Mobil uygulamalar i\u00e7in do\u011fal ve g\u00fcvenli bir kimlik do\u011frulama mekanizmas\u0131 sa\u011fland\u0131.<\/li>\n
- G\u00fcvenlik:<\/strong> K\u0131sa \u00f6m\u00fcrl\u00fc eri\u015fim tokenlar\u0131 ve iptal edilebilir yenileme tokenlar\u0131 kombinasyonu, ele ge\u00e7irilme riskini y\u00f6netilebilir hale getirdi.<\/li>\n<\/ul>\n
Bu vaka analizi, bir e-ticaret platformunun ba\u015flang\u0131\u00e7taki basit oturum y\u00f6netiminden, b\u00fcy\u00fcyen ihtiya\u00e7lara ve modern mimarilere adapte olmak i\u00e7in nas\u0131l karma\u015f\u0131k ve hibrit bir yap\u0131ya ge\u00e7ti\u011fini g\u00f6stermektedir. Her a\u015famada, performans, \u00f6l\u00e7eklenebilirlik ve g\u00fcvenlik dengesi g\u00f6zetilerek do\u011fru teknolojilerin se\u00e7ilmesi, platformun ba\u015far\u0131s\u0131 i\u00e7in kritik olmu\u015ftur.<\/p>\n
Oturum Y\u00f6netimi Se\u00e7enekleri: Uygulaman\u0131za En Uygun Yakla\u015f\u0131m Hangisi?<\/h2>\n
Bu makale boyunca, web uygulamalar\u0131nda oturum y\u00f6netiminin neden hayati oldu\u011funu, geleneksel \u00e7erez tabanl\u0131 yakla\u015f\u0131mlardan sunucu tarafl\u0131 oturumlara ve modern JWT (JSON Web Tokens) \u00e7\u00f6z\u00fcmlerine kadar farkl\u0131 stratejileri detayl\u0131ca inceledik. Her bir yakla\u015f\u0131m\u0131n kendine \u00f6zg\u00fc avantajlar\u0131 ve dezavantajlar\u0131 bulunmaktad\u0131r ve uygulaman\u0131z\u0131n \u00f6zel gereksinimlerine g\u00f6re en uygun se\u00e7imi yapmak, projenizin ba\u015far\u0131s\u0131 i\u00e7in b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r.<\/p>\n
\u00d6zetle, i\u015fte oturum y\u00f6netimi se\u00e7eneklerinin kar\u015f\u0131la\u015ft\u0131rmal\u0131 bir tablosu:<\/p>\n
\n\n\n\u00d6zellik \/ Y\u00f6ntem<\/th>\n \u00c7erezler (Sadece \u0130stemci)<\/th>\n Sunucu Tarafl\u0131 Oturumlar<\/th>\n JWT (JSON Web Tokens)<\/th>\n<\/tr>\n<\/thead>\n \n\nDepolama Yeri<\/strong><\/td>\n\u0130stemci (taray\u0131c\u0131)<\/td>\n Sunucu (bellek, disk, Redis vb.)<\/td>\n \u0130stemci (token kendi i\u00e7inde bilgi ta\u015f\u0131r)<\/td>\n<\/tr>\n \nDurum<\/strong><\/td>\n\u0130stemci taraf\u0131 durumlu<\/td>\n Sunucu taraf\u0131 durumlu<\/td>\n Durumsuz (server-side stateless)<\/td>\n<\/tr>\n \n\u00d6l\u00e7eklenebilirlik<\/strong><\/td>\nY\u00fcksek (Veri azsa)<\/td>\n Merkezi depolama ile iyi, yap\u0131\u015fkan oturumlarla s\u0131n\u0131rl\u0131<\/td>\n M\u00fckemmel (Do\u011fas\u0131 gere\u011fi yatay olarak \u00f6l\u00e7eklenebilir)<\/td>\n<\/tr>\n \nG\u00fcvenlik<\/strong><\/td>\nXSS, Oturum Ka\u00e7\u0131rma riski y\u00fcksek (HttpOnly<\/code>\/Secure<\/code> olmadan)<\/td>\nY\u00fcksek (Veri sunucuda kal\u0131r), CSRF, Oturum Sabitleme riski var<\/td>\n \u0130mza do\u011frulamas\u0131 ile y\u00fcksek b\u00fct\u00fcnl\u00fck, token \u00e7al\u0131n\u0131rsa riskli (k\u0131sa \u00f6m\u00fcrl\u00fc token\/refresh token kombinasyonu ile y\u00f6netilir)<\/td>\n<\/tr>\n \nKullan\u0131m Alanlar\u0131<\/strong><\/td>\nBasit tercihler, izleme (HttpOnly<\/code> olmadan)<\/td>\nGeleneksel web uygulamalar\u0131, e-ticaret siteleri<\/td>\n API'ler, mikroservisler, mobil uygulamalar, SSO (Tek Oturum A\u00e7ma)<\/td>\n<\/tr>\n \nToken \u0130ptali<\/strong><\/td>\nZor (istemciyi beklemelisin)<\/td>\n Kolay (sunucudan silinebilir)<\/td>\n Zor (kara liste veya refresh token ile \u00e7\u00f6z\u00fcl\u00fcr)<\/td>\n<\/tr>\n \nPerformans<\/strong><\/td>\nD\u00fc\u015f\u00fck sunucu y\u00fck\u00fc<\/td>\n Merkezi depolama sorgusu maliyeti<\/td>\n \u00c7ok d\u00fc\u015f\u00fck sunucu y\u00fck\u00fc (do\u011frulama d\u0131\u015f\u0131)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nUygulaman\u0131z i\u00e7in en iyi yakla\u015f\u0131m\u0131 se\u00e7erken \u015fu sorular\u0131 g\u00f6z \u00f6n\u00fcnde bulundurmal\u0131s\u0131n\u0131z:<\/p>\n
\n- Uygulaman\u0131z\u0131n mimarisi nedir? Geleneksel bir web uygulamas\u0131 m\u0131, yoksa API odakl\u0131 mikroservisler mi kullan\u0131yorsunuz?<\/li>\n
- Hangi platformlar\u0131 destekliyorsunuz? Sadece web taray\u0131c\u0131lar\u0131 m\u0131, yoksa mobil uygulamalar da m\u0131 var?<\/li>\n
- \u00d6l\u00e7eklenebilirlik ihtiya\u00e7lar\u0131n\u0131z ne kadar b\u00fcy\u00fck? Gelecekte ne kadar kullan\u0131c\u0131 bekliyorsunuz?<\/li>\n
- G\u00fcvenlik hassasiyetiniz ne kadar y\u00fcksek? Hangi t\u00fcr verilere eri\u015filiyor ve ne kadar koruma gerekiyor?<\/li>\n
- Geli\u015ftirme ekibinizin tecr\u00fcbesi ve mevcut altyap\u0131n\u0131z hangi teknolojilere daha yatk\u0131n?<\/li>\n<\/ul>\n
Sonu\u00e7 olarak, oturum y\u00f6netimi stratejisi, uygulaman\u0131z\u0131n genel g\u00fcvenlik duru\u015funu ve performans\u0131n\u0131 do\u011frudan etkileyen kritik bir karard\u0131r. Hi\u00e7bir \"tek boyut herkese uyan\" \u00e7\u00f6z\u00fcm yoktur. En iyi yakla\u015f\u0131m genellikle uygulaman\u0131n \u00f6zel gereksinimlerine ve evrimine ba\u011fl\u0131 olarak bu y\u00f6ntemlerin bir kombinasyonunu veya hibrit bir modelini kullanmak olabilir. \u00d6rne\u011fin, ana web sitesi i\u00e7in merkezi sunucu tarafl\u0131 oturumlar kullan\u0131rken, mobil uygulama ve \u00fc\u00e7\u00fcnc\u00fc taraf entegrasyonlar\u0131 i\u00e7in JWT tabanl\u0131 bir API kimlik do\u011frulama mekanizmas\u0131 kurmak mant\u0131kl\u0131 bir hibrit yakla\u015f\u0131m olabilir. Gelecekte WebAuthn gibi parola gerektirmeyen kimlik do\u011frulama standartlar\u0131 ve daha geli\u015fmi\u015f biyometrik sistemler, oturum y\u00f6netiminin dinamiklerini daha da de\u011fi\u015ftirecektir, ancak temel prensipler her zaman ge\u00e7erlili\u011fini koruyacakt\u0131r.<\/p>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n\n- \n
JWT'ler neden localStorage'da saklanmamal\u0131d\u0131r?<\/h4>\n
JWT'ler localStorage<\/code>'da sakland\u0131\u011f\u0131nda, XSS (Cross-Site Scripting) sald\u0131r\u0131lar\u0131na kar\u015f\u0131 savunmas\u0131z hale gelirler. K\u00f6t\u00fc niyetli bir JavaScript kodu, localStorage<\/code>'a eri\u015ferek JWT'yi \u00e7alabilir ve sald\u0131rgan\u0131n kullan\u0131c\u0131n\u0131n kimli\u011fine b\u00fcr\u00fcnmesine olanak tan\u0131r. Daha g\u00fcvenli bir alternatif, token'lar\u0131 HttpOnly<\/code> ve Secure<\/code> bayraklar\u0131yla i\u015faretlenmi\u015f \u00e7erezlerde saklamakt\u0131r, bu da JavaScript eri\u015fimini engeller. Ancak bu durumda da CSRF korumas\u0131 gereklidir.<\/p>\n<\/li>\n- \n
Refresh token mekanizmas\u0131 JWT g\u00fcvenli\u011fini nas\u0131l art\u0131r\u0131r?<\/h4>\n
Refresh token mekanizmas\u0131, k\u0131sa \u00f6m\u00fcrl\u00fc eri\u015fim tokenlar\u0131 ve daha uzun \u00f6m\u00fcrl\u00fc yenileme tokenlar\u0131 kullanarak JWT g\u00fcvenli\u011fini art\u0131r\u0131r. Eri\u015fim tokenlar\u0131 k\u0131sa s\u00fcrede (\u00f6rne\u011fin 15-30 dk) ge\u00e7erlili\u011fini yitirdi\u011fi i\u00e7in, ele ge\u00e7irseler bile k\u00f6t\u00fcye kullan\u0131m s\u00fcresi k\u0131s\u0131tl\u0131d\u0131r. Yenileme tokenlar\u0131 ise daha g\u00fcvenli bir \u015fekilde (\u00f6rn. HttpOnly<\/code> \u00e7erezde veya mobil cihaz\u0131n g\u00fcvenli deposunda) saklan\u0131r ve sadece yeni bir eri\u015fim token\u0131 almak i\u00e7in kullan\u0131l\u0131r. Yenileme tokenlar\u0131 sunucu taraf\u0131nda y\u00f6netildi\u011fi i\u00e7in, \u015f\u00fcpheli durumlarda kolayca iptal edilebilir, bu da \"token iptali\" sorununa \u00e7\u00f6z\u00fcm sunar.<\/p>\n<\/li>\n- \n
CSRF sald\u0131r\u0131lar\u0131 \u00e7erez tabanl\u0131 oturumlar\u0131 nas\u0131l etkiler?<\/h4>\n
CSRF (Cross-Site Request Forgery) sald\u0131r\u0131lar\u0131, kullan\u0131c\u0131n\u0131n taray\u0131c\u0131s\u0131n\u0131n otomatik olarak ilgili alan ad\u0131na ait \u00e7erezleri (oturum kimli\u011fini i\u00e7erenler dahil) g\u00f6ndermesi prensibini s\u00f6m\u00fcr\u00fcr. Sald\u0131rgan, kullan\u0131c\u0131n\u0131n oturum a\u00e7m\u0131\u015f oldu\u011fu bir web sitesine y\u00f6nelik k\u00f6t\u00fc niyetli bir istek olu\u015fturur ve bu iste\u011fi kullan\u0131c\u0131ya g\u00f6ndermesini sa\u011flar (\u00f6rne\u011fin bir resim etiketi veya gizli bir form arac\u0131l\u0131\u011f\u0131yla). Taray\u0131c\u0131, iste\u011fi g\u00f6nderirken ilgili \u00e7erezleri de ekledi\u011fi i\u00e7in, sunucu iste\u011fin me\u015fru bir kullan\u0131c\u0131dan geldi\u011fini d\u00fc\u015f\u00fcn\u00fcr ve i\u015flemi ger\u00e7ekle\u015ftirir. Bu nedenle CSRF tokenlar\u0131 veya