Ekşi Duyuru

illa bina ile ilgili ornek vereceksek dogru ornek su olabilir belki;
- otel binasinin girisinde guvenlige kimligini verip gecici bir kart aliyorsun (access token)
- bu kart sadece sana izin verilen kapilari aciyor (scope)
- kartin bir suresi var, karti okuttugunda yetkin var ancak kartin suresi bittiyse otomatik kartini yeniliyor (refresh token)
- kartin suresi bitmeden kartini guvenlik iptal edebilir ya da yetkini kisitlayip genisletebilir ama bunun icin senin guvenlikli kapilarla etkilesime gecmen gerek ya da guvenlik gorevlisinin gelip seni cikarmasi gerekir (session)

cookies kavramını da ayrıca araştırabilirsiniz

siz sadece girişte, login olurken kimlik doğruluyorsunuz. Kimlik doğruladıktan sonra banka'nın bir nevi, iç bankacılık sisteminin bir bölümüne erişmiş oluyorsunuz.

Artık kimliğiniz doğrulandığı ve bir üye numarası, ID(kimlik) aldığınız için size tanımlı rollerin yetkileri doğrultusunda tasarlanmış menüleri görüyorsunuz.

Eğer bu işi protokol bazında HTTP flaglerine kadar irdeleyeceksek, siz her GET veya POST request'ine kimliğinizi doğruladığınızı belirten değişkenler ve header'lar ekliyorsunuz. Bunu sizin adınıza browser'lar ve diğer ağda bulunan cihazlar yapıyor.

Sizin login olduğunuz bilgi, browser'daki session storage + cookie içerisinde tutulabilir. İlla böyle olacak diye bir kavram yok. Bankacılık yazılımına bağlı fakat tek bir sunucu hizmet etmeyeceği ve yüzlerce sunucudan oluşan parkurları varsayarsak cookie'de tutmalı ki session tutarlığını sağlayabilsin.

Bu bilgileri her işlem yaptığınızda gönderiyorsunuz; cookie'de bulunan değer ile sunucu/lb tarafında olan değer eşleşmez ise force logout ediliyor yani oturumunuz kapatılıyor.

Gerçek hayatta da kurumsal bir şirketi düşünün, kartlı giriş sistemi olsun. Size Teknisyen rolü atanmış olsun ve bu Teknisyen rolünün içeride girebileceği oda'lar ve açabileceği kapılar belli olsun. En yakın örnek bu olur lakin, bankacılık sisteminde size tanımlı olmayan ekranları görmezsiniz(istediğiniz odaya gidemezsiniz) dolayısıyla fiziksel bina'da da göremediğiniz ama girilebilen kapı'lar olmalı :)

Çok uzattım, bu bilgiler browser ve sunucu/ağ cihazlarında ayrı ayrı tutulabilir. Güvenlik ve oturum tutarlığı içinde her işlemde kontrol edilir, edilmesi beklenir.

Kontrol edilmeyen sistemler zafiyet içerir (bkz: idor). O da başka bi sorunun konusu olur.

Abi çok basit ve temel bi sistem gibi görünüyor ama zibilyon tane farklı uygulaması var.

- Duyuru gibi eski siteler, login olduğunda sana bi "session id" tanımlıyor. Bunu da hem veritabanına (xephyr -> "XYZ5356" gibi) kaydediyor, hem de sana (browser'a yani) geri gönderiyor. Bu bilgi cookie olarak kaydediliyor, senin her isteğinde bu bilgi tekrar sunucuya gönderiliyor. Sunucu gelen istekten bu bilgiyi alıp bakıyor veritabanına, "XYZ5356" xephyr'a aitmiş diyip, hesap bilgilerini getirirken o kullanıcıya ait bilgileri dönüyor.

Niye her seferinde şifreni ileri geri göndermiyor da bi session id oluşturuyor? Çünkü şifreni ileri geri gönderecek olsa senin bilgisayarına kaydetmesi lazım, ama şifreyi bi yere kaydetmek iyi bi fikir değil, çalınır o kesin. O yüzden direkt şifre yerine, random üretilmiş ve belirli bi süresi olan (ve istediğimiz zaman iptal edebileceğimiz) başka bişey kullanmak daha güvenli.

Ama burada ne sıkıntı var?

1- Bilgiyi veritabanına kaydettik. Her istekte veritabanına gidip bakmamız lazım, yavaş bi işlem.

2- Diyelim ki bu bilgiyi bi süre ram'de tutalım dedik. E peki ya 1'den fazla sunucumuya ihtiyacımız olacaksa? Microservices diyorlar buna, senin session id'in 1. sunucuda ram'de, ama istek 2. sunucuya gitti, ram'de bulamadı kaydı. Olmadı bu iş.

3- Redis gibi bi caching mekanizması kullanabiliriz, ama bu da ekstra bi karmaşıklık. Onu kur, maintain et, parasını öde falan bi sürü maliyet. Ayrıca diyelim redis bozuldu, nolacak, kimse giremeyecek mi siteye?

Bu gibi sıkıntılar yüzünden JWT diye bi yöntem geliştirdiler. Burada da kabaca şöyle işliyor sistem:

- Sen yine login oldun, bu sefer sana yine session id benzeri (ama random olmayan) bi "token" oluşturuyor, bunu direkt sana gönderiyor, veritabanında bi kayıt yok. Buna "access token" diyorlar genelde.

- Bu token'ın içinde senin kim olduğun (misal username: xephyr) bilgisi duruyor. Ama bu token'ı herkes oluşturabilir? O yüzden bi de bunu (oluşturduğumuz saati vs. de kullanarak) imzalıyoruz (kriptografik imza), ki bu sayede bu token'ın gerçekten sana ait olduğundan emin olabilelim.

- Ha bu token yine çalınabilir, başkası tarafından kullanılabilir. O yüzden bu "access token" genelde çok kısa ömürlü oluyor (misal 1-2 saat ile 1-2 gün arası) ve herhangi bir yere kaydedilmiyor yine. Tabi bu süre her bittiğinde kullanıcıya "kardeş yeniden şifre gir de token oluşturalım" demek çok iyi bi UX değil, bu yüzden bi de bi "refresh token" oluşturuyoruz, bunu da kullanıcının cihazına bağlıyoruz. Access token'ının süresi bitince otomatik refresh token gönderiliyor, ki onu valide edip sana yeni bi access token üretebilelim hemen.

- Bilgiler bu access token'ın direkt içinde olduğu için veritabanına bakmaya gerek yok. Token'ın imzası geçerliyse, içindeki bilgiler (misal username) doğrudur diyip kullanmaya devam edebiliyoruz.

- Farklı sunucular olabilir, ram'de tutmadığımız için böyle bi derdimiz de yok.

- Ekstra bi caching mekanizmasına da ihtiyacımız yok.

- Kullanıcıyı yasaklamak istersek, access token'ın süresi bitene kadar beklemek zorundayız. Ama refresh token'ının yeni access token'ları üretmesini engelleyebiliriz, bu sayede elindeki token bittikten sonra sisteme erişemezsin. Ama session id'deki gibi anlık banlama şansımız yok, bu da botlara karşı bir zaafiyet yaratıyor tabi ki.

- Burada bi de OAuth denilen bi yöntem var, orada şifre de yok. Misal ekşi ile entegrasyon sağlıyorum, ekşi'de oturumun varsa ben de onu kabul edip duyuruya uygulayabiliyorum. Çok ilkel bi hali şu an burada kullanılıyor bu yöntemin.

- Aslında çok yaygın olan ama web tarafına fazla gelmemiş olan ssh-key based authentication diye bi yöntem var. Kabaca senin iki tane anahtarın var, public olanı kayıt olacağın siteye yüklüyorsun. Private olan bilgisayarında kalıyor. Bi istek yapacağın zaman private olan ile imzalıyorsun, site de public olanla bunu doğruluyor. Böylece mesela tek anahtarla yüzlerce siteye de kayıt olabilirsin.

Ama browser'ların lokal filesystem'a erişimi olmadığı için bu yöntem de pek kullanılmıyordu, fakat metamask vs. gibi eklentilerle (ya da brave browser'da built-in bu özellik) yavaş yavaş bu yöntem de yaygınlaşmaya başladı. Web haricinde 20-30 yıldır kullanılan bi yöntem ama bu.