1. GİRİŞ

OAuth2, modern web ve mobil uygulamalarda yetkilendirmeyi standartlaştıran, esnek ve geniş kabul görmüş bir protokoldür. İlk versiyonlarından itibaren OAuth, üçüncü parti uygulamalara kullanıcı verisine kontrollü erişim sağlama ihtiyacını karşılamak üzere tasarlanmıştır. Günümüzde mikroservis mimarilerinden mobil uygulamalara, servis‑to‑servis iletişiminden API‑first ürünlere kadar geniş bir kullanım alanı bulur. Ancak "OAuth2 kullandım" demek, güvenli veya doğru şekilde kullanıldığı anlamına gelmez; protokolün doğru uygulanması güvenlik ve operasyonel sağlamlık gerektirir.

Bu konu neden bugün önemli?

• API'lerin ve üçüncü parti entegrasyonların artmasıyla yetkilendirme karmaşıklığı büyüdü.
• Identity, access management ve token tabanlı mimariler güvenlik operasyonlarının merkezinde yer alıyor.
• OAuth2, hem kullanıcı‑etkileşimli (browser/mobile) hem de machine‑to‑machine senaryoları destekleyecek esneklikteki en yaygın çözümdür.

Kimler için önemli?

• Güvenlik mühendisleri ve IAM ekipleri
• Backend geliştiriciler, platform mühendisleri ve API tasarımcıları
• Ürün yöneticileri ve üçüncü taraf entegrasyon ekipleri

Hangi problemleri çözüyor?

• Üçüncü parti uygulamalara kullanıcı verisini sağlamanın güvenli, kontrollü yolu.
• Kullanıcı parolalarını paylaşmadan servisler arası yetkilendirme.
• Kısa ömürlü token'lar ile yetki sınırlandırma ve rotasyon kolaylığı.

2. KAVRAMSAL TEMELLER

2.1 OAuth2 nedir — net tanım

OAuth2, kaynak sahibi (resource owner) adına bir istemciye (client) access token verilmesini sağlayan yetkilendirme protokolüdür. Protokolün kendisi kimlik doğrulama (authentication) çözümü değildir; kullanıcı kimliğini doğrulamak için OpenID Connect gibi üst protokoller veya ek mekanizmalar gerekir. OAuth2 dört temel rol tanımlar: Resource Owner, Client, Authorization Server ve Resource Server.

2.2 Temel terimler

• Authorization Server (AS): Client'ın yetki talebini değerlendirir, kullanıcıdan izin ister ve access/refresh token üretir.
• Resource Server (RS): Korunan kaynakları barındırır ve access token'ı doğrulayarak istekleri işler.
• Access Token: Kısa ömürlü yetki kanıtı; API çağrılarında bearer token olarak kullanılır.
• Refresh Token: Expiry sonrası yeni access token almak için kullanılan uzun ömürlü credential (her senaryoda kullanılmaz).
• Scopes: Token ile izin verilen kaynak ve eylemler seti.
• Grant Type / Flow: Yetkilendirme akışı — Authorization Code, Client Credentials, Resource Owner Password Credentials (deprecated), Implicit (deprecated), Device Authorization vb.

2.3 OAuth2'nin sınırlamaları

• Protokol kimlik doğrulamayı kapsamaz — OIDC gibi ek protokoller gerekir.
• Token yönetimi (revocation, introspection) uygulama tarafından ek mekanizmalarla desteklenmelidir.
• Özellikle mobil ve tarayıcı tabanlı uygulamalarda güvenlik nüansları vardır (PKCE, CORS, storage güvenliği).

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ, AKIŞLAR VE BİLEŞENLER

3.1 High‑level mimari

En tipik mimari, Authorization Server'ın token lifecycle'ını yönettiği, Resource Server'ların token doğrulaması yaptığı bir yapıdır. API Gateway'ler genellikle token doğrulama, rate limiting ve merkezi logging için ön katman görevi görür. Authorization Server, kullanıcı kimlik doğrulaması, consent ekranı, token issuance, revocation ve introspection endpoint'lerini sunar.

3.2 Authorization Code Flow (PKCE dahil) — Kullanıcı tabanlı en güvenli akış

1. Client, kullanıcının tarayıcısını Authorization Server'ın authorize endpoint'ine yönlendirir (scope ve redirect_uri ile).
2. Kullanıcı kimliğini doğrular, consent verir ve authorization code döner.
3. Client authorization code ile token endpoint'e giderek access token ve refresh token alır. PKCE (Proof Key for Code Exchange) modern uygulamalarda code interception riskini azaltmak için zorunludur, özellikle public clients (SPA, mobil) için.

3.3 Client Credentials Flow — Servis‑to‑servis (machine) kimlik

Client (bir servis) doğrudan Authorization Server'a kimlik bilgileri (client_id/secret veya certificate) ile başvurur ve access token alır. Bu akışta kullanıcı etkileşimi yoktur ve refresh token genelde kullanılmaz. mTLS veya JWT client assertion (RFC 7523) ile kimlik daha güvenli hale getirilebilir.

3.4 Device Authorization Flow

Cihazın tarayıcı yeteneği olmadığı senaryolarda (TV, IoT) kullanıcı başka bir cihazda (phone/browser) oturum açıp code girerek cihazı yetkilendirir. Bu akış asenkron onaylama ve uzun lived polling içerir; rate limiting ve polling interval dikkatle ele alınmalıdır.

3.5 Refresh Token, Access Token ve token lifecycles

Access token kısa ömürlü (örn. birkaç dakika–saat) olmalı, refresh token daha uzun (günler–aylar) olabilir. Refresh token'lar rotate edilerek kullanım sonrası invalidation sağlanmalıdır. Refresh token kullanımı istemci tipine göre sınırlandırılmalı (public clients için dikkatli olun).

3.6 Token introspection ve revocation

Resource Server'lar stateless JWT kullanıyorsa her istekte signature ve expiry kontrolü yaparlar. Ancak revocation ve immediate invalidation için Authorization Server'in introspection endpoint'i veya revocation endpoint'i gerekir. Ayrıca short‑lived token ve caching ile performans‑güvenlik dengesine ulaşılır.

3.7 PKCE, mTLS ve JWT assertions gibi hardening teknikleri

• PKCE: public client'larda authorization code akışını güvenli hale getirir.
• mTLS: client authentication veya token binding için kullanılabilir; certificate lifecycle yönetimi gerekir.
• JWT Client Assertion (RFC 7523): Client, kendi private key ile JWT imzalayarak token endpoint'e kimlik doğrular.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Google & Facebook — OAuth2'yi büyük çapta servis kimliklendirme için kullanma

Google ve Facebook OAuth2'yi üçüncü parti uygulamaların kullanıcı verisine erişimini düzenlemek için kullanır. Bu sağlayıcılar genellikle Authorization Code + PKCE, OpenID Connect entegrasyonu ve developer console üzerinden client registration gibi eksiksiz bir developer deneyimi sunar.

4.2 Spotify — authorization + API ecosystem örneği

Spotify, kullanıcının müzik verilerine erişimi üçüncü parti uygulamalara OAuth2 aracılığıyla açar. Scopes (playlist‑read, user‑library‑modify) ile detaylı izin kontrolü sağlar ve refresh token mekanizmasıyla uzun süreli entegrasyon imkânı verir.

4.3 Enterprise: Azure AD, Okta, Keycloak

Kurumsal dünyada Identity Provider'lar (IdP) OAuth2 ve OIDC destekler; bunlar SSO, federation, SCIM provisioning ve policy management ile entegrasyon sağlar. Azure AD B2C, Okta, Auth0 veya self‑hosted Keycloak gibi çözümler firmalarca tercih edilir.

4.4 API Gateways ve service mesh entegrasyonları

Modern platformlarda API Gateway veya sidecar/service mesh (Envoy, Istio) token validation, JWT claim mapping ve RBAC enforcement için merkezi nokta sağlar. Gateways ayrıca rate limiting, caching ve logging gibi cross‑cutting concern'ları gerçekleştirir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• OAuth2, kullanıcı parolası paylaşımını ortadan kaldırarak daha güvenli entegrasyon sunar.
• Farklı istemci tipleri (confidential/public) için esnek grant tipleri sağlar.
• Short‑lived token yaklaşımı ile token sızıntılarının etkisi azaltılabilir.
• OpenID Connect ile birlikte kullanıldığında kimlik doğrulama ve profile bilgilerinin standardize edilmesini sağlar.

Sınırlamalar

• Protokol yanlış veya eksik uygulandığında ciddi güvenlik açıkları ortaya çıkabilir (implicit flow kullanımından kaçınma gibi).
• Token revocation ve token introspection gibi konular ek altyapı gerektirir.
• Refresh token yönetimi ve client secret korunması operasyonel zorluk getirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Authorization Code + PKCE'yi public clients (SPA, mobile) için varsayılan yapın; implicit flow kullanmayın.
• Access token'ları kısa tutun, refresh token'ları rotate edin ve usage monitoring uygulayın.
• Client secrets yerine mümkünse mTLS veya JWT client assertions kullanın; secret'ları güvenli secret store'larda tutun.
• Token revocation ve introspection endpoint'lerini uygulayın; revocation işlemlerini loglayın ve alertleyin.

Performans optimizasyonu

• JWT kullanıyorsanız public key (JWKS) caching ile signature doğrulamasını hızlandırın; TTL ve rotation stratejisi belirleyin.
• Introspection çağrılarını cache'leyin fakat kısa TTL kullanın; revocation senaryolarını göz önünde bulundurun.
• Gateway seviyesinde token validation yapıp downstream servisleri yükten kurtarın.

Güvenlik

• PKCE, mTLS, client assertion gibi sertleştirme (hardening) tekniklerini uygulayın.
• Scope tanımlarını minimal ve intention revealing yapın; principle of least privilege uygulayın.
• Refresh token'ları gizli tutun; ek doğrulama (e.g. device fingerprint) ile kullanımı sınırlandırın.

Operasyonel pratikler

• Audit logging: token issuance, refresh, revocation ve failed attempts kaydedilmeli.
• Automated testing: contract testing, security regression, fuzzing ve penetration testleri rutin hale getirin.
• Developer experience: iyi dokümantasyon, SDK'lar ve example flows sağlayın.

8. SIK YAPILAN HATALAR

• Implicit flow kullanmak—tarayıcı uygulamalarında PKCE tercih edilmelidir.
• Refresh token'ları public client'larda güvenle saklamamak.
• Token revocation ve introspection eksikliği—kötüye kullanımı engelleyecek mekanizmalar olmadan risk artar.
• Scopes'ı geniş ve anlamsız tutmak—least privilege prensibini zedeler.
• JWKS veya discovery endpoint'lerini güvenli cache'lememek—public key rotation sorunlarına yol açar.

9. GELECEK TRENDLER

1. Token binding ve DPoP: Token'ların belirli bağlamlara (örn. TLS bağlantısı) bağlanması ile token replay riskleri azalacak.
2. OAuth2 for the Internet of Things: Cihaz kimlikleri, constrained devices ve asymmetric crypto ile daha fazla ön planda olacak.
3. Decentralized Identity ve Verifiable Credentials: OAuth ekosistemi ile birlikte veri sahipliği modelleri (DID, VC) entegrasyonları görülecek.
4. Automated security analysis: OAuth konfigürasyonları için CI/CD pipeline'larında otomatik uyumluluk ve risk analiz araçları yaygınlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. OAuth2 mi, OIDC mi yoksa SAML mi seçmeliyim?

   OAuth2 yetkilendirme için, OIDC ise kimlik doğrulama ve profile ihtiyaçları için uygundur. Kurumsal SSO ve legacy entegrasyonlarda SAML hala geçerli bir seçenektir. Modern web/mobil uygulamalar için OIDC + OAuth2 önerilir.

2. 2. PKCE nedir ve neden zorunlu?

   PKCE, authorization code interception saldırılarını önleyen bir mekanizmadır. Public clients (SPA, mobil) için authorization code akışı sırasında code exchange sürecini güvenli hale getirir; modern uygulamalarda kullanımı önerilir.

3. 3. Refresh token nasıl güvenle yönetilir?

   Refresh token'ları rotate edin, kullanıldığında eskisini invalid hale getirin ve suspicious usage için monitoring kurun. Public clients'ta refresh token kullanımına sınırlama getirin.

4. 4. JWT kullanmanın dezavantajları neler?

   JWT stateless doğrulama sağlar ancak revocation zorluğu, büyük token boyutları ve yanlış claim tasarımı riskler oluşturur. Short‑lived token ve introspection kombinasyonu önerilir.

5. 5. Authorization Server'ı kendimiz mi kurmalıyız yoksa managed mi kullanmalıyız?

   Managed IdP (Okta, Auth0, Azure AD) hızlı entegrasyon ve operasyonel rahatlık sağlar; self‑hosted (Keycloak) daha fazla özelleştirme ve maliyet kontrolü sunar. Seçim operasyonel kapasitenize, uyumluluk ve özelleştirme ihtiyaçlarınıza bağlıdır.

6. 6. Token revocation nasıl uygulanır?

   Revocation endpoint, denylist/blacklist, and short‑lived tokens + introspection kombinasyonu etkili yöntemlerdir. Ayrıca refresh token rotation kullanarak eski refresh token'ların geçersiz kılınması sağlanır.

7. 7. OAuth2'nin en sık görülen saldırı vektörleri nelerdir?

   Authorization code interception, token leakage via browser storage, CSRF ile consent bypass ve token replay en yaygın vektörlerdir. Bunlara karşı PKCE, secure storage, SameSite cookie ve token binding önlemleri alınmalıdır.

8. 8. OAuth2 ile API Gateway entegrasyonu nasıl olmalı?

   Gateway, token validation, scope enforcement, rate limiting ve claim mapping için ön katman olarak konumlandırılmalı. Ayrıca discovery/JWKS caching ve introspection fallback mekanizmaları gateway tarafında uygulanmalıdır.

Anahtar Kavramlar

Authorization Server

Token issuance, revocation ve introspection gibi yetkilendirme görevlerini yürüten servis.

Resource Server

Korunan API veya kaynakları barındıran ve token'ı doğrulayan servis.

PKCE

Proof Key for Code Exchange — authorization code akışını güvenli hale getiren mekanizma.

Access Token

Kısa süreli yetkilendirme belirteci; API çağrılarında bearer olarak kullanılır.

Refresh Token

Access token yenileme amacıyla kullanılan, daha uzun ömürlü credential.

Öğrenme Yol Haritası

1. 0–1 ay: OAuth2 temel kavramlarını, grant türlerini ve HTTP güvenlik temellerini öğrenin; küçük bir Authorization Code akışı implement edin.
2. 1–3 ay: PKCE, JWT, JWKS, token introspection, revocation ve refresh token rotation pratiklerini uygulayın; OIDC ile kimlik bilgilerini entegre edin.
3. 3–6 ay: mTLS, client assertion, device flow, ve token binding mekanizmaları ile servis‑to‑servis ve constrained devices senaryolarını öğrenin.
4. 6–12 ay: Production‑grade Authorization Server kurulumları (HA, clustering), federation (SAML/OIDC), SCIM provisioning ve security incident response süreçlerini olgunlaştırın.