OAuth 2.0 Güvenliği Nedir? Hızlı Bakış
| Güvenlik Kontrolü | Temel Amaç |
|---|---|
| PKCE | Authorization Code’un ele geçirilerek başka istemci tarafından kullanılmasını zorlaştırır. |
| Exact Redirect URI | Authorization kodunun saldırgan tarafından kontrol edilen adrese yönlendirilmesini önler. |
| State / CSRF Koruması | OAuth akışının saldırgan tarafından başka oturumla ilişkilendirilmesini engellemeye yardımcı olur. |
| Audience Restriction | Access token’ın yalnızca amaçlanan API tarafından kullanılmasını sağlar. |
| Least Privilege Scope | Token’ın sahip olduğu yetkileri yalnızca gerekli işlemlerle sınırlar. |
| Refresh Token Protection | Uzun süreli erişimin ele geçirilmesi durumundaki saldırı etkisini azaltır. |
OAuth 2.0 Güvenliği Nedir? RFC 9700’e Göre 10 Kritik Önlem
1. Authorization Code Flow ve PKCE Kullanın
Modern OAuth uygulamalarında en önemli güvenlik kontrollerinden biri PKCE yani Proof Key for Code Exchange mekanizmasıdır. PKCE, authorization code’un ağ veya tarayıcı akışı sırasında ele geçirilmesi durumunda saldırganın bu kodu kolayca access token’a çevirmesini engellemeye yardımcı olur.
İstemci önce rastgele bir code_verifier üretir ve bunun türetilmiş değerini code_challenge olarak authorization server’a gönderir. Token alınırken gerçek verifier değeri sunulur.
OAuth 2.0 güvenliği nedir yaklaşımında PKCE özellikle public client uygulamalarında temel kontrol olarak değerlendirilmelidir. Güncel OAuth tasarımlarında authorization code flow ile birlikte PKCE kullanılması güçlü bir başlangıç noktasıdır.
2. Redirect URI Değerlerini Exact Match ile Doğrulayın
OAuth saldırılarının en kritik alanlarından biri redirect URI doğrulamasıdır. Authorization server, authentication işlemi sonrasında authorization code veya ilgili cevabı istemci tarafından tanımlanan redirect URI adresine gönderir.
Eğer redirect URI doğrulaması gevşek yapılırsa saldırgan gerçek domaine benzeyen veya saldırganın kontrol ettiği başka bir URL’yi kullanabilir.
RFC 9700, önceden kayıtlı redirect URI değerlerinin mümkün olduğunca tam eşleşme ile kontrol edilmesini önerir. Wildcard veya yalnızca domain başlangıcını kontrol eden gevşek doğrulamalardan kaçınılmalıdır.
3. Open Redirector Kullanmayın
Open redirect, bir web sayfasının URL parametresinden aldığı başka bir adrese kullanıcıyı kontrolsüz biçimde yönlendirmesidir.
Örneğin:
example.com/redirect?url=attacker.example
gibi bir yapı saldırganın OAuth akışındaki güvenilir domaini kötüye kullanmasına neden olabilir.
OAuth istemcileri ve authorization server’lar kullanıcı tarafından gönderilen herhangi bir URL’ye kontrolsüz yönlendirme yapan endpoint’lerden kaçınmalıdır. OAuth 2.0 güvenliği nedir sorusunun önemli cevaplarından biri redirect zincirini güvenilir ve öngörülebilir tutmaktır.
4. Access Token’ları Belirli Resource Server’a Sınırlandırın
Bir access token’ın ele geçirilmesi durumunda saldırganın bu token’ı başka API’lerde de kullanabilmesi saldırının etkisini büyütür.
Bu nedenle token’lar mümkün olduğunca belirli resource server veya audience için üretilmelidir.
Resource server her istekte token’ın kendisi için oluşturulduğunu doğrulamalıdır. JWT tabanlı access token kullanılıyorsa uygun aud claim kontrolü bu işlemin parçalarından biri olabilir.
Böylece bir servise verilmiş token başka serviste otomatik olarak kullanılamaz.
5. Scope Yetkilerini En Az Ayrıcalık İlkesine Göre Verin
OAuth scope değerleri access token’ın hangi işlemleri gerçekleştirebileceğini sınırlandırmak için kullanılır.
Bir uygulamanın yalnızca kullanıcı profilini okuması gerekiyorsa dosya silme, ödeme yapma veya yönetici işlemleri gerçekleştirme yetkileri verilmemelidir.
Geniş kapsamlı token’lar ele geçirildiğinde saldırı etkisi büyür. Bu nedenle OAuth 2.0 güvenliği nedir stratejisinde scope tasarımı en az ayrıcalık prensibine göre yapılmalıdır.
6. Refresh Token’ları Güçlü Biçimde Koruyun
Access token’lar genellikle sınırlı kullanım süresine sahipken refresh token daha uzun süre yeni access token üretmek için kullanılabilir.
Bu nedenle refresh token ele geçirilmesi, kısa süreli access token kaybından daha ciddi sonuçlar doğurabilir.
Refresh token değerlerini güvenli depolayın, istemci türüne göre refresh token rotation gibi yöntemleri değerlendirin ve eski token’ın yeniden kullanılmasını şüpheli davranış olarak ele alın.
Bir refresh token’ın sızdırıldığı tespit edildiğinde ilgili oturum ve token zincirinin iptal edilebilmesi gerekir.
7. Resource Owner Password Credentials Grant Kullanmayın
Eski OAuth uygulamalarında Resource Owner Password Credentials grant adı verilen yöntemde kullanıcı adı ve parola doğrudan uygulama tarafından alınabiliyordu.
Bu yöntem OAuth’un önemli avantajlarından biri olan kullanıcının parolasını üçüncü taraf istemciyle paylaşmaması prensibini zayıflatır.
RFC 9700 bu yöntemin kullanılmaması gerektiğini belirtir. Yeni OAuth uygulamalarında güvenli tarayıcı yönlendirmeli authorization flow yöntemleri tercih edilmelidir.
8. Implicit Grant Yerine Daha Güvenli Akışlar Kullanın
Implicit Grant geçmişte özellikle tarayıcı tabanlı uygulamalarda yaygın olarak kullanılıyordu. Bu yöntemde access token authorization endpoint üzerinden doğrudan istemciye dönebiliyordu.
Modern güvenlik yaklaşımında Authorization Code Flow + PKCE modeli tercih edilir.
Bu değişiklik token’ın URL veya tarayıcı geçmişi gibi alanlara istemeden sızma riskini azaltmaya yardımcı olur. OAuth 2.0 güvenliği nedir konusunda eski örnek kodlardan kopyalanan implicit flow tasarımlarının özellikle kontrol edilmesi gerekir.
9. Token’ları URL İçinde Taşımayın
Access token veya benzeri hassas yetkilendirme bilgilerini URL query parametresi içinde taşımak önemli güvenlik riskleri yaratabilir.
URL değerleri tarayıcı geçmişinde, reverse proxy loglarında, web sunucusu loglarında, analytics sistemlerinde veya Referrer başlıklarında görünür hâle gelebilir.
Bearer token’lar uygun HTTP Authorization header mekanizmasıyla taşınmalıdır.
Ayrıca token değerlerinin uygulama loglarına yanlışlıkla yazılmaması için log masking ve secret filtering uygulanmalıdır.
10. OAuth Token ve Authorization Olaylarını İzleyin
En iyi OAuth yapılandırması bile güvenlik izlemesi olmadan eksik kalır. Aynı refresh token’ın beklenmeyen şekilde tekrar kullanılması, farklı coğrafyalardan hızlı token istekleri veya normalden fazla authorization hatası saldırı belirtisi olabilir.
Authorization server ve resource server loglarında token’ın kendisini kaydetmeden güvenlik açısından gerekli metadata izlenmelidir.
Örneğin client ID, kullanıcı, scope, resource, işlem zamanı, başarısız doğrulama ve token rotation hataları SIEM veya merkezi güvenlik izleme sistemine aktarılabilir.
Bu sayede OAuth 2.0 güvenliği nedir yaklaşımı yalnızca geliştirme zamanındaki yapılandırmadan çıkıp gerçek çalışma zamanında sürekli izlenen güvenlik sürecine dönüşür.
OAuth 2.0 Güvenliği Nedir? Kaçınılması Gereken Eski Yaklaşımlar
| Yaklaşım | Önerilen Yaklaşım |
|---|---|
| Implicit Grant | Authorization Code + PKCE |
| Password Grant | Modern authorization flow |
| Gevşek redirect URI doğrulaması | Exact URI matching |
| URL içinde access token | Authorization header |
| Geniş scope | Least privilege scope |
| Uzun süre değişmeyen refresh token | Rotation / replay detection |
OAuth 2.0 Güvenliği Nedir? 10 Maddelik Kontrol Listesi
- Authorization Code Flow kullanın.
- PKCE etkinleştirin.
- Redirect URI değerlerini tam eşleşmeyle kontrol edin.
- Open redirect endpoint’leri engelleyin.
- Access token’ları audience ve resource açısından sınırlandırın.
- Scope değerlerini en az ayrıcalık ilkesine göre tasarlayın.
- Refresh token değerlerini koruyun ve rotation kullanın.
- Password Grant kullanmayın.
- Implicit Grant kullanımını kaldırın.
- Token değerlerini URL veya loglarda göstermeyin.
- Authorization olaylarını merkezi olarak izleyin.
Sık Yapılan OAuth 2.0 Güvenlik Hataları
- Tüm subdomain’leri redirect URI olarak kabul etmek
- PKCE kullanmamak
- Access token’ı local log dosyalarına yazmak
- Her API için aynı geniş yetkili token’ı kullanmak
- Refresh token’ı süresiz kullanmak
- Eski OAuth örneklerinden Implicit Grant kopyalamak
- Client secret değerini mobil uygulama içine gömmek
- Authorization server loglarını izlememek
OAuth 2.0 Güvenliği Nedir: Sık Sorulan Sorular
OAuth 2.0 kimlik doğrulama protokolü müdür?
OAuth 2.0’ın temel amacı yetkilendirmedir. Kullanıcı kimlik doğrulaması için OAuth üzerinde OpenID Connect gibi ek protokoller kullanılabilir.
PKCE ne işe yarar?
PKCE, ele geçirilen authorization code’un saldırgan tarafından access token almak için kullanılmasını zorlaştırır.
OAuth 2.0’da Implicit Grant kullanılmalı mı?
Yeni uygulamalarda Authorization Code Flow ve PKCE gibi daha güvenli yöntemler tercih edilmelidir.
Refresh token neden daha hassastır?
Refresh token uzun süre boyunca yeni access token üretme imkânı verebildiği için ele geçirilmesi kalıcı erişim riskini artırabilir.
Access token URL içinde gönderilebilir mi?
Token değerlerini URL içinde taşımak log, geçmiş ve Referrer üzerinden sızıntı riskini artırdığı için tercih edilmemelidir.
OAuth 2.0 güvenliği için en önemli kaynak hangisidir?
Güncel güvenlik uygulamaları açısından IETF tarafından yayımlanan RFC 9700 önemli temel kaynaklardan biridir.
İlgili İçerikler
Workload Identity Federation Nedir?
Resmî ve Güvenilir Kaynaklar
IETF / RFC Editor — RFC 9700: Best Current Practice for OAuth 2.0 Security
Sonuç
OAuth 2.0 güvenliği nedir sorusuna; OAuth yetkilendirme akışlarında authorization code, access token, refresh token, redirect URI ve istemci kimliği gibi kritik bileşenlerin güncel güvenlik uygulamalarıyla korunması şeklinde cevap verilebilir.
PKCE, exact redirect URI kontrolü, token audience sınırlandırması, en az ayrıcalıklı scope, refresh token koruması ve güvenlik izlemesi birlikte uygulandığında OAuth saldırı yüzeyi önemli ölçüde azaltılabilir. Özellikle RFC 9700’de yer alan güncel önerileri takip etmek, OAuth 2.0 güvenliği nedir konusunu eski örnek kodlara bağlı kalmadan modern güvenlik yaklaşımıyla uygulamayı sağlar.
