1. Giriş

İnternet uygulamaları ve API'ler büyüdükçe kimlik doğrulama ve yetkilendirme mekanizmalarının güvenli, ölçeklenebilir ve standarda uygun olması kritik hale geldi. OAuth2, kaynak sahibi (resource owner) adına üçüncü taraf uygulamalara sınırlı erişim vermek için endüstri standardı haline gelmiş bir yetkilendirme protokolüdür. Modern mikroservisler, mobil uygulamalar, SPA'lar ve API-first servisler için OAuth2 temel bir yapı taşıdır.

Bu makale, "OAuth2 Authentication Kurulumu" konusunu teknik bir mühendis gözlüğüyle ele alır: kavramsal temeller, mimari seçenekler, uygulama adımları (authorization server kurulumu, resource server konfigürasyonu, client registration), güvenlik incelemeleri, izleme ve üretime alma stratejileri. Hedef, güvenli, yönetilebilir ve standartlara uygun bir OAuth2 altyapısı kurmanıza yardımcı olmaktır.

Neden bugün önemli?

• API ekonomisiyle birlikte servisler arası yetkilendirme ve üçüncü taraf entegrasyonlar arttı.
• Mobil / web uygulamalar için güvenli token tabanlı oturum yönetimi gerekli.
• Regülasyonlar ve veri gizliliği gereksinimleri doğru yetkilendirmeyi zorunlu kılıyor.

Kimler için önemli?

Backend mühendisleri, güvenlik mühendisleri, platform ekipleri, API geliştiricileri ve mobil/SPA ekipleri için kritik bir konudur.

Hangi problemleri çözüyor?

Geleneksel paylaşılmış kimlik bilgisi kullanımının (username/password in apps) yerine yetkilendirme token'ları ile güvenli ve revokable erişim sağlanır; servisler arası least-privilege erişim ve merkezi politikalar uygulanabilir.

2. Kavramsal Temeller

OAuth2'in temel kavramlarını ve terminolojisini açıklayalım.

Temel Kavramlar

• Resource Owner (RO): Korunan kaynağın sahibi (genellikle kullanıcı).
• Client: Kaynağa erişim isteyen uygulama (web app, mobile app, server-side app).
• Authorization Server (AS): Kimlik doğrulama ve token çıkarma işlevini yürüten sunucu (ör. IdentityServer, Keycloak).
• Resource Server (RS): Korunan API; erişim token'larını doğrulayıp istekleri servis eder.
• Access Token: Kısa ömürlü yetkilendirme kanıtı (Bearer token).
• Refresh Token: Yeni access token almak için kullanılan daha uzun ömürlü token (genellikle confidential clients için).

Grant Türleri (Flows)

• Authorization Code: Sunucu tarafı web uygulamaları için güvenli; PKCE ile SPA/mobile için önerilir.
• Implicit: Eskimiş; artık önerilmiyor (token doğrudan tarayıcıya verilirdi).
• Client Credentials: Service-to-service (machine) auth için kullanılır.
• Resource Owner Password Credentials (ROPC): Kullanıcı adı/şifre ile direkt token almak; nadiren ve dikkatle kullanılmalı.
• PKCE (Proof Key for Code Exchange): Authorization Code flow'u güvenli hale getirmek için code exchange doğrulama tekniği, mobile/SPA'larda zorunlu kabul edilir.

Mimari Bileşenler

İyi tasarlanmış bir OAuth2 çözümü şu bileşenleri içerir: Authorization Server (kullanıcı doğrulama, token endpoint), Resource Server'lar (API'ler), Client Registry (kayıtlı uygulamalar ve redirect URI'leri), Token Storage/Revocation, Consent UI (kullanıcı onayı), ve Audit/Logging altyapısı.

3. Nasıl Çalışır? (Teknik Mimari ve Veri Akışı)

OAuth2'in teknik işleyişini ayrıntılı olarak ele alalım.

Sistem Mimarisi

Tipik akışta kullanıcı (RO) client uygulamaya giriş yapmak ister. Client, kullanıcıyı AS'nin authorization endpoint'ine yönlendirir (authorization code flow). Kullanıcı kimlik doğrulamasını ve gerekli izinleri (consent) verdikten sonra AS, client'a authorization code döner. Client bu kodu token endpoint'e göndererek access ve refresh token alır. Client, access token ile resource server'a istek gönderir; RS token'ı doğrulayıp kaynağı sunar.

Adım Adım Veri Akışı (Authorization Code + PKCE örneği)

1. Client oluşturur: code_verifier ve code_challenge (S256).
2. Client, browser'ı AS /authorize endpoint'e yönlendirir (client_id, redirect_uri, code_challenge).
3. Kullanıcı kimlik doğrulaması gerçekleştirilir; AS redirect_uri'ye authorization code ile döner.
4. Client token endpoint'e authorization code ve code_verifier gönderir.
5. AS code_verifier ile code_challenge doğrular; başarılıysa access token (ve opsiyonel refresh token) döner.
6. Client, access token ile Resource Server'a istek yapar. RS, token'ı doğrulayıp istekleri işler.

Token Tipleri ve İçerikleri

• Opaque token: AS tarafından saklanan ve RS tarafından introspection ile doğrulanan token.
• JWT (JSON Web Token): RS tarafında public key ile offline doğrulanabilen self-contained token; claims içerir (exp, scope, aud, iss, sub).

Token Doğrulama Yöntemleri

• Introspection endpoint: RS token'ı AS'ye gönderir, token'ın geçerliliği ve meta bilgisi döner.
• JWT signature verification: RS, AS'in JWKS URI'sinden public key alır ve token'ı doğrular (offline, düşük latency).

4. Gerçek Dünya Kullanımları

OAuth2, birçok büyük kuruluş ve senaryoda yaygın olarak kullanılır. Aşağıda örnek uygulamalar:

Netflix / Amazon / Uber örnekleri

Bu şirketler, farklı servisler ve üçüncü parti uygulamalar arasında güvenli yetkilendirme sağlamak için OAuth2 benzeri yaklaşımlar kullanır. Örneğin: mobil uygulamalar için Authorization Code + PKCE; servisler arası iletişim için Client Credentials; kullanıcı izinleri için merkezi Authorization Server ve politikaların uygulanması.

OpenAI ve API sağlayıcıları

API anahtarlarının yerine token tabanlı erişim (scoped tokens) ve rate limiting ile birlikte OAuth2-benzeri akışlar veya OAuth token exchange desenleri kullanılır.

Stripe ve finansal uygulamalar

Third-party uygulamaların kullanıcı hesaplarına sınırlı erişim ihtiyacı için OAuth2 tabanlı bağlantı (connect) modelleri güvenli ve izlenebilir erişim sağlar.

5. Avantajlar ve Sınırlamalar

Avantajlar

• Standardizasyon: Birçok kütüphane ve sağlayıcı OAuth2'i destekler; interoperabilite kolaydır.
• Scoped access: Token'lar belirli scope'larla sınırlanabilir; least-privilege uygulanabilir.
• Token revoke / rotation: Refresh token ve token revocation mekanizmaları ile erişim kesilebilir.

Sınırlamalar / Zorluklar

• Operasyonel karmaşıklık: Authorization Server yönetimi, key rotation, introspection endpoint'leri ve revocation handle etme ek çaba gerektirir.
• Token yönetimi: Refresh token güvenliği, token theft riski ve token replay saldırıları dikkate alınmalıdır.
• Complicated flows for SPA/mobile: PKCE ve secure storage gereksinimleri uygunsuz uygulanırsa güvenlik açıkları oluşur.

6. Alternatifler ve Karşılaştırma

Aşağıdaki tablo OAuth2 ile bazı diğer yaklaşımları karşılaştırır:

7. En İyi Pratikler

Aşağıda OAuth2 üretime alırken dikkat edilmesi gereken anahtar uygulamalar yer almaktadır.

Production kullanımı

• Authorization Server için olgun bir çözüm kullanın: Keycloak, Auth0, IdentityServer veya cloud provider çözümleri (Azure AD, AWS Cognito) tercih edin.
• Redirect URI'lerini kesin olarak kayıt altında tutun; wildcard redirect kullanımından kaçının.
• Client registration ve secret management (confidential clients için) süreçlerini merkezi ve güvenli KMS/Vault ile yönetin.

Güvenlik

• Authorization Code + PKCE kullanın; implicit flow kullanmayın.
• Access token'ları kısa ömürlü, refresh token'ları sınırlı scope ve revocation yeteneği ile kullanın.
• JWT kullanıyorsanız claim'leri minimal tutun, token boyutunu ve cardinality'i yönetin; public key (JWKS) rotasyonunu planlayın.
• TLS zorunlu olsun, HSTS ve güvenli cookie ayarları (HttpOnly, Secure, SameSite) uygulanmalı.

Operasyon & İzleme

• Audit loglama: token issuance, revocation, failed attempts ve consent event'lerini kaydedin.
• Rate limit: token endpoint ve authorization endpoint için brute-force/abuse koruması uygulayın.
• Alerting: anormal token issuance artışı, repeated failed login ve revocation spike'ları için alert kurun.

Key Management

• Private key'leri HSM veya managed KMS içinde saklayın; per-client veya per-environment key rotation stratejileri geliştirin.
• JWKS endpoint ile public key dağıtımını yönetin; key rollover ve backward compatibility'yi test edin.

8. Sık Yapılan Hatalar

• Access token'ları uzun ömürlü yapmak — token theft durumunda etkisi büyük olur.
• Redirect URI validation'ını gevşek tutmak; open redirect veya token leakage riskleri doğurur.
• PKCE implementasyonunu atlamak — SPA/mobile uygulamalarda kritik güvenlik açığı oluşturur.
• Token revocation mekanizması kurmamak; refresh token'ların iptal edilememesi güvenlik zafiyetidir.
• JWT'leri doğrulamadan kabul etmek (iss/aud/exp kontrollerini atlamak).

9. Gelecek Trendler

• Token exchange ve continuous access evaluation: Token'ların yaşam döngüsünde dinamik policy değerlendirmeleri artacak.
• Decentralized identity (DID): Self-sovereign identity yaklaşımları ve Verifiable Credentials OAuth/UMA ile entegre olacak.
• mTLS + OAuth kombinasyonları: Machine-to-machine güvenliği için daha yaygın kullanılacak.
• Fine-grained authorization: RABC ve ABAC modellerinin token claim'leri ile kombinasyonu çoğalacak.

Ek Bölümler

Sık Sorulan Sorular (FAQ)

1. S: OAuth2 ile JWT arasındaki fark nedir?

   C: OAuth2 bir yetkilendirme protokolüdür; JWT token formatı ise access token olarak kullanılabilir. OAuth2 token'ları opaque veya JWT olabilir.

2. S: SPA'da hangi flow kullanılmalı?

   C: Authorization Code + PKCE önerilir. Access token'ları tarayıcı storage'ta güvenli şekilde tutmak için HttpOnly cookie ve backend-for-frontend (BFF) patterni tercih edilmelidir.

3. S: Refresh token'ları SPA'da kullanmalı mıyım?

   C: SPA için refresh token kullanımı risklidir; BFF veya rotating refresh token + short expiry kombinasyonları daha güvenlidir.

4. S: JWT'leri nerede doğrulamalıyım?

   C: Resource Server üzerinde offline olarak JWKS public key ile doğrulama yapın. Ayrıca iss, aud, exp kontrollerini uygulayın.

5. S: Token revocation nasıl çalışır?

   C: Authorization Server revoke endpoint sağlar; RS introspection ile token durumunu kontrol edebilir. Ayrıca blacklist/whitelist store'ları kullanılabilir.

6. S: Authorization Server olarak ne kullanmalıyım?

   C: Açık kaynak için Keycloak veya IdentityServer; managed hizmetlerde Azure AD, Auth0 veya AWS Cognito değerlendirilebilir.

7. S: Scope nasıl tasarlanmalı?

   C: Scope'ları küçük, anlamlı ve kaynak bazlı tutun. Principal/role bazlı geniş yetkilerden kaçının; fine-grained permission modelini tercih edin.

8. S: OAuth2 kurulumunu nasıl test etmeliyim?

   C: Unit/integration testler, security testleri (redirect validation, token theft simülasyonları), ve end-to-end flows (authorization code + PKCE) ile test edin.

Anahtar Kavramlar

Authorization Code

AS tarafından verilen kısa ömürlü kod; token almak için kullanılır.

PKCE

Code exchange sırasında code_verifier ile code_challenge doğrulaması sağlayan mekanizma.

Introspection

Opaque token'ların validity ve meta verilerini sorgulama işlemi.

JWKS

JSON Web Key Set — public key'lerin yayınlandığı endpoint; JWT signature doğrulama için kullanılır.

Öğrenme Yol Haritası

OAuth2 uzmanlığına ulaşmak için önerilen adımlar:

1. Temel Kavramlar (1-2 hafta): OAuth2 grant türleri, JWT, PKCE, scopes ve token lifecycle öğrenin.
2. Authorization Server kurulumu (2-3 hafta): Keycloak veya IdentityServer ile basit bir AS kurun; client registration ve redirect URI konfig.
3. Resource Server entegrasyonu (1-2 hafta): API üzerinde JWT doğrulama veya introspection implementasyonu yapın.
4. Güvenlik hardening (2-3 hafta): PKCE, HTTPS, key rotation, token revoke ve audit logları kurun.
5. Production readiness (sürekli): scaling, HA, monitoring, incident response ve compliance testleri yapın.

Pratik uygulama olarak küçük bir uygulama geliştirip: Authorization Server, bir SPA veya server-side client, ve bir Resource Server ile end-to-end akışı test edin. PKCE, JWT doğrulama ve token revocation senaryolarını deneyin.