SaaS Ürünlerinde OAuth ve OIDC Güvenlik Testi

Kısa cevap

OAuth/OIDC testi yalnızca login ekranını veya JWT imzasını kontrol etmek değildir. Tarayıcı, istemci, yetkilendirme sunucusu ve SaaS backend’i arasındaki kimlik geçişleri; token’ın hangi API’de kabul edildiği; hesap bağlama ve kullanıcı kapatma davranışları uçtan uca doğrulanmalıdır. Kritik hata, geçerli token’ın yanlış API’ye, istemciye, kullanıcıya ya da tenant’a kabul edilmesidir.

OAuth yetkilendirme devrini, OIDC ise kimlik bilgisini tanımlar. Protokolleri kullanmak güvenli yapılandırma garantisi vermez. SPA, mobil uygulama, sunucu web uygulaması ve kurumsal SSO ayrı akışlar olarak haritalanmalıdır.

Akış envanteri ve işlem bağı

Her client için client_id, tam redirect URI, beklenen issuer, token audience ve izin verilen grant türlerini kaydedin. Login başlangıcından callback’e, code değişiminden oturum oluşturmaya, refresh ve logout’a kadar hangi bileşenin hangi veriye güvendiğini takip edin.

Redirect URI’nin önceden kayıtlı tam değerle eşleştiğini test edin. Wildcard, gevşek subdomain eşleşmesi, open redirect veya kullanıcı denetimindeki callback authorization code’u başka yere taşıyabilir. Encoding ve slash varyantlarını deneyip kabul edilen biçimleri belgeleyin.

state callback’i başlatılan tarayıcı işlemine bağlamalı; OIDC nonce kimlik token’ını login isteğine; PKCE ise code’u aynı client işleminin verifier’ına bağlamalıdır. Geçerli bir akışı kaydedin, ardından state, nonce ve code’u farklı oturumlar arasında değiştirin. Eşleşmeyen callback tamamlanmamalıdır.

Token doğru API ve kullanıcıya mı ait?

İmza geçerliliği yeterli değildir. API; beklenen issuer, audience, token türü, algoritma, süre ve scope/role değerlerini doğrulamalıdır. ID token’ı access token gibi ve başka servise verilmiş access token’ı mevcut API’de kullanmayı deneyin. İmzalı ama yanlış audience veya issuer reddedilmelidir.

JWKS anahtar döndürme, kid seçimi, cache ve beklenmeyen algoritma davranışını inceleyin. Güvenilmeyen claim’den key kaynağı seçilmemeli; eski anahtar kabul penceresi sınırlı olmalıdır. Hata yanıtı token’ı veya doğrulama sırlarını açığa çıkarmamalıdır.

Hesap bağlama ve tenant üyeliği

Sosyal kimliği mevcut SaaS hesabına bağlamak yüksek riskli bir karardır. Farklı issuer’ların aynı e-posta değerini aynı kişi saymayın. E-posta değişikliği, alias, davet ve doğrulanmamış hesap senaryolarında otomatik birleştirmeyi deneyin. Mevcut oturuma yeni kimlik eklemek için yeniden doğrulama ve açık kullanıcı niyeti aranmalıdır.

Kurumsal SSO’da domain eşleşmesi tek başına tenant üyeliği değildir. Davet, SCIM provisioning, kullanıcı askıya alma ve IdP bağlantısını kaldırma sonrası rollerin nasıl güncellendiğini test edin.

Senaryo	Güvenli sonuç
Aynı e-posta, farklı issuer	Otomatik hesap birleştirme yok
Tenant dışı SSO kullanıcısı	Açık üyelik olmadan erişim yok
Devre dışı kullanıcı	Yeni oturum ve hassas refresh reddedilir
Yanlış API için token	Audience uyuşmazlığında reddedilir
Başka browser’dan callback	State/PKCE eşleşmeden tamamlanmaz

Refresh, logout ve yaşam döngüsü

Refresh token rotation, tekrar kullanım tespiti ve istemciye göre saklama incelenmelidir. Eski token yeniden kullanıldığında beklenen iptal davranışını doğrulayın. Logout yalnızca browser cookie’sini silip server session veya refresh’i açık bırakmamalıdır.

Parola değişimi, MFA sıfırlama, çalışan ayrılığı ve tenant’tan çıkarılma sonrası erişimin ne kadar sürdüğünü ölçün. Kısa ömürlü JWT anlık iptal değildir; kritik işlemlerde güncel hesap durumunun denetlendiğini kanıtlayın.

Güvenli test sırası

Her istemci ve giriş türünü ayrı diyagramlayın.
Sandbox akışını kaydedin ve token’ları maskeleyin.
Redirect, state, nonce, PKCE ve callback oturum bağını ayrı ayrı bozun.
Token’ı yanlış issuer, audience, API, tenant ve role bağlamında deneyin.
Hesap bağlama, davet, provisioning, kapatma ve refresh tekrar kullanımını test edin.
Bulguyu protokol hatasıyla birlikte hangi hesaba/tenant’a erişildiğini açıklayarak raporlayın.

İstemci tipine göre farklı tehdit modeli

Public client secret’ı gizli tutamaz. SPA ve mobil uygulamada uygulama paketine gömülü secret güvenlik sınırı değildir; Authorization Code + PKCE ve sıkı redirect kaydı daha anlamlı kontrollerdir. Confidential web client’ta ise client kimlik doğrulaması, secret veya private key saklama ve token endpoint’ine erişim ayrıca test edilir. Servis-to-servis akışlarında kullanıcı oturumu taklidi yerine dar kapsamlı service identity aranmalıdır.

Birden çok IdP veya issuer varsa iss ve sub değerlerinin tenant bağlamında nasıl eşleştirildiğini inceleyin. Sadece sub değerini global kullanıcı anahtarı kabul etmek issuer’lar arasında çakışmaya yol açabilir. Tenant’a özel bağlantının kapatılması, yeni girişleri durdurmanın yanında mevcut session ve refresh yetkilerinin yaşam süresini de netleştirmelidir.

Hataları güvenli biçimde gözlemleyin

Test sırasında authorization code, access token, refresh token ve ID token’ı rapora düz metin koymayın. İstek/yanıt kanıtını redakte edilmiş biçimde saklayın; mümkünse claim setinin sadece iss, aud, süre ve rol gibi ilgili alanlarını gösterin. Token doğrulama hatasında uygulama detaylı iç nedeni kullanıcıya vermemeli, fakat sunucu logu olayın issuer/audience uyuşmazlığı mı yoksa süresi dolma mı olduğunu teşhis etmeye yetecek güvenli bir kod taşımalıdır.

Bulgu önceliğini protokol adıyla değil, erişilebilen aksiyonla belirleyin. Başka API’ye token sunulması reddediliyorsa bu koruma kanıtıdır; başka tenant’ın yönetici API’sinde kabul edilmesi ise yüksek etkili bir yetki sınırı ihlalidir. Retest; saldırı akışının artık çalışmadığını ve doğru kullanıcı/tenant’ın normal girişinin bozulmadığını birlikte göstermelidir.

OAuth/OIDC’nin uygulama ve API kontrolleriyle birlikte değerlendirilmesi için uygulama güvenliği testimize bakabilirsiniz.