Kullanıcı girişi yalnızca şifre kontrolü değildir. Bu rehberde oturum modeli, JWT tercihi ve rol-izin matrisiyle yazılım kimlik doğrulama yetkilendirme kararlarını iş dilinde ele alıyoruz. Kim neyi görebilir sorusunu netleştirerek tasarımı daha öngörülebilir hale getirirsiniz.
Yazılım kimlik doğrulama yetkilendirme tasarımı, “kullanıcı giriş yapabiliyor mu?” sorusundan daha geniş bir çerçevedir. Asıl iş sorusu şudur: sisteme giren kişi hangi kayıtları görebilir, hangi işlemleri başlatabilir ve bu sınırlar sonradan nasıl yönetilir? Oturum modeli, JWT ve rol-izin matrisi bu soruya verilen teknik cevaplardır; doğru seçim ise iş kurallarının netliğine bağlıdır.
Bu rehber güvenlik kontrol listesi değildir. Amaç; oturumun nerede tutulacağı, token’ın ne taşıyacağı ve “kim neyi görebilir” kararlarının projenin başında nasıl yazılacağını sade bir dille ortaya koymaktır. KepezWeb olarak özel yazılım projelerinde bu kararların erken netleşmesinin, sonradan ekran ve API revizyonunu azalttığını sık görürüz.
Kimlik doğrulama ile yetkilendirme neden ayrı düşünülür?
Kimlik doğrulama (authentication), kişinin iddia ettiği kimlik olduğunu doğrular. Yetkilendirme (authorization) ise o kişinin hangi kaynaklara ve eylemlere erişebileceğini belirler. İkisini aynı adımda çözmeye çalışmak, ileride “giriş yapan herkes her şeyi görüyor” tipinde riskli varsayımlara yol açar.
İş dilinde ayırım şöyledir:
- Giriş: E-posta ve şifre doğru mu, çok faktörlü doğrulama gerekli mi?
- Oturum: Kullanıcı bu istekte hâlâ geçerli bir kimlikle mi konuşuyor?
- Yetki: Bu kullanıcı siparişi iptal edebilir mi, sadece kendi şubesini mi görebilir?
Bu üç katmanı ayrı tasarladığınızda hem hata ayıklama kolaylaşır hem de yeni roller eklemek daha az maliyetli olur. Özellikle birden fazla birim, bayi veya müşteri hesabı olan sistemlerde yetki modeli erken planlanmalıdır.
Oturum modeli: sunucu tarafı oturum nasıl çalışır?
Klasik oturum modelinde sunucu, giriş sonrası bir oturum kimliği üretir ve bunu genelde güvenli bir çerezle tarayıcıya verir. Asıl durum bilgisi sunucuda (bellek, veritabanı veya oturum deposu) tutulur. Her istekte sunucu oturum kimliğini okur ve kullanıcının hâlâ geçerli olup olmadığını kontrol eder.
Bu model özellikle şu senaryolarda anlaşılırdır:
- Tek bir web uygulaması ve tarayıcı odaklı kullanım
- Oturumu anında sonlandırma ihtiyacı (örneğin “tüm cihazlardan çıkış”)
- Yetki değişikliğinin hemen yansıması (rol güncellendiğinde eski erişimin kesilmesi)
İş açısından avantajı, kontrolün merkezde kalmasıdır. Dezavantajı ise oturum deposunun ölçeklenmesi ve birden fazla sunucu arasında tutarlı tutulmasıdır. Mobil uygulama, üçüncü taraf API veya çoklu servis mimarisine geçildiğinde oturum tasarımı yeniden gözden geçirilmelidir.
Oturum tasarımında netleştirilecek kararlar
- Oturum ne kadar süre aktif kalacak, hareketsizlik sonrası ne olacak?
- Aynı hesap birden fazla cihazdan eşzamanlı giriş yapabilecek mi?
- Yönetici bir kullanıcı oturumunu uzaktan sonlandırabilecek mi?
- Hassas işlemlerde (şifre değişimi, ödeme) yeniden doğrulama istenecek mi?
Bu sorular teknik detay gibi görünse de aslında operasyon politikasıdır. Cevapları ürün ve iş birimleriyle birlikte yazmak gerekir.
JWT ile kimlik doğrulama: ne zaman tercih edilir?
JWT (JSON Web Token), kimlik bilgisinin imzalı bir token içinde taşınmasına dayanan bir yaklaşımdır. Kullanıcı giriş yaptıktan sonra sunucu bir token üretir; istemci sonraki isteklerde bu token’ı gönderir. Sunucu token’ın imzasını ve süresini doğrular.
JWT’nin sık tercih edildiği durumlar:
- Mobil uygulama ve web arayüzünün aynı API’yi kullanması
- Birden fazla servisin aynı kimlik bilgisini doğrulaması
- Sunucunun her istekte merkezi oturum deposuna bakmak istememesi
Ancak JWT “her projede modern çözüm” değildir. Token içeriğine ne koyduğunuz, ne kadar süre geçerli olacağı ve iptal ihtiyacı iş riskini belirler. Token içinde rol listesi taşımak kolay görünür; fakat kullanıcı rolü değiştiğinde eski token süresi dolana kadar eski yetkiyle dolaşabilir. Bu yüzden kısa ömürlü erişim token’ı ve ayrı yenileme stratejisi gibi tasarım kararları peşinen konuşulmalıdır.
JWT’de iş dilinde sorulması gerekenler
- Token ne kadar süre geçerli olacak? Süresi bitince kullanıcı deneyimi bozulacak mı?
- Yetki iptali acil mi (örneğin işten çıkan personel), yoksa kısa gecikme kabul edilebilir mi?
- Token içinde hangi kimlik alanları taşınacak; kişisel veri aşırıya kaçıyor mu?
- API’ler arasında aynı token mı kullanılacak, yoksa servis bazlı sınırlar mı olacak?
Bu sorulara cevap vermeden “JWT kuralım” demek, sonradan çıkış, iptal ve yetki senkron sorunlarını projeye taşır.
Oturum mu JWT mi? Karar çerçevesi
Seçim moda teknolojiye göre değil, erişim senaryosuna göre yapılmalıdır. Aşağıdaki tablo, karar toplantılarında ortak dil kurmak için sade bir özet sunar.
| Karar ölçütü | Sunucu oturumu | JWT odaklı model |
|---|---|---|
| Kontrol ve anında iptal | Genelde daha kolay | Ek iptal/yenileme tasarımı ister |
| Tarayıcı odaklı tek uygulama | Doğal uyum | Gereksiz karmaşa riski |
| Mobil + web + API | Ek katman gerekebilir | Sık tercih edilen yol |
| Yetki değişikliğinin yansıması | Merkezi kontrol avantajı | Token ömrü ve yenileme politikasına bağlı |
| Operasyonel sadelik | Küçük ve orta ölçekte sade | Dağıtık mimaride avantajlı olabilir |
Pratikte birçok sistem hibrit ilerler: tarayıcı oturumu ile kullanıcı deneyimini yönetir, API erişiminde kısa ömürlü token kullanır. Önemli olan isimlendirme değil; “giriş durumu nerede tutuluyor, yetki nereden okunuyor, iptal nasıl oluyor” sorularının yazılı olmasıdır.
Rol ve izin matrisi: kim neyi görebilir?
Yazılım kimlik doğrulama yetkilendirme işinin en görünür kısmı rol tasarımıdır. Rol, kullanıcıya verilen iş unvanı gibidir; izin ise o rolün yapabildiği somut eylemlerdir. “Admin her şeyi yapar” cümlesi başlangıçta hızlıdır ama büyüyen ürünlerde denetimi zorlaştırır.
İşe yarayan yaklaşım, önce iş eylemlerini listelemektir:
- Sipariş görüntüleme
- Sipariş iptal etme
- Fiyat güncelleme
- Kullanıcı davet etme
- Rapor indirme
- Ödeme ayarlarını değiştirme
Sonra her eylem için “kim” sorusunu cevaplayın. Örnek bir matris şöyle kurulur:
| Eylem | Satış temsilcisi | Satış yöneticisi | Muhasebe | Sistem yöneticisi |
|---|---|---|---|---|
| Kendi müşterilerini görme | Evet | Evet | Hayır | Evet |
| Tüm şube siparişlerini görme | Hayır | Evet | Kısmi | Evet |
| İndirim tanımlama | Hayır | Evet | Hayır | Evet |
| Fatura dışa aktarma | Hayır | Hayır | Evet | Evet |
| Rol atama | Hayır | Hayır | Hayır | Evet |
Matris yalnızca “evet/hayır”dan ibaret kalmamalıdır. Çoğu gerçek sistemde kapsam da vardır: kendi kaydı, kendi ekibi, kendi şubesi, tüm şirket. “Sipariş görebilir” demek yetmez; “hangi siparişleri?” sorusu yetkilendirmenin özüdür.
Rol sayısını şişirmeden ilerlemek
Her küçük fark için yeni rol açmak, yönetimi zorlaştırır. Daha sağlıklı model genellikle şöyledir:
- Az sayıda temel rol tanımlayın (örneğin temsilci, yönetici, muhasebe, admin).
- İzinleri rollerden ayırın; role izin paketleri bağlayın.
- İstisnaları “özel kullanıcı yetkisi” ile geçici olarak yönetin, kalıcı istisnayı yeni role dönüştürmeden önce iş gerekçesini yazın.
- Hassas izinleri ayrı denetleyin: silme, dışa aktarma, ödeme ve kullanıcı yönetimi gibi.
Bu yapı, ekran bazlı yetkilendirmeden daha dayanıklıdır. Ekran değişebilir; iş eylemi daha uzun yaşar. API tarafında da aynı izin adlarını kullanmak, arayüz ile sunucu arasında tutarsızlığı azaltır.
Yazılım kimlik doğrulama yetkilendirme kararlarını proje planına bağlamak
Kimlik ve yetki modeli, arayüz çizildikten sonra “eklenecek bir özellik” değildir. Hangi menünün görüneceği, hangi listenin filtreleneceği ve hangi butonun pasif kalacağı bu modele bağlıdır. Bu nedenle kararlar yazılım yol haritası içinde erken bir iş paketi olarak yer almalıdır.
Uygulanabilir bir sıra:
- Aktörleri yazın: iç kullanıcı, müşteri, bayi, denetçi gibi.
- Kritik varlıkları listeleyin: sipariş, fatura, stok, kullanıcı, rapor.
- Eylemleri çıkarın: görüntüle, oluştur, güncelle, sil, onayla, dışa aktar.
- Kapsamı netleştirin: kendi kaydı / ekip / şube / tüm organizasyon.
- Oturum veya token modelini seçin: iptal, süre ve çoklu cihaz kurallarını yazın.
- Denetim ihtiyacını belirleyin: kim hangi hassas işlemi ne zaman yaptı?
Bu adımlar, teklif ve kapsam görüşmelerinde de işe yarar. Yazılım proje teklifi değerlendirme sürecinde “giriş ekranı var” ifadesi yetmez; rol matrisi, oturum politikası ve yetki kapsamı yazılı değilse kapsam kayması riski artar.
KepezWeb tarafında yazılım geliştirme projelerinde bu konuyu genelde gereksinim netleştirme aşamasında ele alırız. Amaç, geliştirme hızını düşürmek değil; “sonradan her ekrana yetki ekleme” yükünü baştan azaltmaktır. Belirsiz kalan noktalar için küçük bir proof of concept ile oturum sonlandırma veya rol değişiminin yansıma davranışını denemek de mümkündür.
Sık yapılan tasarım hataları
Aşağıdaki hatalar teknik ekipten çok, iş-kuralı belirsizliğinden doğar:
- Tek “admin” rolüne yığılma: günlük operasyon da yönetici hesabından yürür; hata ve kötüye kullanım riski büyür.
- Sadece arayüzde gizleme: buton gizlenir ama API aynı işlemi herkese açık bırakır.
- Rol adıyla yetki karıştırmak: “müdür” rolü her şirkette aynı anlama gelmez; izinler yazılmalıdır.
- Kapsamı unutmak: kullanıcı “sipariş görebilir” denir, ama tüm şirket siparişlerini görür.
- İptal senaryosunu ertelemek: işten ayrılan kullanıcının erişiminin ne kadar sürede kesileceği tanımsız kalır.
- Log’suz hassas işlem: kim fiyatı değiştirdi veya raporu indirdi bilinmez.
Bu maddeleri proje başında kontrol listesine almak, güvenlik ürünü satın almak kadar pratik bir risk azaltma adımıdır. Model sade tutuldukça denetim de kolaylaşır.
Uygulamaya geçerken kısa kontrol listesi
Tasarımı kodlamadan önce şu soruların yazılı cevabı olsun:
- Giriş yöntemleri neler? (şifre, davet linki, kurumsal kimlik sağlayıcı vb.)
- Oturum veya token nerede sonlanır; kullanıcı bunu kendi hesabından yönetebilir mi?
- Rol değişince yeni yetki ne zaman geçerli olur?
- Veri erişimi kayıt sahibi mi, organizasyon birimi mi, yoksa özel kural mı?
- Hangi işlemler ek doğrulama ister?
- Hangi olaylar denetim kaydına düşer?
Cevaplar netleştikçe geliştirme ekibi ekran ve API’yi aynı dilde kurar. Test senaryoları da “başarılı giriş”ten öteye geçer: yetkisiz erişim denemesi, kapsam dışı kayıt, süresi dolmuş oturum ve rol düşürme gibi durumlar test planına girer.
Sıkça Sorulan Sorular
Oturum ve JWT aynı şey midir?
Hayır. Oturum genelde sunucuda tutulan bir giriş durumudur; JWT ise imzalı bir kimlik taşıyıcısıdır. İkisi de “kullanıcı kim?” sorusuna hizmet eder ama durumun nerede tutulduğu ve iptalin nasıl yapıldığı farklıdır.
Rol ile izin arasındaki fark nedir?
Rol, kullanıcıya atanan iş paketidir. İzin ise o paketin içindeki somut eylem hakkıdır. Rol sayısı az, izin tanımları net tutulduğunda yönetim daha kolaydır.
Her yazılımda JWT kullanmak gerekir mi?
Gerekmez. Tek bir web uygulaması ve güçlü merkezi kontrol ihtiyacı varsa sunucu oturumu yeterli ve daha sade olabilir. Mobil, çoklu istemci veya dağıtık API senaryolarında JWT daha sık gündeme gelir.
Yetkilendirme ne zaman tasarlanmalıdır?
İdeal zaman, ilk ekran ve veri modeli konuşulurkendir. Rol matrisi sonraya bırakılırsa menüler, listeler ve raporlar yeniden yazılabilir. Yol haritasında erken bir iş paketi olarak yer vermek gerekir.
“Kendi kaydını görme” kuralı nasıl yazılmalı?
Yalnızca “görüntüleme var” demek yetmez. Kayıt sahibi mi, ekip üyesi mi, şube mi, yoksa atanmış müşteri portföyü mü sorusunu açık yazın. Bu kapsam kuralı hem arayüz filtrelerine hem API kontrollerine aynı şekilde yansıtılmalıdır.
Kimlik doğrulama ve yetki modeli, ürünün güveninden çok operasyonun düzenini de belirler. Oturum veya JWT tercihi ile rol-izin matrisini iş kurallarına bağladığınızda, “kim neyi görebilir” sorusu tartışmalı bir sonradan ekleme olmaktan çıkar. Özel yazılımınızda bu kararları netleştirmek ve uygulanabilir bir yetki modeli kurmak istiyorsanız KepezWeb teklif al sayfasından ihtiyacınızı iletebilirsiniz; kapsamı birlikte sadeleştiririz.
