OAuth, Authentication ve Authorization Arasındaki Fark?

Authentication ve Authorization, yazılım güvenliğinin en temel iki kavramıdır. İsimleri birbirine benzediği için sık sık karıştırılsalar da tamamen farklı sorulara cevap verirler.

Authentication kullanıcının kim olduğunu doğrular. Authorization ise doğrulanan kullanıcının sistem içerisinde hangi kaynaklara erişebileceğini ve hangi işlemleri yapabileceğini belirler.

En basit ifadeyle Authentication "Sen kimsin?", Authorization ise "Ne yapmaya yetkin var?" sorusunun cevabıdır. Güvenli bir uygulamada bu iki mekanizmanın birlikte ve doğru şekilde uygulanması gerekir.

Authentication Nedir?

Authentication, Türkçede kimlik doğrulama anlamına gelir. Sisteme erişmeye çalışan kişinin veya servisin iddia ettiği kimliğe gerçekten sahip olup olmadığının doğrulanması işlemidir.

Bir web sitesine e-posta adresiniz ve şifrenizle giriş yaptığınızda gerçekleştirilen işlem Authentication'dır. Sistem kullanıcı bilgilerini kontrol eder ve bilgiler geçerliyse kullanıcının kimliğini doğrular.

• Kullanıcı adı ve şifre ile giriş.
• E-posta ve şifre ile giriş.
• Tek kullanımlık doğrulama kodları.
• Authenticator uygulamaları.
• Biyometrik doğrulama.
• Passkey kullanımı.
• OAuth veya OpenID Connect tabanlı giriş sistemleri.

Bunların tamamı farklı yöntemler kullansa da temel amaç aynıdır: kullanıcının kimliğini doğrulamak.

Authorization Nedir?

Authorization, Türkçede yetkilendirme anlamına gelir. Kullanıcının kimliği doğrulandıktan sonra hangi işlemleri gerçekleştirmesine izin verileceğini belirler.

Örneğin bir e-ticaret sisteminde hem müşteri hem de yönetici başarıyla giriş yapmış olabilir. İkisinin de Authentication işlemi tamamlanmıştır. Ancak müşterinin ürün fiyatlarını değiştirmesine veya başka müşterilerin siparişlerini yönetmesine izin verilmemelidir.

Bu ayrımı sağlayan mekanizma Authorization'dır.

Authentication ve Authorization Arasındaki Temel Fark

• Authentication: Kullanıcı kim?
• Authorization: Kullanıcı ne yapabilir?
• Authentication genellikle önce gerçekleşir.
• Authorization kimliği doğrulanmış kullanıcının erişim haklarını kontrol eder.
• Authentication kimlik bilgileriyle ilgilenir.
• Authorization rol, izin, sahiplik ve erişim politikalarıyla ilgilenir.

Basit Bir Örnekle Authentication ve Authorization

Bir şirket binasına giriş yaptığınızı düşünelim. Güvenlik görevlisine kartınızı gösterdiğinizde kartın size ait olup olmadığının kontrol edilmesi Authentication işlemine benzer.

Binaya girdikten sonra kartınızın hangi odaların kapısını açabileceği ise Authorization'dır.

Kimliğiniz doğrulanmış olabilir ancak bu durum binadaki bütün odalara erişme hakkınız olduğu anlamına gelmez. Yazılım sistemlerinde de aynı prensip geçerlidir.

En Büyük Hatalardan Biri: "Giriş Yaptıysa Erişebilir"

Web uygulamalarındaki ciddi güvenlik problemlerinden biri Authentication işleminin Authorization için yeterli kabul edilmesidir.

Bir endpoint yalnızca giriş yapmış kullanıcılara açık olabilir. Ancak endpoint üzerinde kaynak sahipliği kontrol edilmiyorsa kullanıcı başka kullanıcılara ait verilere erişebilir.

Route::middleware('auth')->get('/orders/{id}', function ($id) {
return Order::findOrFail($id);
});

İlk bakışta endpoint güvenli görünebilir çünkü auth middleware kullanılmaktadır. Ancak burada yalnızca kullanıcının giriş yapıp yapmadığı kontrol edilmektedir.

Kullanıcı kendi siparişini görüntülerken URL içerisindeki ID değerini değiştirirse başka bir kullanıcının siparişine ulaşma ihtimali doğabilir.

/orders/1001
/orders/1002
/orders/1003

Sistemin yalnızca "Bu kullanıcı giriş yaptı mı?" sorusunu sorması yeterli değildir. Aynı zamanda "Bu sipariş gerçekten bu kullanıcıya mı ait?" sorusunu da kontrol etmesi gerekir.

Kaynak Sahipliği Kontrolü

Kullanıcının yalnızca kendisine ait verilere erişmesi gereken sistemlerde kaynak sahipliği Authorization mekanizmasının önemli bir parçasıdır.

$order = Order::where('id', $id)
->where('user_id', auth()->id())
->firstOrFail();

return response()->json($order);

Bu örnekte yalnızca sipariş ID'si kontrol edilmez. Siparişin mevcut kullanıcıya ait olup olmadığı da sorguya dahil edilir.

IDOR Nedir?

Kaynak sahipliği ve yetkilendirme kontrollerinin eksik olması IDOR olarak bilinen güvenlik problemlerine yol açabilir. IDOR, Insecure Direct Object Reference ifadesinin kısaltmasıdır.

Örneğin bir uygulamada aşağıdaki adres kullanıcının faturasını gösteriyor olabilir.

/invoice/5832

Kullanıcı değeri 5833 olarak değiştirdiğinde başka müşterinin faturasını görüntüleyebiliyorsa sistemde yalnızca nesnenin varlığı kontrol ediliyor, kullanıcının o nesneye erişim yetkisi doğrulanmıyor olabilir.

Bu nedenle tahmin edilmesi zor ID değerleri kullanmak tek başına güvenlik mekanizması değildir. Sunucu her istekte kullanıcının ilgili kaynağa erişme yetkisini doğrulamalıdır.

Frontend Yetkilendirme İçin Yeterli Değildir

Bir diğer yaygın hata, kullanıcının erişmemesi gereken butonları veya menüleri frontend üzerinde gizleyerek yetkilendirme sağlandığını düşünmektir.

if (user.role === "admin") {
showDeleteButton();
}

Bu kod kullanıcı deneyimi açısından faydalıdır ancak güvenlik sağlamaz. Kullanıcı butonu göremese bile HTTP isteğini manuel olarak göndermeyi deneyebilir.

Gerçek Authorization kontrolü backend tarafında gerçekleştirilmelidir. Frontend yalnızca kullanıcının sahip olduğu izinlere uygun bir arayüz göstermelidir.

Role-Based Access Control Nedir?

Role-Based Access Control veya RBAC, kullanıcıların roller üzerinden yetkilendirildiği yaygın bir erişim kontrol modelidir.

Örneğin bir ERP sisteminde aşağıdaki roller bulunabilir.

• Admin
• Muhasebe
• Satış
• Depo
• Yönetici
• Standart kullanıcı

Her role belirli yetkiler atanabilir. Örneğin depo çalışanı stok miktarını görüntüleyebilir ancak kullanıcı hesaplarını yönetemez.

Permission-Based Authorization

Daha esnek sistemlerde yalnızca rol kontrol etmek yerine doğrudan izinler tanımlanabilir.

• product.view
• product.create
• product.update
• product.delete
• order.view
• order.refund
• user.manage

Bir rol daha sonra bu izinlerin belirli bir kombinasyonuna sahip olabilir. Böylece yetkilendirme sistemi daha detaylı yönetilebilir.

RBAC Her Sistem İçin Yeterli midir?

Hayır. Bazı sistemlerde kullanıcının rolü tek başına karar vermek için yeterli değildir. Kaynağın sahibi, departman, şirket, lokasyon, işlem zamanı veya verinin durumu gibi ek bilgiler gerekebilir.

Örneğin iki kullanıcının da "manager" rolüne sahip olması, birbirlerinin departmanındaki bütün verilere erişmeleri gerektiği anlamına gelmeyebilir.

ABAC Nedir?

Attribute-Based Access Control veya ABAC, yetkilendirme kararlarının kullanıcı, kaynak ve ortam özelliklerine göre verilmesini sağlayan daha esnek bir modeldir.

Örneğin bir erişim kuralı şu şekilde olabilir: Kullanıcı yönetici rolüne sahip olmalı, kendi şirketindeki kayda erişmeli ve kayıt henüz onaylanmamış olmalıdır.

Büyük kurumsal sistemlerde RBAC ve ABAC yaklaşımlarının birlikte kullanılması mümkündür.

Laravel'de Authentication ve Authorization

Laravel, Authentication ve Authorization için birbirinden ayrılmış mekanizmalar sunar. Authentication tarafında session tabanlı sistemler veya API senaryolarında uygun kimlik doğrulama çözümleri kullanılabilir. Authorization tarafında ise Gates ve Policies gibi mekanizmalar bulunur.

Örneğin bir kullanıcının belirli bir gönderiyi güncelleme hakkını Policy üzerinden kontrol etmek mümkündür.

public function update(User $user, Post $post): bool
{
return $user->id === $post->user_id;
}

Controller içerisinde ise yetkilendirme kontrolü uygulanabilir.

$this->authorize('update', $post);

Böylece yetkilendirme kurallarını controller içerisinde tekrar tekrar yazmak yerine merkezi bir yapıda yönetmek mümkün olur.

API Sistemlerinde Authentication

Modern uygulamalarda frontend ve backend çoğu zaman birbirinden ayrıdır. React, Vue, mobil uygulamalar veya farklı servisler backend API ile iletişim kurabilir.

Bu yapılarda session, güvenli cookie tabanlı yöntemler, token tabanlı sistemler veya OAuth/OpenID Connect gibi standartlar kullanılabilir. Hangi yöntemin uygun olduğu uygulamanın mimarisine ve tehdit modeline göre belirlenmelidir.

JWT Nedir?

JSON Web Token veya JWT, taraflar arasında imzalanmış claim bilgilerinin taşınması için kullanılan bir formattır. API Authentication sistemlerinde sıklıkla kullanılmasına rağmen JWT'nin kendisi bir Authorization sistemi değildir.

Token içerisinde kullanıcı kimliği veya roller gibi bilgiler bulunabilir ancak sunucunun yine erişim politikalarını uygulaması gerekir. Geçerli bir JWT'ye sahip olmak kullanıcının sistemdeki bütün işlemleri yapabileceği anlamına gelmez.

Token İçerisindeki Role Güvenmek Yeterli mi?

Token doğru şekilde imzalanmış ve sunucu tarafından doğrulanmışsa içerisindeki claim'ler yetkilendirme kararlarının bir parçası olabilir. Ancak sistemin tasarımına göre izinlerin değişmesi, token'ın süresi veya kaynak sahipliği gibi başka kontroller de gerekebilir.

Özellikle kritik işlemlerde Authorization kontrolünün yalnızca istemci tarafındaki bilgilere bırakılmaması gerekir.

Authentication İçin Şifreler Nasıl Saklanmalıdır?

Kullanıcı şifreleri veritabanında düz metin olarak saklanmamalıdır. Şifreler bu amaç için tasarlanmış güçlü parola hash algoritmaları kullanılarak saklanmalıdır.

Argon2id ve bcrypt bu amaçla kullanılan yaygın seçenekler arasındadır. Framework'lerin sağladığı güvenli parola hash mekanizmalarının tercih edilmesi, algoritmanın elle uygulanmasından genellikle daha güvenlidir.

Hash ile Encryption Aynı Şey Değildir

Encryption verinin uygun anahtarla tekrar çözülebilmesini amaçlar. Parola hashing ise tek yönlü olacak şekilde tasarlanır. Authentication sırasında kullanıcının girdiği parola aynı doğrulama mekanizmasından geçirilerek saklanan hash ile karşılaştırılır.

Bu nedenle kullanıcı parolalarının geri çözülebilir biçimde saklanması yerine parola doğrulamaya uygun hash algoritmaları kullanılmalıdır.

Multi-Factor Authentication Nedir?

Multi-Factor Authentication veya MFA, kimlik doğrulama sırasında birden fazla doğrulama faktörü kullanılmasını sağlar.

• Kullanıcının bildiği bir şey: parola veya PIN.
• Kullanıcının sahip olduğu bir şey: telefon, güvenlik anahtarı veya authenticator.
• Kullanıcının biyometrik özelliği: parmak izi veya yüz doğrulaması.

Bir saldırgan kullanıcının parolasını ele geçirse bile ikinci doğrulama faktörü hesabın ele geçirilmesini zorlaştırabilir.

Passkey Nedir?

Passkey, açık anahtarlı kriptografiye dayanan modern bir kimlik doğrulama yaklaşımıdır. Kullanıcı tarafındaki özel anahtar cihazda korunurken servis tarafında açık anahtar bulunur.

Bu yaklaşım klasik parola kullanımını azaltabilir ve phishing saldırılarına karşı önemli avantajlar sağlayabilir. Ancak passkey de Authentication mekanizmasının bir parçasıdır; kullanıcının hangi verilere erişeceğini yine Authorization sistemi belirler.

OAuth ile Authentication Aynı Şey mi?

OAuth 2.0 esas olarak yetkilendirme için tasarlanmış bir protokol çerçevesidir. Bir uygulamanın kullanıcının parolasını almadan başka bir servisteki belirli kaynaklara sınırlı erişim elde etmesini sağlar.

"Google ile giriş yap" gibi kimlik doğrulama senaryolarında OAuth 2.0'ın üzerinde OpenID Connect kullanılması yaygındır. OpenID Connect OAuth 2.0 üzerine kimlik katmanı ekler.

Authentication Başarılı Olduktan Sonra Ne Olur?

Başarılı kimlik doğrulamasından sonra sistem kullanıcıyı temsil eden bir session veya başka bir güvenli kimlik mekanizması oluşturabilir. Sonraki isteklerde kullanıcının kimliği bu mekanizma üzerinden belirlenir.

Ancak her hassas işlemde gerekli Authorization kontrolünün yapılması gerekir. Login sırasında kullanıcının rolünü bir kez kontrol etmek, sonraki bütün işlemler için otomatik olarak yeterli değildir.

Least Privilege Prensibi

Least Privilege veya en az ayrıcalık prensibi, bir kullanıcıya veya servise yalnızca görevini gerçekleştirmek için ihtiyaç duyduğu minimum yetkinin verilmesini ifade eder.

Örneğin yalnızca ürün görüntüleyen bir servis hesabının kullanıcı silme veya veritabanı yönetme yetkisine sahip olması gereksizdir. Hesabın ele geçirilmesi durumunda sahip olduğu gereksiz yetkiler saldırının etkisini büyütebilir.

Backend'de Her İstek Yeniden Kontrol Edilmeli mi?

Güvenlik açısından backend, istemciden gelen isteğin güvenilir olduğunu varsaymamalıdır. Kullanıcının frontend üzerinde hangi sayfadan geldiğine veya hangi butona bastığına güvenmek yerine kritik işlemlerde gerekli yetkilendirme kontrolleri sunucu tarafında uygulanmalıdır.

Bu yaklaşım web uygulamalarının yanında mobil uygulamalar ve doğrudan API kullanan istemciler için de geçerlidir.

Admin Paneli Gizlemek Güvenlik Sağlar mı?

Admin panelinin tahmin edilmesi zor bir URL altında bulunması ek bir engel oluşturabilir ancak gerçek bir Authorization mekanizmasının yerini tutmaz.

Yönetim endpoint'leri kullanıcı rolü ve gerekli izinler üzerinden backend tarafında korunmalıdır. URL'nin bilinmemesi güvenlik sınırı olarak kabul edilmemelidir.

401 ve 403 Arasındaki Fark

HTTP API geliştirirken Authentication ve Authorization ayrımı durum kodlarında da görülebilir.

• 401 Unauthorized: İstek geçerli kimlik doğrulama bilgilerine sahip değildir veya kimlik doğrulama gereklidir.
• 403 Forbidden: Sunucu isteği anlamıştır ancak istemcinin ilgili işlemi gerçekleştirmesine izin verilmemektedir.

İsimlendirme nedeniyle 401 kodu ilk bakışta kafa karıştırıcı olabilir. Pratikte 401 çoğunlukla Authentication, 403 ise Authorization problemleriyle ilişkilidir.

Authentication ve Authorization Test Edilmeli mi?

Evet. Özellikle Authorization testleri güvenli yazılım geliştirmede kritik öneme sahiptir. Testler yalnızca yetkili kullanıcının işlemi gerçekleştirebildiğini değil, yetkisiz kullanıcının gerçekleştiremediğini de doğrulamalıdır.

• Giriş yapmamış kullanıcı endpoint'e erişebiliyor mu?
• Standart kullanıcı admin endpoint'ine erişebiliyor mu?
• Bir kullanıcı başka kullanıcının kaydını görüntüleyebiliyor mu?
• Salt okunur kullanıcı veri değiştirebiliyor mu?
• Rol değiştirildiğinde eski yetkiler devam ediyor mu?
• Silinmiş veya devre dışı bırakılmış hesapların oturumları geçerliliğini koruyor mu?

Yapay Zeka ile Kod Yazarken Authorization Kontrolü

Yapay zeka ile yazılım geliştirirken Authentication ve Authorization ayrımı özellikle önemlidir. Bir yapay zeka modeline "bu endpoint'i güvenli hale getir" denildiğinde model yalnızca Authentication middleware ekleyebilir.

Kodun auth middleware arkasında bulunması endpoint'in tamamen güvenli olduğu anlamına gelmez. Kaynak sahipliği, roller, izinler ve iş kuralları ayrıca incelenmelidir.

Bu nedenle yapay zeka tarafından oluşturulan backend kodlarında "Kullanıcı giriş yapmış mı?" kontrolünün yanında "Bu kullanıcı bu işlemi yapmaya gerçekten yetkili mi?" sorusu mutlaka sorulmalıdır.

Güvenli Bir Yetkilendirme Sisteminde Nelere Dikkat Edilmeli?

• Authentication ve Authorization birbirinden ayrı tasarlanmalıdır.
• Yetkilendirme kontrolleri backend üzerinde yapılmalıdır.
• Kullanıcılara minimum gerekli yetki verilmelidir.
• Kaynak sahipliği her gerekli işlemde kontrol edilmelidir.
• Rol kontrolleri tek güvenlik katmanı olarak görülmemelidir.
• Kritik işlemler için daha detaylı permission sistemleri kullanılmalıdır.
• Frontend kontrollerine güvenlik mekanizması olarak güvenilmemelidir.
• API endpoint'leri doğrudan çağrılabileceği düşünülerek tasarlanmalıdır.
• Yetkilendirme senaryoları otomatik testlerle doğrulanmalıdır.
• Rol ve izin değişiklikleri kayıt altına alınmalıdır.

Authentication ve Authorization Akışı

Güvenli bir uygulamada temel erişim akışı basitleştirilmiş şekilde şu mantıkla düşünülebilir.

• 1. Kullanıcı sisteme bir istek gönderir.
• 2. Sistem kullanıcının kimliğini doğrular.
• 3. Authentication başarılıysa kullanıcının kimliği belirlenir.
• 4. Kullanıcının ilgili kaynağa erişim yetkisi kontrol edilir.
• 5. Gerekliyse rol, permission ve kaynak sahipliği değerlendirilir.
• 6. Kullanıcı yetkiliyse işlem gerçekleştirilir.
• 7. Kullanıcı yetkili değilse erişim reddedilir.

Kısa Bir Örnek

Bir kullanıcı sisteme e-posta ve parolasıyla giriş yaptı. Sistem bilgileri doğruladı.

Bu Authentication'dır.

Kullanıcı daha sonra 150 numaralı siparişi silmek istedi. Sistem kullanıcının bu siparişi silme yetkisine sahip olup olmadığını kontrol etti.

Bu Authorization'dır.

Kullanıcının sisteme başarıyla giriş yapmış olması ikinci kontrolü gereksiz hale getirmez.

Sonuç

Authentication ve Authorization modern yazılım güvenliğinin birbirini tamamlayan iki temel mekanizmasıdır. Authentication kullanıcının kim olduğunu doğrularken Authorization kullanıcının sistem içerisinde hangi işlemleri gerçekleştirebileceğini belirler.

Bir kullanıcının başarıyla giriş yapması, sistemdeki bütün kaynaklara erişebileceği anlamına gelmez. Her hassas işlemde rol, permission, kaynak sahipliği veya gerekli erişim politikaları backend tarafında kontrol edilmelidir.

Özellikle API, ERP, e-ticaret, mobil uygulama ve yönetim paneli gibi kullanıcıların farklı yetkilere sahip olduğu sistemlerde bu ayrım kritik öneme sahiptir. Authentication doğru uygulanmış olsa bile eksik Authorization kontrolleri ciddi veri sızıntılarına ve yetkisiz işlemlere neden olabilir.

Güvenli bir yazılımın sorması gereken iki ayrı soru vardır: "Bu kullanıcı gerçekten kim?" ve "Bu kullanıcının yapmak istediği işleme gerçekten yetkisi var mı?" İlk sorunun cevabı Authentication, ikinci sorunun cevabı Authorization'dır.