Kimlik Doğrulama (Authentication) ile Yetkilendirme (Authorization) Arasındaki Fark Nedir?

Bir kullanıcı e-posta ve şifresiyle sisteme giriş yapıyor — bu 'kimlik doğrulama' (authentication). Aynı kullanıcı giriş yaptıktan sonra 'muhasebe modülünü görebilir mi, başka bir şubenin cirosunu değiştirebilir mi' sorusu ise 'yetkilendirme' (authorization). İkisi neredeyse her teknik dokümanda yan yana geçiyor, çoğu geliştirici de kariyerinin ilk yıllarında bu ikisini birbirine karıştırıyor — ve bu karışıklık üretim ortamında ciddi güvenlik açıklarına dönüşüyor. Bu yazıda kimlik doğrulama ile yetkilendirme arasındaki farkı gerçek bir uygulama senaryosu üzerinden, hangi yöntemin ne zaman kullanılacağını ve en sık yapılan hataları anlatıyorum.

##Kimlik doğrulama (authentication) tam olarak ne yapar?

Kimlik doğrulama, sistemin 'sen gerçekten iddia ettiğin kişi misin' sorusuna cevap aradığı adımdır. En basit hali e-posta + şifre kontrolüdür: kullanıcının girdiği şifre, veritabanında saklanan hash ile eşleşiyor mu diye bakılır. Şifre asla düz metin olarak tutulmaz; bcrypt veya argon2 gibi bir algoritmayla, her kullanıcıya özel bir 'salt' eklenerek hashlenir — böylece aynı şifreyi kullanan iki kişinin veritabanındaki kaydı bile birbirine benzemez. Eşleşme başarılıysa sistem bir 'oturum' (session) ya da 'token' (genelde JWT) üretir ve bunu tarayıcıya ya da uygulamaya verir. Bundan sonraki her istekte kullanıcı bu token'ı gönderir, sistem de 'bu token geçerli mi, süresi dolmuş mu' diye kontrol eder. İyi kurulmuş bir authentication katmanı ayrıca art arda başarısız giriş denemelerini de sınırlar (rate limiting) — aksi halde biri saniyede binlerce şifre deneyerek hesabınızı kaba kuvvetle kırmaya çalışabilir. İki faktörlü doğrulama (2FA/MFA), sosyal medya ile giriş (OAuth login) ve tek seferlik SMS/e-posta kodları da hep bu aynı sorunun farklı çözümleridir: kimliği doğrula, sonra bunu bir süre boyunca hatırla.

##Yetkilendirme (authorization) nerede devreye giriyor?

Kimlik doğrulandıktan sonra sistem artık kullanıcının kim olduğunu biliyor — ama bu, her şeyi yapabileceği anlamına gelmiyor. Yetkilendirme, 'bu kimlik, bu kaynağa, bu işlemi yapabilir mi' sorusuna her istekte yeniden cevap arar. Authentication genelde girişte bir kez olur; authorization ise API'ye gelen her tek istekte, hatta bazen aynı istek içinde birden fazla kez kontrol edilir — önce 'bu rol bu ekranı görebilir mi', sonra 'bu kayıt gerçekten bu kullanıcıya mı ait'. Bir e-ticaret panelinde giriş yapmış bir mağaza çalışanı düşünün: kimlik doğrulama 'bu gerçekten Ayşe' der, yetkilendirme ise 'Ayşe sadece kendi mağazasının siparişlerini görebilir, fiyat değiştiremez, başka bir şubenin verisine erişemez' der. Bu ayrımı net kurmayan sistemlerde tipik sonuç şudur: giriş güvenlidir ama girdikten sonra herkes her şeyi görebilir ya da değiştirebilir — kapıda sıkı güvenlik, içeride tam serbestlik.

##Gerçek bir örnek: çok şubeli bir panelde login'den 'bu veriyi görebilir mi'ye

Diyelim ki üç şubesi olan bir perakende zinciri için bir yönetim paneli kuruyoruz. Şube müdürü kendi e-postası ve şifresiyle giriş yapıyor; backend şifreyi doğruluyor ve içine kullanıcı ID'si, rolü ('şube müdürü') ve bağlı olduğu şube ID'si yazılmış bir JWT üretip tarayıcıya veriyor — authentication adımı burada bitiyor. Müdür panelde 'Ciro Raporu' sekmesine tıkladığında tarayıcı bu token'ı API'ye gönderiyor. API önce token'ın geçerliliğini kontrol ediyor (authentication'ın devamı), sonra ayrı bir middleware devreye giriyor: 'bu rol ciro raporunu görüntüleyebilir mi' (rol bazlı kontrol) ve 'bu şube ID'si, istenen şube ID'siyle eşleşiyor mu' (kaynak bazlı/ownership kontrolü). İkinci kontrol atlanırsa — ki bu gerçek projelerde şaşırtıcı derecede sık yapılan bir hata — müdür URL'deki şube ID'sini elle değiştirerek başka bir şubenin cirosunu görebilir hale gelir. Doğru kurulmuş bir sistemde bu iki kontrol her istekte, sunucu tarafında, kullanıcının göremediği bir katmanda çalışır; üstüne bir de 'kim, ne zaman, hangi kaydı görüntüledi/değiştirdi' bilgisini tutan bir audit log eklenirse, bir uyuşmazlık çıktığında geriye dönüp neyin gerçekten olduğunu kanıtlamak da mümkün olur.

##Yaygın yöntemler: hangisi ne zaman kullanılır

Pratikte bu iki katmanı kurmak için birkaç kalıp var, ve doğru seçim projenin büyüklüğüne ve karmaşıklığına göre değişiyor:

• ▸Session tabanlı auth: Sunucu oturumu hafızada/Redis'te tutar, tarayıcıya sadece bir session ID cookie'si verir. Basit, klasik web uygulamaları için hâlâ sağlam bir seçim.
• ▸JWT / token tabanlı auth: Kullanıcı bilgisi token'ın içine gömülür, sunucu durum tutmaz (stateless). Mobil uygulamalar ve mikroservisler arası iletişim için pratik, ama token iptal etmek session'a göre daha zahmetli.
• ▸OAuth2 / sosyal giriş: 'Google ile giriş yap' gibi akışlar — kimlik doğrulamayı büyük bir sağlayıcıya devretmek, şifre yönetimi yükünü kaldırır.
• ▸RBAC (role-based access control): Kullanıcılara admin, editör, görüntüleyici gibi roller atanır, yetkiler role bağlanır. 3-5 net rolü olan çoğu SaaS için en az karmaşık, en sürdürülebilir model.
• ▸ABAC / kaynak bazlı (ownership) kontrol: 'Bu kayıt bu kullanıcıya/şubeye/organizasyona mı ait' gibi daha ince taneli kurallar. Çok kiracılı (multi-tenant) sistemlerde RBAC'a ek olarak neredeyse her zaman gerekir.

##Yetkilendirmeyi test etmek ve zamanla büyütmek

Yetkilendirme mantığı kod tabanına yayıldıkça elle test etmek yetmiyor. İşe yarayan bir yaklaşım, staging ortamında her rol için gerçek bir test hesabı tutmak ve kritik endpoint'leri 'admin olarak dene, sonra görüntüleyici olarak aynısını dene, ikincisi reddedilmeli' şeklinde otomatik testlere bağlamak. Küçük ve orta ölçekli projelerde RBAC + ownership kontrolü genelde uzun süre yeterli kalır; ama ürün büyüyüp 'bu özelliği sadece Pro plandaki organizasyonlar görebilsin', 'bu raporu sadece kendi ekibini yöneten kişiler indirebilsin' gibi çok boyutlu kurallar birikmeye başladığında, bu mantığı her endpoint'e elle dağıtmak yerine merkezi bir politika katmanına (örneğin Open Policy Agent gibi bir 'policy engine') taşımak bakımı çok kolaylaştırır. Erken aşamada buna geçmek gereksiz bir soyutlama olur; ama sinyali (rol sayısının patlaması, aynı kontrolün onlarca yerde tekrarlanması) görünce ertelemenin de bir bedeli var.

##Sık yapılan hatalar

En sık gördüğüm hata, yetkilendirmeyi sadece arayüzde yapmak: buton gizlenir ama API endpoint'i açıkta kalır, biri Postman ile doğrudan isteği atınca kontrolsüz erişim elde eder. İkinci yaygın hata IDOR (Insecure Direct Object Reference) — URL'deki /orders/482 gibi bir ID'yi değiştirerek başkasının kaydına erişebilmek; bunun tek çözümü her kayıt sorgusunda 'bu kayıt gerçekten bu kullanıcıya mı ait' kontrolünü sunucuda yapmaktır. Üçüncüsü, admin/servis hesaplarına gerekenden fazla yetki vermek — bir entegrasyon script'i sadece okuma yapması gerekirken tam yazma yetkisiyle kurulur ve token sızarsa hasar çok daha büyük olur. Dördüncüsü, token süresini hiç kısaltmamak: uzun ömürlü bir token çalınırsa, kısa ömürlü bir token'a göre çok daha uzun süre kötüye kullanılabilir. Beşincisi ise az konuşulan ama pahalıya patlayan bir hata: yetkilendirme reddedilmelerini hiç loglamamak — biri sistematik olarak erişemeyeceği kayıtları denemeye başladığında (klasik bir IDOR taraması), bunu fark edecek hiçbir kayıt olmuyor.

##Sık Sorulan Sorular

>Authentication ve authorization aynı şey mi?

Hayır. Authentication 'kimsin' sorusuna, authorization 'ne yapabilirsin' sorusuna cevap verir. Biri diğerinin önkoşulu ama ikisi de ayrı ayrı, ayrı kod katmanlarında kurulması gereken mekanizmalardır.

>JWT kullanmak yetkilendirmeyi otomatik çözer mi?

Hayır — JWT sadece kimliği ve içine koyduğunuz birkaç claim'i (rol, şube ID gibi) taşıyan imzalı bir kutudur. Token geçerli olması, isteği atan kişinin o kaynağa erişim yetkisi olduğu anlamına gelmez; bu kontrolü her endpoint'te ayrıca yazmanız gerekir.

>Küçük bir SaaS için RBAC mi yoksa daha basit bir model mi yeterli?

Çoğu erken aşama SaaS için 2-3 net rol (örneğin admin/üye/görüntüleyici) artı basit bir ownership kontrolü (bu kayıt bu hesaba mı ait) fazlasıyla yeterli. ABAC gibi ince taneli, kural motoruna dayalı sistemler genelde yüzlerce kullanıcılı, karmaşık kurumsal ürünlerde gerekli hale gelir — erken kurmak gereksiz karmaşıklık ekler.

>Frontend'de butonu/menüyü gizlemek yeterli mi?

Hayır, bu sadece kullanıcı deneyimi içindir. Gerçek güvenlik kontrolü her zaman backend'de, API isteğinin işlendiği katmanda olmalı — çünkü frontend kodu tarayıcıda çalışır ve isteyen herkes onu atlayıp API'ye doğrudan istek atabilir.

>Yetkilendirme hatalarını loglamak neden önemli?

Çünkü tek bir reddedilen istek genelde önemsizdir, ama aynı kullanıcıdan gelen onlarca farklı kayıt ID'sine erişim denemesi bir tarama saldırısının işareti olabilir. Bu logları tutmadan hem bu tür denemeleri fark edemezsiniz hem de bir güvenlik olayında geriye dönük olarak neyin gerçekten yaşandığını kanıtlayamazsınız.

Authentication ve authorization'ı baştan ayrı katmanlar olarak tasarlamak, sonradan 'aslında herkes her şeyi görebiliyormuş' diye panikle yama yapmaktan çok daha ucuza geliyor. Bir SaaS ya da iç panel için bu mimariyi doğru kurmak istersen /contact üzerinden yazabilirsin; performans tarafında benzer bir 'küçük kararın büyük etkisi' örneğini merak ediyorsan veritabanı index'i yazısı da ilgini çekebilir.