OAuth 2.1 ve OpenID Connect, 2026 itibarıyla modern kimlik doğrulama mimarisinin omurgasıdır; IETF’in 2025 sonunda RFC 9700 olarak yayımladığı OAuth 2.1, yıllardır birikmiş BCP belgelerini tek standartta birleştirerek protokol düzeyinde güvenliği yükseltir. Okta’nın State of Identity 2026 raporuna göre kurumsal kimlik ihlallerinin %29’u OAuth 2.0 yanlış yapılandırmalarından kaynaklanırken, Microsoft Identity Threat Trends 2026 verileri implicit flow saldırılarının kurumsal token sızıntılarının %18’ini oluşturduğunu gösterir. Auth0 Developer Report 2026’ya göre dünya genelinde 2,4 milyondan fazla uygulama OAuth 2.1 ve OpenID Connect (OIDC) tabanlı federasyon kullanırken, GitHub OAuth App ekosisteminde PKCE adopsiyonu son 12 ayda %43’ten %88’e fırladı. Bu rehber; OAuth 2.0 ile 2.1 arasındaki kırılma noktalarını, OIDC katmanının kimlik doğrulama rolünü, akış seçim kriterlerini, token yönetim disiplinini, FAPI 2.0 finansal profilini ve mobil/SPA güvenlik desenlerini 2026 standartları ışığında ele alır.
Yetkilendirme (authorization) ile kimlik doğrulama (authentication) farkını net ayırmak, modern kimlik mimarisinin başlangıç noktasıdır. OAuth 2.1 “bu istemci o kaynağa erişebilir” sorusunu cevaplarken, OIDC “bu kullanıcı kim” sorusuna ID Token üzerinden cevap verir. İki katmanın birlikte konuşlandırılması, SSO, federasyon, step-up authentication ve denetlenebilir audit log mimarisinin temelini oluşturur. Bu yazıda ayrıca OWASP API Security Top 10 2025 listesindeki kimlik kaynaklı zafiyetleri ve 2026’da öne çıkan DPoP, PAR, Rich Authorization Requests (RAR) gibi modern OAuth eklentilerini de inceleyeceğiz.
OAuth 2.0 ve OAuth 2.1 Arasındaki Kırılma Noktaları
OAuth 2.1, OAuth 2.0’a yeni özellik eklemekten ziyade onun çevresinde 8 yıl boyunca yayımlanan BCP (Best Current Practice) ve Security Topics belgelerini tek konsolide standartta birleştirir. IETF OAuth 2.1 taslağı bu konsolidasyonun resmi referansıdır. Aşağıdaki tablo, OAuth 2.0 ile 2.1 arasındaki temel kırılma noktalarını özetler.
| Konu | OAuth 2.0 | OAuth 2.1 | Etki |
|---|---|---|---|
| PKCE | Yalnız public client önerilir | Tüm Authorization Code akışları için zorunlu | Authorization code intercept saldırısı kapatılır |
| Implicit Flow | Mevcut, deprecated | Kaldırıldı | Access token URL fragment’inde dönmez |
| ROPC (Password Grant) | Mevcut | Kaldırıldı | Kullanıcı şifresi client’a verilemez |
| Redirect URI Matching | Substring/pattern | Sadece exact match | Open redirect saldırıları bloklanır |
| Refresh Token | İsteğe bağlı rotation | Public client için zorunlu rotation | Token reuse detection mümkün olur |
| Bearer Token Konumu | Header, body, URL query izinli | URL query yasak | Log/proxy üzerinden sızıntı önlenir |
| State Parametresi | Önerilir | Zorunlu (CSRF için) | State binding saldırıları azalır |
Bu kırılmaların pratik anlamı şudur: implicit flow kullanan eski SPA’lar Authorization Code + PKCE’ye taşınmadıkça OAuth 2.1 uyumlu IdP’ler tarafından reddedilir; ROPC üzerinden mobil uygulamalarda saklanan kullanıcı şifreleri yeniden mimarileştirilmek zorundadır. Okta’nın 2026 transition raporuna göre kurumsal müşterilerin %71’i bu iki konuyu altı ay içinde tamamlamış durumdadır.
OpenID Connect: Yetkilendirmeye Eklenen Kimlik Katmanı
OpenID Connect, OAuth 2.1 üzerine “kullanıcı kimdir” sorusunu cevaplayan ince bir kimlik katmanı ekler. Resmi referans için OpenID Foundation spesifikasyonları birincil kaynak niteliğindedir. OIDC üç temel yapıyı standartlaştırır: ID Token (JWT formatında, kullanıcı bilgisini taşıyan), UserInfo endpoint (ek claim’leri sağlayan REST endpoint) ve Discovery dokümanı (.well-known/openid-configuration URL’sinde IdP yetkinliklerini ve endpoint’leri yayınlayan).
- ID Token doğrulama zinciri: İmza (RS256/ES256),
iss,aud,exp,iat,nonceveazpkontrolleri tamamlanmadan ID Token kabul edilmemelidir. - UserInfo endpoint: Access token ile çağrılır ve scope’a göre profile, email, address, phone claim setlerini döner.
- OIDC Discovery: Statik konfigürasyondan vazgeçilip dinamik metadata kullanılır;
jwks_uriüzerinden anahtarlar otomatik rotasyona açılır. - OIDC Federation 1.0: 2026’da yayımlanan final sürüm, çoklu IdP arasında ortak güven zinciri tanımlar; eIDAS 2.0 ile uyumlu Avrupa kurumları için kritiktir.
- FAPI 2.0 profili: Yüksek güvenlikli finans senaryolarında OIDC üzerine ek kısıtlamalar getirir.
OIDC’nin sağladığı kritik fayda, federasyon ve SSO senaryolarında IdP’nin çıkardığı ID Token’a tüm sistemlerin güvenebilmesidir. Böylece her uygulamada ayrı oturum yönetimi yerine merkezi bir kimlik kaynağından gelen JWT işlenir.
Grant Type Karşılaştırması: Hangi Akış Hangi Senaryo İçin?
OAuth 2.1’de geriye kalan üç ana grant type — Authorization Code (PKCE ile), Client Credentials ve Device Authorization — farklı senaryolara yönelir. Aşağıdaki tablo, üç akışın yan yana karşılaştırmasını sunar.
| Özellik | Authorization Code + PKCE | Client Credentials | Device Authorization |
|---|---|---|---|
| Kullanıcı katılımı | Var (browser ile) | Yok (M2M) | Var (cihaz kodu girişiyle) |
| Tipik kullanım | Web, SPA, mobil | Backend-to-API, cron job | TV, IoT, smart speaker |
| ID Token döner mi? | Evet (openid scope ile) | Hayır | Hayır (genellikle) |
| Refresh Token | Evet | Yok (yeniden auth) | Evet |
| PKCE | Zorunlu | Geçerli değil | Geçerli değil |
| Güvenlik profili | Yüksek | Çok yüksek (mTLS önerilir) | Orta (kullanıcı kodu side channel’a açık) |
| OWASP API risk | BOLA, BFLA | Geniş scope | Phishing-by-QR |
Backend-to-API entegrasyonlarında Client Credentials akışı, mTLS sertifika bağlı access token ile birleştirildiğinde FAPI 2.0 baseline gerekliliklerini karşılar. Mobil uygulamalar için RFC 8252 (OAuth for Native Apps) sistem tarayıcısı kullanımını ve AppAuth kütüphanesini referans alır.
PKCE Mekaniği: Authorization Code Intercept Saldırısına Karşı Savunma
Proof Key for Code Exchange (PKCE), RFC 7636 ile tanımlanır ve OAuth 2.1’de tüm Authorization Code akışları için zorunlu hâle gelmiştir. PKCE, client’ın authorization request gönderirken bir code_verifier üretip onun SHA-256 hash’i olan code_challenge‘ı yetkilendirme sunucusuna ilettiği bir meydan okuma-cevap protokolüdür. Token endpoint çağrısında orijinal code_verifier doğrulanır; eşleşmezse token verilmez.
- Client, kriptografik olarak rastgele
code_verifier(43-128 karakter) üretir. code_challenge = BASE64URL(SHA256(code_verifier))hesaplanır.- Authorization request’e
code_challengevecode_challenge_method=S256eklenir. - Kullanıcı kimlik doğrulamadan sonra IdP, authorization code’u redirect_uri’ye gönderir.
- Client, token endpoint’e
authorization_codeve orijinalcode_verifier‘ı POST eder. - IdP, gelen
code_verifier‘ın hash’inin saklanancode_challengeile eşleştiğini doğrular ve access/ID/refresh token döner.
Bu mekanizma, mobilde özel URL şemaları üzerinden gerçekleşebilen “authorization code intercept” saldırısını etkisizleştirir: saldırgan code’u yakalasa bile code_verifier‘a sahip olmadığı için token alamaz. OWASP API Security Top 10 2025 listesinde API2:2023 Broken Authentication kategorisi altında PKCE eksikliği en sık tespit edilen zafiyetlerden biridir.
Token Türleri ve Yaşam Döngüsü
OAuth 2.1 ve OIDC ekosisteminde üç farklı token tipi rol alır: access token, refresh token ve ID Token. Her birinin ömrü, formatı ve doğrulama disiplini farklıdır. NIST SP 800-63C 2026 revizyonu yüksek güvenli senaryolar için access token ömrünü 15 dakika ve refresh token ömrünü rotation ile 24 saatle sınırlar.
| Token | Amaç | Format | Tipik ömür | Doğrulama yeri | İptal |
|---|---|---|---|---|---|
| Access Token | API’ye erişim | JWT veya opaque | 5-15 dk | Resource server | JWT: zor / Opaque: introspection |
| Refresh Token | Yeni access token almak | Opaque (genellikle) | 1-24 saat (rotation) | Yetkilendirme sunucusu | Rotation ile reuse detection |
| ID Token | Kullanıcı kimliği bilgisi | JWT (zorunlu) | 5-60 dk | Client | Tek seferlik, oturumda saklanmaz |
| DPoP-bound Token | Cihaza bağlı access | JWT + DPoP proof | 5-15 dk | Resource server | Anahtar değişimiyle |
| mTLS-bound Token | Sertifika bağlı access | JWT + cnf claim | Saatler | Resource server | Sertifika revocation |
Stateless mikroservis mimarileri JWT erişim token’larını tercih ederken, anlık iptal gereksiniminin yüksek olduğu senaryolarda opaque token + introspection tercih edilir. Bu seçim, bu sitedeki API Güvenliği: OWASP API Top 10 2026 Pratik Uygulama yazısında detaylandırılan token doğrulama kalıplarıyla doğrudan ilişkilidir.
OIDC Discovery ve JWKS: Anahtar Rotasyonunun Otomatikleştirilmesi
OIDC Discovery, IdP’nin yetkinliklerini ve endpoint URL’lerini standart bir JSON dokümanda yayınlamasını sağlar. Client’lar {issuer}/.well-known/openid-configuration üzerinden bu bilgiyi alır ve jwks_uri aracılığıyla imza doğrulama için açık anahtarlara erişir. JWKS (JSON Web Key Set) endpoint’i, IdP’nin aktif imza anahtarlarını liste hâlinde döner ve kid (key ID) ile her ID Token’ı doğru anahtarla eşleştirmeyi mümkün kılar.
JWKS endpoint cache’lemesi, doğrulama performansını ciddi şekilde etkiler. Çok agresif cache (>24h) anahtar rotasyonunu kaçırmaya, çok kısa cache (<5dk) IdP üzerinde gereksiz yüke yol açar. Önerilen kalıp: cache TTL 1 saat, ancak kid bulunamadığında forceful refresh tetiklemek. Bu yaklaşım, anahtar rotasyonunun sıfır kesintiyle gerçekleşmesini sağlar.
- Pre-flight check: Discovery metadata’sını uygulamayı ayağa kaldırırken bir kez okumak, runtime sürprizleri azaltır.
- Algoritma whitelist: RS256, ES256, PS256 izin verilenler;
noneveHS256public client’ta yasak. - Issuer pinning: Discovery’den gelen
issuer, client config’deki ile bit-bit eşleşmelidir. - Anahtar rollover: Yeni
kid‘in JWKS’e eklenmesinden eski anahtarın kaldırılmasına kadar overlap penceresi en az 24 saat olmalı.
Refresh Token Rotation ve Token Reuse Detection
OAuth 2.1, public client’lar için refresh token rotation’ı zorunlu kılar: her refresh_token tek kullanımlıktır ve token endpoint cevabında yeni bir refresh token döner. Eski refresh token’ın ikinci kez kullanılması “token reuse” olarak algılanır ve IdP, ilgili kullanıcının tüm refresh token soyunu iptal eder. Bu mekanizma, refresh token sızıntısının etkisini hızlı tespit ve geniş çaplı invalidation ile sınırlar.
| Aşama | Client davranışı | IdP davranışı | Güvenlik sonucu |
|---|---|---|---|
| İlk token alımı | Auth code + PKCE ile RT-1 alınır | RT-1 üretilir, kaydedilir | Token chain başlatılır |
| Normal yenileme | RT-1 ile yenileme, RT-2 döner | RT-1 invalidate, RT-2 aktif | Sürekli rotation |
| Sızıntı + meşru kullanım | Saldırgan RT-1 dener, sonra client RT-2 dener | RT-1 zaten kullanılmış → tüm chain iptal | Reuse detection tetiklenir |
| İptal sonrası | Client login akışına yönlendirilir | Yeni session, yeni chain | Kullanıcı tekrar onaylar |
| Audit | Logout event’ı raporlanır | SIEM’e güvenlik olayı | İhlal görünür |
Reuse detection mekanizması doğru kurulduğunda, sızdırılmış refresh token’la yapılan bir tek talep tüm token chain’in iptaline yol açar. Bu, DevSecOps: Shift-Left Güvenlik Protokolleri ve CI/CD Entegrasyonu rehberinde tanımlanan “blast radius minimization” prensibinin kimlik katmanındaki karşılığıdır.
OIDC Scopes ve Claims: En Az Ayrıcalık İlkesi
OIDC scope’ları kullanıcının onayladığı yetki kümesini ve dönecek claim setini belirler. Tasarım disiplini, en az ayrıcalık ilkesinin somut uygulama noktasıdır. Aşağıdaki tablo OIDC standart scope’larını ve dönen claim’leri özetler.
| Scope | Anlam | Dönen Claim’ler | Hassasiyet | UX etkisi |
|---|---|---|---|---|
| openid | OIDC etkin (zorunlu) | sub, iss, aud, exp, iat | Düşük | Onay ekranında “kimliği doğrula” |
| profile | Profil bilgisi | name, family_name, given_name, picture, locale | Orta | “Profilinizi görüntüle” |
| E-posta | email, email_verified | Orta | “E-posta adresinizi görüntüle” | |
| phone | Telefon | phone_number, phone_number_verified | Orta-Yüksek | Açık onay gerekir |
| address | Adres | address (structured) | Yüksek | Açık onay, KVKK/GDPR kaydı |
| offline_access | Refresh token talep et | — | Yüksek | “Uygulamayı çevrimdışı kullanabilir” |
Kurumsal API’lerde standart scope’ların yanı sıra resource:eylem formatında özel scope’lar (örneğin orders:read, invoices:write, admin:billing) tanımlanmalıdır. Auth0 blog ve Okta blog bu konuda 2026’da yayımlanmış çok sayıda örnek mimari sunar.
FAPI 2.0: Yüksek Güvenlikli Finansal Profil
Financial-grade API (FAPI) 2.0 Baseline ve Advanced profilleri, açık bankacılık ve PSD3 senaryoları için OAuth 2.1 ve OIDC üzerine ek kısıtlamalar getirir. FAPI 2.0 baseline spesifikasyonu resmi referanstır. Aşağıdaki tablo, FAPI 2.0 ile standart OAuth 2.1 arasındaki farkları özetler.
| Konu | OAuth 2.1 Standart | FAPI 2.0 Baseline | FAPI 2.0 Advanced |
|---|---|---|---|
| Client Auth | Secret veya PKCE | private_key_jwt veya mTLS | mTLS zorunlu |
| Token Binding | Bearer (önerilir DPoP) | Sender-constrained (mTLS veya DPoP zorunlu) | mTLS zorunlu |
| PAR | İsteğe bağlı | Zorunlu | Zorunlu |
| JARM | İsteğe bağlı | İsteğe bağlı | Zorunlu |
| İmza algoritması | RS256+ | PS256 / ES256 | PS256 / ES256 |
| Request Object | İsteğe bağlı | İsteğe bağlı | İmzalı zorunlu |
EBA’nın 2026 PSD3 hazırlık raporundaki bir vakaya göre Avrupa’nın ilk on bankasından biri 2025’te açık bankacılık API’lerini FAPI 2.0 Baseline’a yükseltti; PAR + mTLS-bound token + DPoP kombinasyonu AS-TPP arası token tekrar saldırılarını sıfıra indirdi ve SCA maliyetlerini %22 azalttı. Bu profil özellikle Fintech Ödeme Sistemleri Entegrasyonu mimarisi için referans niteliğindedir.
Mobil ve SPA İçin Güvenlik Desenleri
Public client kategorisindeki mobil ve SPA uygulamalar, client secret saklayamadıklarından OAuth 2.1 ve OIDC entegrasyonunda kendine özgü güvenlik desenleri uygular. Aşağıdaki tablo, üç ana public client tipi için önerilen güvenlik yapısını karşılaştırır.
| Konu | SPA (browser) | iOS Native | Android Native |
|---|---|---|---|
| Token saklama | Memory + httpOnly cookie (BFF) | Keychain | EncryptedSharedPreferences / Keystore |
| Redirect URI | HTTPS exact match | ASWebAuthSession + Universal Link | Custom Tab + App Link |
| DPoP | Önerilir | Önerilir | Önerilir |
| Token rotation | Zorunlu | Zorunlu | Zorunlu |
| Refresh token TTL | Saatler (BFF arkasında uzun) | 24 saat | 24 saat |
| Logout | RP-initiated + back-channel | RP-initiated | RP-initiated |
| Anti-CSRF | state + nonce + SameSite | state + PKCE | state + PKCE |
SPA tarafında BFF (Backend for Frontend) deseni, refresh token’ı tarayıcıya değil arkadaki güvenli servise emanet ederek XSS yüzeyini ciddi şekilde küçültür. Mobil tarafta sistem tarayıcısı (iOS ASWebAuthSession / Android Custom Tabs) kullanımı, WebView ile OAuth akışı yapma gibi anti-patterns’i ortadan kaldırır. Bu konular Mobil Deep Link ve App Link rehberinde mobil mimari açısından da işlenir.
Modern OAuth Eklentileri: DPoP, PAR, RAR ve mTLS
OAuth 2.1, çekirdek protokolün etrafına gelişen bir eklenti ekosistemiyle birlikte kullanılır. Bu eklentilerin temel motivasyonu, bearer token’ı “sahibinden bağımsız” olmaktan çıkarıp sender-constrained hale getirmek ve authorization request’i daha güvenli kanallar üzerinden taşımaktır.
- DPoP (Demonstrating Proof-of-Possession, RFC 9449): Public client’lar için access ve refresh token’ı cihaza bağlı bir imzalı proof JWT’siyle tamamlar; çalınan bearer token, DPoP anahtarı olmadan kullanılamaz.
- PAR (Pushed Authorization Request, RFC 9126): Authorization request’i query parametresinde değil, önceden token endpoint’e POST ederek
request_urireferansıyla başlatır; loglardan parametre sızıntısını engeller. - RAR (Rich Authorization Requests, RFC 9396): Scope yerine yapısal “authorization_details” JSON nesnesi kullanır; özellikle finansal işlemde “şu IBAN’a 1000 EUR transfer” gibi parametreleri token’a bağlar.
- mTLS Client Authentication (RFC 8705): Sertifika bağlı access token üretir; resource server token’ın TLS sertifikasıyla eşleştiğini doğrular.
- JARM (JWT Secured Authorization Response): Authorization response’unu imzalı JWT olarak döner; tamper detection sağlar.
- Step-up authentication:
acr_valuesparametresiyle bağlama özel güçlü kimlik doğrulama talep eder; hassas işlemde MFA tetikler.
Bu eklentilerin ortak hedefi, “token = erişim” eşitliğini “token + bağlam + sahiplik = erişim” eşitliğine taşımaktır. Zero Trust Mimarisi yazısında ele alınan “her istek doğrulanır” prensibinin kimlik katmanındaki somut uygulamasıdır.
Sık Sorulan Sorular
OAuth 2.0’dan 2.1’e geçiş ne kadar zor ve hangi sırayla yapılmalı?
Çoğu IdP (Okta, Auth0, Microsoft Entra ID, Keycloak, Ping Identity) PKCE ve refresh token rotation’ı zaten varsayılan olarak destekler; bu nedenle ana iş istemci tarafında yoğunlaşır. Önerilen sıralama: (1) implicit flow kullanan SPA’ları Auth Code + PKCE’ye taşı, (2) ROPC üzerinden çalışan mobil entegrasyonları yeniden mimarileştir, (3) wildcard redirect URI’ları exact match’e dönüştür, (4) refresh token rotation’ı etkinleştir ve token reuse detection alarmlarını SIEM’e bağla, (5) opsiyonel olarak DPoP ve PAR ekle. Kapsamlı bir kurumsal uygulamada genellikle 2-3 sprint’te geçiş tamamlanır; FAPI 2.0 gerektiren finansal kurumlarda süre 3-6 aya uzayabilir.
JWT mi opaque access token mu kullanmalıyım?
JWT erişim token’ları stateless doğrulama ve mikroservis mimarileri için uygundur: kaynak sunucu IdP’ye çağrı yapmadan imzayı yerel olarak kontrol eder ve exp, aud, scope claim’lerine göre yetki kararı verir. Dezavantajı anlık iptaldir: imzalı JWT’yi süresi dolana kadar geri çağıramazsınız. Opaque token (referans token) ile her doğrulama IdP introspection endpoint’ine bir çağrı içerir; performans bedeli vardır ama iptal anlıktır. Pratik kalıp: dış API’ler için kısa ömürlü JWT + DPoP, çok hassas işlemler veya iç M2M için opaque + introspection.
PKCE backend tabanlı confidential client’ta da gerekli mi?
Evet. OAuth 2.1 PKCE’yi confidential client’lar dahil tüm Authorization Code akışlarında zorunlu kılar. Backend client_secret saklasa bile PKCE, authorization code intercept saldırılarına karşı ek bir savunma katmanı sağlar ve tüm istemci tipleri için tek tip davranış oluşturur. Pratikte modern IdP’ler (Okta, Auth0, Entra ID 2026 sürümleri) PKCE parametreleri eksikse hatayla yanıt verir; bu nedenle entegrasyon başında PKCE’yi standart davranış olarak benimsemek hem uyumluluk hem güvenlik açısından doğru karardır.
Güvenli logout nasıl uygulanır?
İki kanal birden desteklenmelidir. RP-Initiated Logout (OIDC RP-Initiated Logout 1.0), kullanıcı tarafından tetiklenen tek tıkla çıkışı sağlar; client IdP’nin end_session_endpoint‘ine id_token_hint ve post_logout_redirect_uri ile yönlendirir. Back-Channel Logout, IdP’nin tüm RP’lere imzalı LogoutToken POST etmesiyle başka bir uygulamada başlayan logout’un tüm SSO oturumlarında etkili olmasını sağlar. Üretimde her iki kanalın ve session iframe ya da Continuous Access Evaluation gibi tamamlayıcı yapıların birlikte kullanılması en sağlam yaklaşımdır.
OAuth 2.1 ile OIDC’nin farkı tam olarak nedir, biri diğerinin yerine geçer mi?
İki katman farklı problemleri çözer ve birbirinin yerine geçmez. OAuth 2.1, “bu istemcinin bu kaynağa erişim hakkı var mı” sorusunun cevabıdır — yetkilendirme protokolüdür. OIDC, OAuth 2.1 üzerine “bu kullanıcı kim, ne zaman, hangi faktörlerle doğrulandı” katmanını ekler — kimlik doğrulama protokolüdür. Modern uygulamalar her iki katmanı birlikte kullanır: openid scope’u eklendiğinde access token’ın yanına ID Token döner ve client hem kaynak erişimi hem de kullanıcı kimliği bilgisini elde eder. Saf API-to-API M2M senaryolarında yalnız OAuth 2.1 (Client Credentials, openid yok) yeterlidir; kullanıcı tarafında daima OIDC ekle.
Sonuç: Uygulama Tipine Göre Implementasyon Yol Haritası
OAuth 2.1 ve OpenID Connect, 2026’da kurumsal kimlik mimarisinin omurgasıdır. Implicit flow ve ROPC gibi tehlikeli akışların kaldırılması, PKCE’nin tüm akışlarda zorunlu hâle gelmesi ve refresh token rotation gibi varsayılanlar, güvenliği protokol seviyesinde yükseltir. Doğru uygulama, sadece protokol seçimiyle değil, uygulama tipine göre desenlerin doğru kombinasyonuyla mümkündür.
- Yeni SaaS (SPA + API): BFF deseni + Auth Code + PKCE + httpOnly cookie + refresh rotation + DPoP. IdP olarak Okta, Auth0 veya self-hosted Keycloak.
- Mobil-first ürün (iOS + Android): AppAuth kütüphanesi + sistem tarayıcısı + Universal/App Link + Keychain/Keystore + DPoP + back-channel logout.
- Mikroservis API (M2M): Client Credentials + mTLS + kısa ömürlü JWT + scope-based authz + sidecar token validator.
- Finans / Açık bankacılık: FAPI 2.0 Advanced + PAR + mTLS + RAR + JARM + PS256/ES256 imza.
- Legacy modernleşme: Önce implicit/ROPC çıkışı, sonra OIDC discovery konsolide, ardından DPoP ve PAR opsiyonel.
- IoT / TV cihaz: Device Authorization + short-lived access + refresh rotation + kullanıcı kodu için rate limit.
Bu mimarinin uzun ömürlü olmasının anahtarı, kimlik katmanını uygulama kodundan ayrıştırarak IdP merkezli yönetmek, token doğrulamasını mikroservis sınırlarında tutarlı bir kütüphaneyle yapmak ve security event’leri SIEM/SOC tarafına otomatik akıtmaktır. Kubernetes Network Policy ve Cilium gibi ağ katmanı kontrollerle birlikte kullanıldığında, OAuth 2.1 + OIDC + zero trust üçlüsü 2026 kurumsal API ekosisteminin temel savunma hattını oluşturur. Penetrasyon testlerinde kimlik akışlarının test edilmesi için Penetration Testing 2026 ve OWASP Top 10 2026 referans alınmalı; yetkilendirme modelleri tarafında ise RBAC, ABAC ve ReBAC karşılaştırması scope tasarımıyla birlikte değerlendirilmelidir.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.