JWT Token Kullananlara Sorum Var

Mevzu o değil, authN/authZ işini bir API gateway'e de bırakabilir. Kaç yıldır greenfield ve brownfield projelerde çalışıyorum, ne zaman iş authN/Z'ye el atmaya gelse JWT varsa bu tasarım kararını kim verdiyse arkasından güzel bir sövüyorum. Abi şunu anlamak zor değil, JWT denen nane partiler arası veri paslamıyorsanız (SSO vs sosyal medya login'i durumlarında vs.) Web authentication için kullanılmıyor. Auth0, Okta bile yapmıyor bu saçmalığı, ama ne hikmetse bir JWT manyası var geliştiricilerde. Adamlar 25-30 yıl önce bu sorunu çözmüşler zaten cookie ile.

https://www.google.com/search?q=don%...combinator.com

Middleware, rate limiting kullan. Ama bu ikisi de iṣe yaramıyor. Diyelim ki, api adresine saldırganlar dakikada milyonlarca istek atıyor. (çoğu hatalı istek) ama bu hatalı istekler; sunucunu ṣiṣirir.

En profesyonel çözüm; cloudflare ve docker kubernetes ile güvenlik duvarı kurmaktır. Baṣkasından gelen saldırgan request isteklerini engellersin.

Bu sorun JWT'a özel bir şey değil, cookie'lerle session oluşturduğunda da aynı olası problemi adreslemen gerekiyor zaten. Bunu bazı uygulamalar IP tabanlı validasyonla proaktif şekilde önlemeye çalışıyor, diğerleri de kullanıcı istemediği takdirde (beni hatırla vs.) oturum süresini olabildiğince kısa tutmaya çalışıyor. Cookie'lerde tarayıcı kapanınca ilgili cookie'yi silme mevzusu da var, o da bir seçenek olabiliyor. Diğer türlü o oturumun korunmasında kullanıcının da eşit sorumluluğu var. Makinene trojan girip bütün tarayıcı verini çalarsa ne yapabilirsin ki? Ek olarak, JWT kullanıyorsan sitende XSS açığı oluşursa bütün tokenleri yürütürler haberin olsun. O yüzden CSP ayarlarını da iyi yap. Bunu mesela cookie kullanıyorsan eğer HttpOnly deyip çözebiliyorsun, düşünmene gerek kalmıyor.

Sana tavsiyem first party auth yapıyorsan, cookie ve opak tokenlerden faydalan. JWT'ın sana bir faydası yok işleri karıştırmaktan başka.

https://zitadel.com/blog/jwt-vs-opaque-tokens

aslında aklımda bir proje yokken jwt token mantığını oturtmak adına bir backend yazdım hadi bunu yazmışken birde react native ile bir mobil app yazayım login sistemi nasıl olsa hazır mobile hakkında bilgi sahibi olayım dedim işin içine girip düşündükçe karmaşık bir hal aldı Genelce cookie de tutmuyorum localde tutuyorum fakat ip ile kontrol edip geçmesi en iyisi sanırım bu kadar takılmaya gerek yok gibi geri kalan güvenliği kullanıcı kendi sağlasın

Mevzu o değil, authN/authZ işini bir API gateway'e de bırakabilir. Kaç yıldır greenfield ve brownfield projelerde çalışıyorum, ne zaman iş authN/Z'ye el atmaya gelse JWT varsa bu tasarım kararını kim verdiyse arkasından güzel bir sövüyorum. Abi şunu anlamak zor değil, JWT denen nane partiler arası veri paslamıyorsanız (SSO vs sosyal medya login'i durumlarında vs.) Web authentication için kullanılmıyor. Auth0, Okta bile yapmıyor bu saçmalığı, ama ne hikmetse bir JWT manyası var geliştiricilerde. Adamlar 25-30 yıl önce bu sorunu çözmüşler zaten cookie ile.

https://www.google.com/search?q=don%...combinator.com

Middleware, rate limiting kullan. Ama bu ikisi de iṣe yaramıyor. Diyelim ki, api adresine saldırganlar dakikada milyonlarca istek atıyor. (çoğu hatalı istek) ama bu hatalı istekler; sunucunu ṣiṣirir.

En profesyonel çözüm; cloudflare ve docker kubernetes ile güvenlik duvarı kurmaktır. Baṣkasından gelen saldırgan request isteklerini engellersin.

Ciddi projelerde genelde BFF'den faydalanılır bu durumda. Birden fazla frontend varsa ona göre ayrı backend katmanı çekilir. Mesela sende hem Web, hem mobil var. Hepsinin ihtiyaçları farklı olur. Mesela Web'de server rendered içerik sunabilirsin, mobilde böyle bir şey olmadığı için ya API ya da GQL vs. kullanırsın. Best practice şöyle:

Ayrı bir api projesi oluşturdum gerekli sorguları api ve repositoryleri burada yazıyorum front end olarak mobil başladım ama ileride web içinde aynı apiyi kullanabilirim