Her oturum açma ekranının arkasında iki ayrı soru çalışır: "Sen kimsin?" ve "Buna erişebilir misin?". İlki kimlik doğrulama, ikincisi yetkilendirmedir; karıştırıldıklarında en büyük güvenlik açıkları doğar. Bu sayfada OAuth 2.0 ve OpenID Connect'ten SSO ve federasyona, çok faktörlü doğrulamadan token yaşam döngüsüne ve RBAC/ABAC yetkilendirmesine kadar — uygulamanızın kimlik katmanını birlikte sadeleştirelim.
Kimlik ve erişim yönetimi (IAM), bir sistemde kimin kim olduğunu ve neye erişebileceğini yöneten katmandır. İki kavram sürekli karıştırılır: kimlik doğrulama (authentication) "sen gerçekten iddia ettiğin kişi misin?" sorusunu yanıtlar; yetkilendirme (authorization) ise "bu işlemi yapmaya iznin var mı?" sorusunu. Doğru kimlik, yanlış yetki kontrolüyle birleştiğinde — örneğin giriş yapan bir kullanıcının başkasının verisine erişebilmesi — en sık görülen kritik açıklardan biri ortaya çıkar.
Kullanıcının iddia ettiği kimliği kanıtlamasıdır: parola, tek seferlik kod, donanım anahtarı ya da biyometri. Sonuç ikilidir — kanıtlandı ya da kanıtlanmadı. Bundan sonraki her karar bu kimliğe dayanır.
Doğrulanmış kimliğin neyi yapabileceğine karar verir: hangi sayfayı görebilir, hangi kaydı düzenleyebilir, hangi API'yi çağırabilir. Kimlik bir kez kurulur; yetki ise her istekte yeniden sorgulanmalıdır.
Kim, ne zaman, neye erişti? Denetim kaydı (audit log) olmadan doğrulama ve yetkilendirme yarım kalır. Bir olayın izini sürebilmek, IAM'in görünmeyen ama vazgeçilmez üçüncü ayağıdır.
# 1. kimlik doğrulama — "sen kimsin?"
POST /login kimlik bilgisi + ikinci faktör
→ kimlik kanıtlandı, oturum/token verildi
# 2. her istekte yetkilendirme — "iznin var mı?"
GET /invoices/42 Authorization: Bearer <token>
↓ sunucu kontrol eder
kullanıcı 42 numaralı faturanın sahibi mi?
evet → 200 OK
hayır → 403 Forbidden # kimlik geçerli ama yetki yokBu üç standart sürekli birbirine karıştırılır çünkü çoğu zaman aynı oturum açma ekranının arkasında birlikte çalışırlar. Ama her biri farklı bir işi yapar: biri yetki devri, biri kimlik doğrulama, biri ise kurumsal dünyada federasyon için tasarlanmıştır.
Bir uygulamanın, parolanızı görmeden adınıza sınırlı bir işlem yapmasına izin verir — "bu uygulama takvimime erişebilsin" gibi. OAuth bir kimlik doğrulama protokolü değildir; tek başına "kullanıcı kim?" sorusunu güvenle yanıtlamaz.
OAuth 2.0'ın üzerine inşa edilmiş kimlik katmanıdır. "Google ile giriş yap" akışlarının altında bu çalışır. Kullanıcının kimliğini doğrulanabilir bir ID token (JWT) ile taşır — "kullanıcı kim?" sorusunu OAuth'un eksik bıraktığı yerde yanıtlar.
XML tabanlı, kurumsal SSO'nun yıllardır taşıyıcısı olan standart. Çalışanın şirket hesabıyla üçüncü taraf uygulamalara girmesini sağlar. Yeni projelerde yerini büyük ölçüde OIDC'ye bırakıyor; ama kurumsal entegrasyonlarda hâlâ çok yaygın.
Bugün önerilen varsayılan akış. Kullanıcı kimlik sağlayıcıda doğrulanır, uygulamaya kısa ömürlü bir code döner, uygulama bunu arka kanaldan token'la takas eder. PKCE eklentisi, code'un yolda çalınıp kullanılmasını engeller; mobil ve tek sayfa uygulamalarda zorunlu sayılır.
Implicit flow ve Resource Owner Password akışları artık önerilmez: token'ı tarayıcı geçmişinde ya da uygulamaya parola vererek riske atarlar. Token'lar her zaman TLS üzerinden taşınmalıdır; aktarım güvenliği için TLS, SSL ve Sertifikalar.
aud (audience) ve iss (issuer) alanlarını mutlaka kontrol edin.
Tek oturum açma (SSO), kullanıcının bir kez kimliğini doğrulayıp birden çok uygulamaya yeniden parola girmeden erişmesidir. Bunu mümkün kılan şey federasyondur: uygulamalar (service provider) kimlik doğrulamayı kendileri yapmaz, güvendikleri merkezî bir kimlik sağlayıcıya (identity provider, IdP) devreder.
Faydası açık: tek bir güçlü kimlik, daha az parola, merkezî erişim iptali. Ama riski de merkezîdir — IdP ele geçirilirse ona bağlı tüm uygulamalar etkilenir. Bu yüzden IdP'de güçlü MFA ve sıkı denetim kaydı vazgeçilmezdir.
# kullanıcı bir uygulamaya (SP) girmek istiyor
1. GET app.sirket.com oturum yok
→ IdP'ye yönlendir
2. login.sirket.com # kimlik sağlayıcı (IdP)
kullanıcı zaten oturum açmış mı?
evet → adım 3'e geç (parola sorulmaz)
hayır → kimlik doğrula + MFA
3. IdP imzalı bir assertion / id_token üretir
→ uygulamaya geri yönlendir
4. app.sirket.com imzayı doğrular, oturumu açar
✓ erişim verildiParola tek başına en zayıf halkadır: tahmin edilir, sızar, yeniden kullanılır. Çok faktörlü doğrulama, birbirinden bağımsız iki ayrı kanıt türünü birleştirir — bildiğiniz, sahip olduğunuz ve olduğunuz şey. Tek bir faktör çalınsa bile saldırgan ikinciyi sağlayamaz.
Parola, PIN ya da güvenlik sorusu. En yaygın ama en kırılgan faktör; tek başına kullanıldığında kimlik avı ve sızıntılara açıktır.
knowledgeTelefondaki authenticator uygulaması (TOTP), donanım güvenlik anahtarı (FIDO2) ya da geçiş anahtarı (passkey). Fiziksel sahiplik gerektirdiği için uzaktan çalınması zordur.
possessionParmak izi, yüz ya da diğer biyometrik veriler. Genellikle cihazda yerel olarak doğrulanır; biyometrik veri cihazdan dışarı çıkmaz, yalnızca "doğrulandı" sinyali iletilir.
inherenceFaktörler eşit güçte değildir. SMS ile gelen kodlar MFA'nın en zayıf biçimidir — SIM swap ve kimlik avı ile aşılabilir. Authenticator uygulamaları (TOTP) belirgin biçimde daha güvenlidir; FIDO2/passkey ise kimlik avına karşı dirençli olduğu için bugün altın standarttır.
Geçiş anahtarları (passkey), parola ve ortak sırrı tamamen ortadan kaldırır; her site için cihazda saklanan açık/özel anahtar çiftine dayanır. Kimlik avıyla çalınamaz, çünkü doğrulama alan adına bağlıdır. Yeni projelerde birincil yöntem olarak değerlendirin.
MFA ne kadar güçlü olursa olsun, "şifremi unuttum" akışı e-postaya düşüyorsa güvenlik o seviyeye iner. Kurtarma kodlarını tek kullanımlık üretin, e-posta hesabını da MFA ile koruyun; aksi halde en güçlü kapının yanına açık bir pencere bırakırsınız.
Saldırganlar art arda push bildirimi göndererek kullanıcıyı "onayla"maya zorlar (MFA fatigue). Sayı eşleştirmeli (number matching) onay ve hız sınırlama bunu kırar. Anormal giriş denemelerini görünür kılmak için Observability & Logging.
Kimlik bir kez doğrulandıktan sonra, her istekte yeniden parola sormamak için bir oturum durumu taşınır. Bu iki temel yaklaşımla yapılır: sunucuda tutulan klasik session ya da istemcide taşınan imzalı token (JWT). İkisinin de güçlü ve zayıf yanları vardır; doğru seçim, iptali ne kadar hızlı yapmanız gerektiğine bağlıdır.
# header.payload.signature
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjMi....Tc8Hk3...
# payload çözüldüğünde (base64 — şifreli DEĞİL)
{
"sub": "user_123", # kimin
"iss": "login.sirket.com", # kim üretti (issuer)
"aud": "app.sirket.com", # kimin için (audience)
"exp": 1735689600, # son kullanma — kısa olmalı
"scope": "read:invoices"
}
# imza, üretenin özel anahtarıyla atılır
# payload'a asla sır koymayın — herkes okuyabilirHttpOnly bir çerezde saklanmalı ve her kullanımda döndürülerek (rotation) çalınma tespit edilmelidir.
exp ile bir kara liste/oturum kaydını birlikte kullanın.
localStorage'da tutmak XSS'e karşı açıktır — HttpOnly çerez tercih edin. XSS savunması için Web Uygulama Güvenliği.
Kimlik doğrulandıktan sonra "neye erişebilir?" sorusunu bir modelle yanıtlarsınız. İki yaygın yaklaşım vardır: izinleri rollere bağlayan RBAC ve özniteliklere bağlayan ABAC. Her ikisinin de üzerinde değişmez bir ilke durur: en az ayrıcalık.
İzinler doğrudan kullanıcıya değil, rollere verilir; kullanıcı role atanır. "Editör", "Yönetici", "Görüntüleyici" gibi. Anlaşılması ve yönetilmesi kolaydır, çoğu uygulama için yeterlidir. Zayıflığı: çok ince ayrım gerektiğinde rol sayısı patlar (role explosion).
Karar; kullanıcının, kaynağın ve bağlamın özniteliklerine göre verilir — "aynı departmandan, mesai saatinde, kurumsal ağdan" gibi. Çok esnektir ama kurallar karmaşıklaştıkça akıl yürütmesi ve test edilmesi zorlaşır. Genellikle RBAC'ın üzerine, ince ayar için eklenir.
Varsayılan "reddet" olmalı; erişim yalnızca gerektiğinde ve gerektiği kadar açılmalı. Geniş "her şeye yetkili" hesaplar, ele geçirildiğinde verdikleri zararla orantılı bir risktir.
Yetkiler zamanla birikir (privilege creep): rol değiştiren çalışan eski izinlerini taşır. Düzenli erişim incelemeleriyle "kimin neye, neden erişimi var?" periyodik olarak gözden geçirilmeli ve fazlalıklar geri alınmalıdır.
Arayüzde bir butonu gizlemek yetki kontrolü değildir. Her yetki kararı sunucuda, kaynağa erişilen noktada yeniden uygulanmalı; istemciden gelen "ben yöneticiyim" iddiasına asla güvenilmemelidir.
Authentication kim olduğunuzu doğrular ("sen sen misin?"). Authorization neye erişebileceğinize karar verir ("buna iznin var mı?"). Önce kimlik kurulur, sonra her istekte yetki sorgulanır. 401 birincinin, 403 ise ikincinin başarısızlığıdır.
OAuth 2.0 bir yetki devri protokolüdür; access token verir ama "kullanıcı kim?" sorusunu güvenle yanıtlamaz. OIDC ise OAuth üzerine kimlik katmanı ekler ve imzalı bir ID token ile kimliği taşır. Giriş için OIDC, kaynak erişimi için OAuth düşünün.
SSO kaç kez kimlik doğrulayacağınızı azaltır — bir kez girip çok uygulamaya erişirsiniz (kolaylık). MFA ise tek bir doğrulamayı güçlendirir — birden çok faktör ister (güvenlik). Birbirinin alternatifi değil, tamamlayıcısıdır; ikisi birlikte kullanılır.
Access token kısa ömürlüdür ve her API isteğinde sunulur. Refresh token uzun ömürlüdür ve yalnızca yeni access token almak için kullanılır. Access çalınırsa pencere dardır; refresh çok daha değerlidir ve sıkı korunmalı, döndürülmelidir.
RBAC izinleri rollere bağlar; anlaşılır ve çoğu durum için yeterlidir. ABAC izinleri kullanıcı/kaynak/bağlam özniteliklerine bağlar; çok esnektir ama yönetimi karmaşıktır. Pratikte sıklıkla RBAC tabana, ABAC ince ayara konur.
Session durumu sunucuda tutulur; iptali anında olur ama ölçeklenirken paylaşımlı depo gerekir. JWT durumu imzalı olarak istemcide taşır; durumsuzdur ve ölçeklenir ama tek tek iptali zordur. Seçim, anlık iptale ne kadar ihtiyaç duyduğunuza bağlıdır.
OAuth, OpenID Connect, SAML, token biçimleri ve dijital kimlik kuralları için resmi kaynaklar.
Oturum açma akışınızı, token yaşam döngünüzü, MFA kurulumunuzu ve yetkilendirme modelinizi gözden geçirelim — uygulamanızın kimlik ve erişim katmanını birlikte sağlamlaştıralım.