Yetkilendirme (Authorization) Nedir?

Kimlik doğrulamadan farkı

İki kavram çoğu zaman aynı giriş ekranının arkasında yaşadığı için karıştırılır, ama farklı soruları yanıtlar ve sırayla çalışır. Önce kimlik doğrulama isteği yapanın kim olduğunu belirler; ardından yetkilendirme o kimliğin istenen işlemi yapıp yapamayacağına karar verir. Bankada kimlik kartınızı göstermek kimlik doğrulamadır; gişeden yalnızca kendi hesabınızdan para çekebilmeniz ise yetkilendirmedir.

HTTP'de bu ayrım iki farklı durum koduyla ifade edilir:

Adındaki "Unauthorized" ifadesine rağmen 401 aslında kimlik doğrulama eksikliğini anlatır ve yanıtla birlikte bir WWW-Authenticate başlığı gönderilir; yetki eksikliğinin karşılığı 403'tür (RFC 9110). Bazı API'ler, varlığı bile gizlenmesi gereken kaynaklarda bilinçli olarak 403 yerine 404 döndürür.

Yaygın erişim modelleri

• RBAC (Role-Based Access Control): İzinler rollere (yönetici, editör, okuyucu), roller de kullanıcılara atanır. Anlaşılması ve denetlenmesi kolaydır; çoğu iş uygulaması için iyi bir başlangıçtır. Her istisna için yeni rol açıldığında ise "rol patlaması" yaşanır ve yönetim zorlaşır.
• ABAC (Attribute-Based Access Control): Karar; kullanıcının, kaynağın ve ortamın niteliklerine (departman, belgenin gizlilik seviyesi, saat, ağ) bakılarak verilir. Daha esnektir, ama kuralların doğru çalıştığını test etmek daha fazla emek ister.
• ReBAC (Relationship-Based Access Control): Erişim, nesneler arasındaki ilişkiden doğar: "Klasörün sahibi, içindeki belgeleri düzenleyebilir." Paylaşım özelliği olan ürünlerde doğal bir modeldir.
• ACL (Access Control List): Her kaynak için kimin neye erişebileceği tek tek listelenir; dosya sistemlerinden tanıdık bir yaklaşımdır.

Uygulamalar arasında yetki devri ise ayrı bir konudur: OAuth, bir uygulamaya kullanıcının parolasını vermeden, sınırlı kapsamlarla (scope) erişim izni tanımlamanın standart yoludur.

Kodda iki ayrı kontrol

Aşağıdaki Express.js örneğinde hem işlev düzeyinde izin kontrolü hem de nesne düzeyinde sahiplik kontrolü yapılıyor:

function izinGerekli(izin) {
  return (req, res, next) => {
    if (!req.user) return res.status(401).end();                       // kimlik yok
    if (!req.user.izinler.includes(izin)) return res.status(403).end(); // izin yok
    next();
  };
}

app.delete("/api/faturalar/:id", izinGerekli("fatura:sil"), async (req, res) => {
  const fatura = await faturaBul(req.params.id);
  // Nesne düzeyi: fatura bu kullanıcının şirketine mi ait?
  if (!fatura || fatura.sirketId !== req.user.sirketId) return res.status(404).end();
  await faturaSil(fatura.id);
  res.status(204).end();
});

İkinci kontrol sıkça unutulur. Kullanıcının "fatura silme" izni olması, başka bir şirketin faturasını silebileceği anlamına gelmez. URL'deki kimliği değiştirerek başkasının verisine ulaşılabilen bu açık IDOR ya da BOLA (Broken Object Level Authorization) olarak bilinir ve API güvenliğinde en sık karşılaşılan sorunlardandır.

İyi uygulamalar

• Kararı sunucuda verin. Bir butonu arayüzde gizlemek yetkilendirme değildir; aynı istek doğrudan API'ye gönderilebilir.
• Varsayılan olarak reddedin. Açıkça izin verilmemiş her işlem kapalı olmalıdır.
• En az yetki ilkesine uyun. Kullanıcılara ve servis hesaplarına yalnızca işlerini görmeye yetecek izinleri verin.
• Kuralları tek yerde toplayın. İzin mantığı her uç noktaya dağıldığında tutarsızlık kaçınılmazdır; merkezi bir politika katmanı ya da ortak yardımcı fonksiyonlar kullanın.
• Token içindeki rolün ömrünü hesaba katın. JWT içine yazılan bir rol, token geçerli olduğu sürece kullanılabilir; rolü geri alınan kullanıcının erişimi token süresi dolana kadar devam edebilir.