1. GİRİŞ

OAuth, modern uygulamalarda yetkilendirme için en yaygın kullanılan protokoldür; OpenID Connect (OIDC) ise kimlik bilgisi katmanını ekler. Mobil uygulamalar, tek sayfa uygulamaları (SPA), mikroservisler ve API ekonomisi OAuth/OIDC ile güvenilir, standartlaştırılmış erişim modeli sağlar. Ancak protokolün esnekliği ve farklı akış seçenekleri yanlış yapılandırıldığında kritik güvenlik açıklarına yol açabilir. Bu nedenle OAuth güvenliği tasarım aşamasından başlayıp üretim ve operasyonel izlemeye kadar sürekli ele alınmalıdır.

Bu konu neden bugün önemli?

• Uygulamalar OAuth ile üçüncü taraf erişimini kolaylaştırıyor; yanlış scope veya redirect konfigurasyonu veri sızıntısına neden olabilir.
• Token'ların yanlış yönetimi (uzun süreli tokenlar, imza doğrulaması atlanması) account takeover ve service abuse riskini artırır.
• SSO yaygınlaştıkça bir IdP'nin ele geçirilmesi geniş çaplı etkiler doğurur; IdP güvenliği kritik hale gelir.

Kimler için önemli?

• Kimlik ve erişim mimarları
• Backend ve frontend geliştiriciler
• Güvenlik mühendisleri ve DevSecOps ekipleri
• Platform/Identity sağlayıcıları ve entegrasyon ekipleri

Hangi problemleri çözüyor?

• Güvenli token alışverişi ve delegation
• SSO ile kullanıcı deneyimini bozmadan güvenlik sağlama
• Yetkilendirme ve kimlik bilgilerinin merkezi yönetimi

2. KAVRAMSAL TEMELLER

2.1 OAuth ve OIDC — kısa tanım

OAuth2, kaynak sahibinin (resource owner) erişim delegasyonunu sağlayan bir yetkilendirme çerçevesidir. OpenID Connect (OIDC) ise OAuth2 üzerine kimlik doğrulama katmanı getirir ve id_token ile kullanıcı kimliğini taşır. Temel kavramlar: client (uygulama), resource owner (kullanıcı), authorization server (IdP), resource server (API) ve redirect_uri gibi parametrelerdir.

2.2 Ortak terminoloji

• Access Token: Kaynak sunucusuna erişim izni veren kısa ömürlü jeton.
• Refresh Token: Yeni access token almak için kullanılan daha uzun ömürlü jeton (safely stored).
• Authorization Code: Yetki kodu akışında IdP tarafından client'a verilen tek kullanımlık kod.
• PKCE: Public client'lar için code exchange sırasında man‑in‑the‑middle saldırılarını önleyen mekanizma (Proof Key for Code Exchange).
• Redirect URI: IdP'nin authorization response'ı göndereceği client adresi; kesin olarak doğrulanmalıdır.

3. NASIL ÇALIŞIR?

3.1 Yaygın akışlar ve kullanım senaryoları

• Authorization Code Flow (confidential client): Sunucu tarafı uygulamalar için tercih edilir. Authorization code alınır, client secret ile token değişimi yapılır.
• Authorization Code + PKCE (public client): Mobil ve SPA'ler için safe seçenektir; client secret saklanamayan ortamlarda PKCE zorunludur.
• Implicit Flow: Eskiden SPA'ler için kullanılan akış; artık güvenlik nedenleriyle önerilmez.
• Client Credentials Flow: Service‑to‑service yetkilendirme; kullanıcı bağlamı yoktur.
• Resource Owner Password Credentials (ROPC): Kullanıcı adı/parola direkt client'a verildiğinde kullanılır; modern uygulamalarda önerilmez.

3.2 Sistem mimarisi ve veri akışı

Tipik Authorization Code + PKCE akışında: kullanıcı client uygulamayı kullanır → client IdP'ye authorization isteği gönderir (code_challenge ile) → kullanıcı IdP'de oturum doğrular → IdP authorization code ile redirect eder → client code ve code_verifier ile token endpoint'e gider → IdP access/refresh token döner. Access token resource server'a isteklerde kullanılır.

3.3 Güvenlik karar noktaları

• redirect_uri doğrulaması: tam eşleşme veya whitelisting zorunlu
• state parametresi: CSRF koruması için kullanılır; her istek için unique olmalı
• PKCE: code exchange sırasında doğrulama için kritik
• token scope ve audience (aud): kaynak sınırlandırması ve target API doğrulama

4. YAYGIN TEHDİTLER VE ZAFİYETLER

4.1 Redirect URI manipülasyonları

Redirect URI doğrulanmadığında veya wildcard kullanıldığında authorization code veya token'lar saldırgan kontrolündeki endpoint'e gönderilebilir. Bu durum authorization code interception veya token theft ile sonuçlanır. çözüm: kesin eşleşme, whitelist ve protocol (https) zorunluluğu.

4.2 CSRF ve state parametresi eksikliği

Authorization isteklerinde state parametresi kullanılmazsa CSRF saldırılarıyla kullanıcı istemeden saldırganın başlattığı akışa yönlendirilebilir. Önlem: her authorization isteği için rastgele state, session'da saklama ve dönüşte doğrulama.

4.3 PKCE olmadan public client kullanımı

PKCE kullanılmayan mobil veya SPA uygulamalarında authorization code interception mümkündür. PKCE, attacker'ın authorization code'u kendi token'a çevirmesini engeller.

4.4 Token leakage ve storage hataları

Access veya refresh token'ların localStorage gibi XSS'e açık alanlarda saklanması kritik hatadır. HttpOnly, Secure cookie kullanımı (CSRF ile trade‑off dikkate alınmalı) veya platform‑native secure storage tercih edilmelidir. Ayrıca long‑lived token'ların kötüye kullanımı risklidir; refresh token rotation ve revocation mekanizmaları uygulanmalıdır.

4.5 Token forgery ve alg='none' gibi zayıflıklar

JWT validation sırasında signature kontrolü atlanır veya alg değeri esnek bırakılırsa saldırgan sahte token üretebilir. İmzalama algoritmasının sabitlenmesi, key management ve token issuer/audience doğrulaması zorunludur.

4.6 Scope ve excessive privilege

Gereğinden geniş scope'lar clientlara verildiğinde (ör. full:read_write) token çalındığında etki artar. Principle of least privilege; scope'ları minimize edin ve kullanım bazlı izinler uygulayın.

4.7 Open redirect ve phishing senaryoları

Open redirect zafiyetleri, OAuth akışını phishing kampanyaları için kullanılabilir. Redirect hedeflerinin kesin kontrolü ve IdP tarafından gösterilen insan‑okuyabilir izin ekranları (consent) phishing'i zorlaştırır.

5. GERÇEK DÜNYA ÖRNEKLERİ

OAuth zayıflıkları geçmişte birçok ciddi vaka ile gündeme geldi: public repo'larda client secret sızıntıları, yanlış redirect_uri konfigurasyonlarıyla token hırsızlığı, refresh token'ların XSS ile ele geçirilmesi ve IdP misconfigurasyonları. Büyük şirketler, IdP'lerini multi‑tenant güvenlik gereksinimlerine göre sıkılaştırdı; PKCE standart hale geldi ve implicit flow kullanımından kaçınıldı.

5.1 Mobil uygulama senaryosu

Mobil uygulamalarda OAuth ile native browser veya in‑app browser kullanımı arasında trade‑off vardır. In‑app browser (webview) kullanımı XSS ve token interception riskini artırabilir; sistem tarayıcı (system browser) + PKCE önerilir. Ayrıca mobile OS secure storage (Keychain/Keystore) kullanılmalıdır.

5.2 SPAs ve CORS/CSRF

SPA'ler genellikle auth code + PKCE ile çalışır; token'ların client tarafı saklanması dikkat gerektirir. CORS yapılandırmaları ve SameSite cookie politikaları, token security ile doğrudan ilişkilidir. OIDC kullanımıyla id_token doğrulaması ve userinfo endpoint kontrolleri yapılmalıdır.

6. AVANTAJLAR VE SINIRLAMALAR

6.1 OAuth'un avantajları

• Standartlaştırılmış delegation modeli; üçüncü taraf erişimi kontrol etme
• SSO ve merkezi kimlik sağlayıcı ile yönetim kolaylığı
• Çeşitli client tipleri (confidential/public) için farklı akışlar sunması

6.2 OAuth uygulama zorlukları

• Yanlış konfigurasyonun ağır güvenlik etkileri olabilir
• Token lifecycle ve revocation yönetimi operasyon gerektirir
• Client türüne göre güvenlik yaklaşımları farklılık gösterir; developer iş birliği şarttır

7. EN İYİ PRATİKLER

7.1 Tasarım ve production kullanımı

• Authorization Code + PKCE: Public client'lar (SPA, mobil) için tercih edin; implicit akışı kullanmayın.
• redirect_uri tam eşleşmesi kullanın; wildcard ve dinamik redirect'lerden kaçının.
• state parametresini her authorization isteği için zorunlu tutun ve session ile ilişkili saklayın.
• Access token'ları kısa ömürlü yapın; refresh token rotation ve revocation uygulayın.
• Token'ları HttpOnly, Secure cookie veya platform secure storage'ta saklayın; XSS riskini minimize edin.
• Audience (aud) ve scope validation: resource server access token'ı doğrulamalı ve izinleri denetlemelidir.

7.2 Operasyonel ve performans

• Key management: signing key'leri KMS/HSM içinde tutun ve anahtar rotasyon politikası uygulayın.
• Token introspection endpoint'leri ile token revocation ve canlı doğrulama sağlayın; cache ile performans dengeleyin.
• Telemetry: failed token validation, unexpected audience, multiple token usage, ve token theft indikasyonlarını SIEM ile korele edin.

7.3 Güvenlik

• PKCE uygulayarak code exchange güvenliğini sağlayın.
• Consent ekranlarını açık ve anlamlı tutun; kullanıcıyı hangi erişimlerin verildiği konusunda bilgilendirin.
• Client secret'ları asla public repos'da veya istemci tarafında saklamayın; CI/CD pipeline'larında secret scanning uygulayın.

8. SIK YAPILAN HATALAR

• Implicit flow veya token doğrudan URL fragment'ında saklama — önerilmez.
• redirect_uri wildcard kullanmak veya tam eşleşme kontrolü yapmamak.
• PKCE uygulamadan public client'a authorization code verme.
• Long‑lived access token kullanmak ve refresh token rotation uygulamamak.
• Client secret veya token'ları version control içine geçirmek.

9. GELECEK TRENDLER

9.1 Continuous Authorization ve risk‑based decisions

Geleneksel statik izinlerin ötesinde, runtime risk skorlarına dayanan dinamik authorization kararları yaygınlaşacak. Bu, token kullanım davranışına göre adaptive additional checks (MFA, re‑auth) tetikleyebilecek.

9.2 Decentralized identity ve verifiable credentials

Merkezi IdP'lerden bağımsız, verifiable credentials tabanlı authentication/authorization modelleri (DID, verifiable credentials) belirli senaryolarda OAuth'u tamamlayıcı rol alacak; ancak geniş kabul için standartlaşma gerekiyor.

9.3 OAuth ve privacy by design

Consent UX ve minimal scope uygulamalarıyla birlikte verinin korunmasına yönelik daha sıkı gereksinimler (regülasyon) uygulanacak. OAuth implementasyonları privacy‑first prensipleriyle şekillendirilecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. PKCE nedir ve neden gerekli?

   PKCE (Proof Key for Code Exchange), authorization code'un public client tarafından güvenli şekilde token'a çevrilmesini sağlar; code interception saldırılarını önler. Mobil ve SPA gibi secret saklanamayan client'larda zorunludur.

2. 2. Implicit flow artık kullanılmalı mı?

   Hayır. Implicit flow güvenlik zafiyetleri nedeniyle önerilmez; yerine Authorization Code + PKCE kullanılmalıdır.

3. 3. Token'ları localStorage'ta saklamalı mıyım?

   LocalStorage XSS'e açıktır; mümkünse HttpOnly, Secure cookie veya platform secure storage (Keychain/Keystore) kullanın. Eğer client tarafında saklama kaçınılmazsa XSS riskini minimize edecek tedbirler alınmalıdır.

4. 4. Refresh token'ları nasıl güvenle yönetirim?

   Refresh token'ları rotate edin, kullanımda blacklist/ revocation mekanizmaları kurun, ve refresh endpoint'lerini anomalous usage'a karşı izleyin. Ayrıca refresh token'ları mümkünse secure storage'ta tutun.

5. 5. redirect_uri nasıl doğrulanmalı?

   IdP tarafında redirect_uri için tam eşleşme veya kesin whitelisting uygulayın. Dinamik veya wildcard redirect'ler güvenlik riski taşır.

6. 6. OAuth implementasyonunu test etmek için hangi kontrolleri yapmalıyım?

   State parametresi doğrulaması, PKCE doğrulaması, redirect_uri tam eşleşmesi, token signature validation, audience/scope doğrulaması ve refresh token rotation testlerini düzenli olarak yapın.

7. 7. IdP güvenliği için en kritik adım nedir?

   Key management ve signing key'lerin korunması en kritik adımdır; ayrıca IdP erişim kontrolü, monitoring ve anomaly detection olmalıdır.

8. 8. OAuth entegrasyonlarında en sık yapılan hata nedir?

   Client secret'ların sızdırılması ve redirect_uri kontrolünün zayıf olması en sık rastlanan ve kritik hatalardır.

Anahtar Kavramlar

• PKCE: Authorization code exchange güvenliği için kullanılan mekanizma.
• Redirect URI: Authorization response'ın gönderileceği client adresi.
• Access/Refresh Token: Kaynak erişimi ve token yenileme amaçlı jetonlar.
• Scope: Token ile verilecek izinlerin sınırlandırması.
• Client Secret: Confidential client'lar için saklanması gereken sırlı değer.

Öğrenme Yol Haritası

1. 0–1 ay: OAuth2 temel kavramları, OAuth akışları (authorization code, client credentials), HTTP/TLS ve temel kimlik konularını öğrenin.
2. 1–3 ay: PKCE, OIDC, token lifecycle, JWT signature validation ve redirect_uri güvenliğini uygulamalı olarak deneyin.
3. 3–6 ay: Mobile ve SPA uygulamalarında secure storage, token revocation, refresh token rotation ve IdP konfigürasyon yönetimi pratikleri yapın.
4. 6–12 ay: Advanced topics: continuous authorization, decentralized identity, verifiable credentials ve OAuth güvenliğini enterprise ölçekte uygulama deneyimi kazanın.