Authentication ve authorization: Kimlik doğrulama ile yetkilendirme arasındaki fark

Güvenlik ve kimlik bloğuna, çoğu geliştiricinin farkında olmadan karıştırdığı iki kelimeyi ayırarak başlıyoruz: authentication ve authorization. İkisi de "auth" ile başlıyor, ikisi de güvenlikle ilgili, ama tamamen farklı iki soruya cevap veriyorlar. Bu ayrımı net oturtmadan JWT'ye, rollere, policy'lere geçmek, temeli sağlam olmayan bir binaya kat çıkmaya benzer. O yüzden bugün yavaş ve dikkatli gidiyoruz.

İki Farklı Soru

Her şeyi tek bir cümleyle özetleyebiliriz. Authentication, "sen kimsin?" sorusunu sorar. Authorization ise "senin buna iznin var mı?" sorusunu. Birincisi kimliğini doğrular, ikincisi o kimliğin neye erişebileceğini belirler. Sıra da her zaman böyledir: önce kim olduğunu anlarız, sonra neye izinli olduğuna bakarız.

Türkçe karşılıkları da bu ayrımı güzel yakalar. Authentication, kimlik doğrulama demek. Authorization ise yetkilendirme. Kimliğini doğrulamak başka şeydir, sana bir yetki vermek başka şey. İkisini karıştırmamak için bu Türkçe karşılıkları aklında tut.

Bir Otel Benzetmesi

En net benzetme bir otel. Otele girdiğinde önce resepsiyona gidersin ve kimliğini gösterirsin. Resepsiyon "evet, sen gerçekten rezervasyon yaptıran kişisin" diye seni tanır. İşte bu authentication: kim olduğunu kanıtladın, sistem seni tanıdı. Karşılığında sana bir oda kartı verilir.

Ama o oda kartı her kapıyı açmaz. Kendi odanın kapısını açar, belki spor salonunu ve havuzu. Ama başkasının odasını, personel bölümünü ya da kasa dairesini açmaz. Kartın hangi kapıları açtığı, senin yetkilerindir. İşte bu authorization: kimliğin belli, ama her yere değil, sadece iznin olan yerlere girebilirsin. Kimliğini doğrulamış olman, her şeye erişebileceğin anlamına gelmez.

Neden Önce Authentication?

Sıralama tesadüf değil, zorunluluk. Bir kişinin neye izni olduğunu söyleyebilmen için, önce o kişinin kim olduğunu bilmen gerekir. Kimliği belli olmayan birine yetki veremezsin; "sen kimsin bilmiyorum ama şuraya girebilirsin" demek anlamsızdır. Bu yüzden authorization her zaman authentication'ın üzerine kurulur. Önce kimlik, sonra yetki.

On üçüncü yazıda middleware sırasının neden önemli olduğunu konuşmuştuk; işte bu kavram tam da orada karşımıza çıkıyor. .NET'te app.UseAuthentication() her zaman app.UseAuthorization()'dan önce gelir. Sırayı ters çevirirsen, yetki kontrolü daha ortada bir kimlik yokken çalışmaya kalkar ve mantık çöker. İkinci yazıdaki "kim doğrulamadan yetki soramazsın" örneği, tam olarak buydu.

.NET'te Bu İkisi Nasıl Görünüyor?

İki kavramın koda nasıl yansıdığına bakalım. Bir action metodunun yetki gerektirdiğini, en basit haliyle bir attribute ile söyleriz:

[HttpGet]
[Authorize]
public IActionResult GetSecret()
{
    return Ok("Bu içeriği sadece kimliği doğrulanmış kullanıcılar görebilir.");
}

Buradaki [Authorize] attribute'u şunu der: "Bu endpoint'e ulaşmak için önce kimliğin doğrulanmış olmalı." Kimliği doğrulanmamış bir istek gelirse, .NET otomatik olarak 401 Unauthorized döner. Bu, "sen kimsin bilmiyorum, önce kimliğini doğrula" demenin standart yoludur. İçeriye hiç girmeden, kapıda çevrilir.

Peki kimliği doğrulanmış ama yeterli yetkisi olmayan biri gelirse? O zaman farklı bir cevap alır: 403 Forbidden. Bu iki durum kodu arasındaki ayrım tam da bugünkü konumuzu özetliyor. 401, "kim olduğunu bilmiyorum" demektir; bir kimlik sorunudur. 403 ise "kim olduğunu biliyorum ama buraya iznin yok" demektir; bir yetki sorunudur. Beşinci yazıda durum kodlarını konuşurken bu ikisine değinmiştik; şimdi neden farklı oldukları çok daha net.

Yetkiyi Daraltmak

[Authorize]'ı tek başına kullanmak "kimliği doğrulanmış herkes girebilir" demektir. Ama çoğu zaman daha ince ayar istersin: "sadece yöneticiler girebilir" gibi. İşte burada authorization'ın asıl gücü devreye girer. Attribute'a bir koşul ekleyerek erişimi daraltabilirsin:

[HttpDelete("{id}")]
[Authorize(Roles = "Admin")]
public IActionResult Delete(int id)
{
    return Ok($"{id} numaralı kayıt silindi.");
}

Bu endpoint artık sadece kimliği doğrulanmış ve "Admin" rolüne sahip kullanıcılara açık. Sıradan bir kullanıcı, kimliği doğru olsa bile buraya erişemez ve 403 alır. Rollerin ve daha esnek olan policy'lerin detayına ilerleyen yazılarda gireceğiz; şimdilik görmen gereken şey, authorization'ın "girer/giremez" ikilisinden çok daha ince ayarlar yapabildiği.

Küçük Bir Deneme

Bu yazıda kod yazmaktan çok kavramı oturtmak istiyorum, o yüzden deneme de düşünsel olsun. Kendi kullandığın bir uygulamayı, mesela bir sosyal medya platformunu ya da bankacılık uygulamasını düşün. Giriş yaptığın an authentication gerçekleşir: sistem seni tanır. Sonra uygulama içinde bazı şeyleri yapabilir, bazılarını yapamazsın; başkasının profilini düzenleyemez, sana ait olmayan hesabın parasını göremezsin. İşte bu kısıtlamalar authorization'dır. Günlük kullandığın uygulamalarda bu iki katmanı zihninde ayırmaya çalış; bu alışkanlık, ikisini kodda kurgularken de sana rehber olur.

Bir sonraki yazıda authentication'ı gerçek anlamda hayata geçireceğiz: JWT (JSON Web Token) ile kimlik doğrulamayı konuşacağız. Bir kullanıcının kimliğini bir kez doğruladıktan sonra, sonraki isteklerde bunu nasıl taşıdığını ve API'nin bu kimliği nasıl güvenle tanıdığını adım adım göreceğiz. Bugün oturttuğun "önce kim, sonra yetki" mantığı, o mekanizmanın tam kalbinde olacak.