OAuth 2.1 + PKCE + DPoP 2026 yılında modern authentication’ın yeni standardı olarak yerleşti. OWASP Authentication Cheat Sheet 2025, token theft kaynaklı API abuse saldırılarının %430 arttığını gösteriyor. IETF OAuth 2.1 BCP, implicit flow ve resource owner password credentials grant’ı resmen deprecate etti. Konuyla ilişkili olarak Modern Identity Provider: Keycloak vs Auth0 vs Authentik vs Ory Karşılaştırması rehberimiz detaylı incelemeyi içerir.
OAuth 2.1: 2026 Standartlaşma ve Breaking Changes
OAuth 2.1, IETF tarafından OAuth 2.0’ın güvenlik consolidation’ı olarak hazırlanan ve 2025 sonunda RFC olarak yayınlanan revizyondur. Breaking changes: implicit flow kaldırıldı, resource owner password credentials grant kaldırıldı, PKCE tüm authorization code flow’larda zorunlu, redirect URI exact match şart, bearer token URL’de yasak. Cloudflare 2025 API Security Report: bearer token sızıntısı en yaygın 3. ihlal vektörü.
OAuth 2.1, AWS Cognito (Eylül 2024), Auth0 (Aralık 2024), Keycloak 25+ (Mart 2025) tarafından destekleniyor. Okta 2025 Q3 itibarıyla legacy implicit flow tenant’ları için 18 ay deprecation timeline duyurdu. IDC 2025 Identity Survey: kurumların yalnızca %34’ü OAuth 2.1 BCP’ye tam uyumlu.
PKCE: Authorization Code Interception Koruması
PKCE (Proof Key for Code Exchange, RFC 7636), authorization code’un mobil cihaz veya SPA’da intercept edilmesini engelleyen mekanizmadır. Client, random code_verifier (43-128 karakter) üretir; SHA256 hash’i code_challenge olarak authorization request’e ekler. Token exchange aşamasında original code_verifier sunulur; server hash karşılaştırması yapar. RFC 8252 native app, RFC 8252 SPA için zorunlu kıldı.
| Client Type | OAuth 2.0 | OAuth 2.1 | PKCE |
|---|---|---|---|
| SPA (Public) | Implicit | Auth Code + PKCE | Zorunlu |
| Mobile (Public) | Auth Code | Auth Code + PKCE | Zorunlu |
| Web App (Confidential) | Auth Code | Auth Code + PKCE | Zorunlu |
| Backend Service | Client Credentials | Client Credentials | N/A |
| Device Code | Device Code | Device Code | Önerilen |
DPoP: Sender-Constrained Token
DPoP (Demonstrating Proof of Possession, RFC 9449, Eylül 2023), bearer token’ı belirli bir public-private key çiftine bağlayan mekanizmadır. Klasik bearer token: çalan kullanır. DPoP token: çalan ek olarak private key gerektirir. Her HTTP request’te DPoP proof JWT (HTTP method + URL + timestamp + key thumbprint) ile gönderilir.
DPoP, mTLS-bound token’a alternatif olarak public client’larda (SPA, mobil) sender-constrained binding sağlar. Keycloak 24+ (Mayıs 2024) ve Auth0 (Ekim 2024) production’da DPoP destekliyor. Okta Q2 2025 itibarıyla DPoP GA. PingFederate ve ForgeRock 2026 Q1 roadmap’inde.
Refresh Token Rotation ve Reuse Detection
OAuth 2.1 BCP, public client’lar için refresh token rotation’ı (RFC 6749 Section 6 + draft-ietf-oauth-security-topics) zorunlu kılıyor. Her refresh çağrısında yeni refresh token üretilir ve eski iptal edilir; eski token tekrar kullanılırsa “token theft” tespit edilip kullanıcının tüm session’ları sonlandırılır.
Karşılaştırma: 3 Modern Authentication Pattern
| Pattern | Token Binding | Public Client | Olgunluk |
|---|---|---|---|
| Bearer (legacy) | Yok | Tam destek | Production (deprecate) |
| mTLS-bound | TLS sertifikası | Zor | Production |
| DPoP | HTTP-level proof JWT | Native destek | RFC 9449 (2023) |
| Token Binding (legacy) | TLS extension | Sınırlı | Deprecate |
| Cookie + SameSite | Browser-level | Sadece web | Production |
İlgili konu: OpenID Connect implementation rehberimizde OIDC’nin OAuth 2.1 üzerine kimlik katmanını detaylandırdık.
FAPI 2.0 ve Open Banking
FAPI (Financial-grade API) 2.0, Open Banking gibi yüksek güvenlik gerektiren senaryolarda OAuth 2.1 üzerine PAR (Pushed Authorization Request, RFC 9126), JAR (JWT-secured Authorization Request, RFC 9101), mTLS veya DPoP zorunluluğu getirir. UK Open Banking 2025, FAPI 2.0 migration takvimini 2026 Q2 olarak belirledi.
Sektörel Use Case: Fintech, Sağlık, B2B SaaS
Fintech sektöründe PSD3 ve FAPI 2.0 OAuth 2.1 + DPoP/mTLS’i şart koşuyor. Sağlık sektöründe SMART on FHIR 2.0 (HL7) OAuth 2.0’dan 2.1’e geçiş tamamladı. B2B SaaS’te SCIM 2.0 ile birlikte OAuth 2.1 kurumsal SSO standardı.
Kurumsal OAuth 2.1 Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Tüm client’ları aynı anda migrate etmeye çalışmak — 4-6 ay kesinti riski
- Legacy SDK’ların PKCE desteği olmaması — mobile SDK güncellemesi 6 ay sürebiliyor
- DPoP proof JWT’nin server saat kayması nedeniyle reddedilmesi
- Refresh token rotation’da race condition — eşzamanlı çağrılar token theft alarmı tetikliyor
- Token introspection cache’inin doğru ayarlanmaması — performans veya stale data riski
- Authorization server’ın FAPI 2.0 profili için yapılandırılmamış olması
Sonuç
OAuth 2.1 + PKCE + DPoP üçlüsü 2026’da modern API güvenliğinin temeli. Migration için sıralı yaklaşım: önce SPA + mobile için PKCE zorunlu, sonra confidential client için DPoP pilot, en son legacy entegrasyonlar. Authorization server tarafında Keycloak 24+, Auth0, Okta hızlı başlangıç sunuyor. FAPI 2.0 gerektiren regülasyon ortamlarında 12-18 aylık roadmap gerçekçi. Pilot için 1 yüksek değerli endpoint seçin, metric ölçün, sonra rollout.
Sıkça Sorulan Sorular
PKCE tüm client türleri için zorunlu mu?
OAuth 2.1 BCP’ye göre evet, tüm authorization code flow’larda PKCE zorunlu — public ve confidential client ayrımı kaldırıldı. Pre-OAuth 2.1 yapılandırılmış server’larda PKCE confidential client için opsiyoneldi; bu pratik 2025 itibarıyla deprecate.
DPoP yerine mTLS-bound token kullanılabilir mi?
Confidential client’larda evet ve hatta tercih edilebilir; client’da TLS client cert yönetimi olgun. Public client’larda (SPA, mobile) mTLS pratik değil çünkü cert yönetimi cihaza özgü; DPoP burada native çözüm.
Refresh token rotation race condition’ı nasıl yönetilir?
Authorization server’da idempotency window (5-10 saniye) tanımlanır; aynı refresh token’ın 2 paralel kullanımı birbirini tetiklemez. Auth0 ve Keycloak’ta default 30 saniye; race condition’ı gerçek token theft’ten ayırır.
OIDC ile OAuth 2.1 ilişkisi nedir?
OIDC OAuth 2.0/2.1 üzerine kimlik katmanıdır; id_token JWT ekleyerek “kim” sorusunu cevaplar. OAuth 2.1 ile OIDC 2.0 (Aralık 2024 draft) eşzamanlı evrildi; PKCE ve DPoP OIDC’de de zorunlu.
Bearer token’dan DPoP’a migration ne kadar sürer?
Tipik kurumsal migration 9-12 ay: 3 ay AS yapılandırma, 3 ay client SDK güncelleme, 3 ay paralel mode (bearer + DPoP), 3 ay bearer disable. Auth0 müşterileri için ortalama 7 ay.
Ömer ÖNAL
Mayıs 23, 2026OAuth 2.0 implicit flow hâlâ canlıda olan kurumlarda token theft riski %430 yüksek; ancak migration’a ‘tüm client’ları aynı anda yenileme’ diye başlayanlar 8 ay batık kalıyor. Doğru sıra: önce SPA + mobile için PKCE zorunlu yap, sonra confidential client için DPoP pilot, en son legacy entegrasyonlar. AS tarafında Keycloak 24+ veya Auth0 / Okta’nın DPoP desteği gerekiyor. — Ömer Önal