OAuth 2.0, JWT ve SSO Giriş Nedir?

Modern web, mobil ve mikroservis mimarilerinde bir kullanıcının sisteme güvenle giriş yapması, yalnızca veritabanındaki bir parola özetini (hash) kontrol etmekten çok daha karmaşık bir siber güvenlik mühendisliği gerektirir. Bugün bir kullanıcı akıllı telefonundan, tek sayfalık web uygulamasından (SPA - React/Vue) veya üçüncü parti bir entegrasyon servisinden uygulamanıza erişirken; parolasını paylaşmadan Google/Apple/Microsoft hesabıyla oturum açmayı, tek bir kurumsal girişle (SSO) şirketin kullandığı 40 farklı SaaS yazılımına kesintisiz geçiş yapmayı ve oturumunun çalınmamasını bekler. İşte bu modern kimlik ve erişim yönetimi (IAM - Identity and Access Management) dünyasının temel taşlarını OAuth 2.0, OpenID Connect (OIDC), JWT (JSON Web Token) ve SSO (Single Sign-On - Tek Oturum Açma) protokolleri oluşturmaktadır.

Bu kapsamlı güvenlik ve yazılım mimarisi rehberinde; sıklıkla birbirine karıştırılan Kimlik Doğrulama (Authentication - AuthN) ile Yetkilendirme (Authorization - AuthZ) kavramlarını, bir JWT token'ın kriptografik anatomisini, Authorization Code + PKCE akışını, Access Token ve Refresh Token Rotasyonu stratejilerini, token saklamada HttpOnly Cookie ile LocalStorage (XSS/CSRF) savaşını ve kurumsal yetkilendirme modellerini (RBAC vs. ABAC) tüm teknik derinliğiyle inceliyoruz. Diğer yazılım mühendisliği rehberlerimiz için Uygulama ve Yazılım kategorimizi ziyaret edebilirsiniz.

1. En Temel Ayrım: Kimlik Doğrulama (Authentication) vs. Yetkilendirme (Authorization)

Yazılım mülakatlarından kurumsal mimari toplantılarına kadar en sık karıştırılan iki kavram Authentication (AuthN) ve Authorization (AuthZ) süreçleridir. Bu iki süreci bir havalimanı ve otel metaforuyla kesin olarak ayırabiliriz:

• Kimlik Doğrulama (Authentication - AuthN - "Sen Kimsin?"): Kullanıcının iddia ettiği kişi olup olmadığının kanıtlanması sürecidir. Havalimanında pasaportunuzu veya kimlik kartınızı görevliye göstermeniz bir kimlik doğrulamadır. Yazılımda bu işlem; kullanıcı adı/parola, SMS/Authenticator tabanlı Çok Faktörlü Doğrulama (MFA/2FA), biyometrik iz veya Passkeys (WebAuthn / FIDO2) ile gerçekleştirilir. Başarılı bir doğrulama sonucunda sistem HTTP 401 Unauthorized (isimlendirmesi tarihsel olarak yanıltıcı olsa da "Kimliği Doğrulanmamış" anlamına gelir) hatası vermeyi bırakır ve kimliğinizi tanır.
• Yetkilendirme (Authorization - AuthZ - "Neye Erişme İznin Var?"): Kimliği doğrulanmış bir kullanıcının hangi kaynakları görebileceğinin veya hangi işlemleri yapabileceğinin belirlenmesidir. Otelde kimliğinizi gösterip aldığınız oda kartının yalnızca 402 numaralı odayı ve spor salonunu açması, ancak 500 numaralı kral dairesini veya personel odasını açmaması bir yetkilendirmedir. Yetkiniz olmayan bir kaynağa erişmeye çalıştığınızda sunucu kimliğinizi bilmesine rağmen HTTP 403 Forbidden (Yasak) yanıtı döndürür.

Altın Kural: OAuth 2.0 özünde bir Yetkilendirme (Authorization) çerçevesidir; kimlik doğrulama yapmaz. OpenID Connect (OIDC) ise OAuth 2.0'ın üzerine inşa edilmiş bir Kimlik Doğrulama (Authentication) katmanıdır.

2. OAuth 2.0 ve OpenID Connect (OIDC) Nedir? Nasıl Birlikte Çalışırlar?

2010'lu yılların başında bir takvim uygulaması veya fotoğraf baskı servisi, Google Kişilerinize veya Facebook fotoğraflarınıza erişmek istediğinde sizden doğrudan Google/Facebook e-posta adresinizi ve şifrenizi isterdi. Bu durum felaket bir güvenlik modeliydi; çünkü üçüncü parti uygulama şifrenizi düz metin olarak saklayabilir, hesabınızdaki her şeye tam erişim kazanabilir ve erişimi iptal etmenin tek yolu ana şifrenizi değiştirmek olurdu.

OAuth 2.0 (RFC 6749) tam olarak bu "Yetki Devri" (Delegated Authorization) problemini çözmek için tasarlanmıştır. OAuth 2.0 sayesinde kullanıcı şifresini yalnızca asıl kimlik sağlayıcısına (Authorization Server - örn. Google, GitHub, Okta, Keycloak) girer; üçüncü parti uygulamaya ise şifre yerine yalnızca belirli izinlerle (Scopes: örn. calendar.readonly) sınırlandırılmış ve süresi kısıtlı bir Erişim Anahtarı (Access Token) verilir.

Neden Tek Başına OAuth 2.0 Giriş Yapmak İçin Yetersizdir ve OIDC Devreye Girer?

OAuth 2.0 yalnızca bir access_token üretir ve bu token, hedef API'ye (Resource Server) "Bu isteği yapan kişiye takvim verilerini ver" der; ancak uygulamanın kendisine "Şu an giriş yapan kullanıcının adı, e-postası ve benzersiz kullanıcı numarası nedir?" bilgisini standart bir formatta vermez. İşte OpenID Connect (OIDC), OAuth 2.0 akışına openid kapsamını (scope) ve kriptografik olarak imzalanmış bir id_token (Kimlik Token'ı - JWT formatında) ekleyerek "Google ile Giriş Yap" veya kurumsal SSO sistemlerinin standart bir kimlik doğrulama protokolüne dönüşmesini sağlar.

3. JWT (JSON Web Token) Anatomisi ve Kriptografik İmza Doğrulaması

Geleneksel monolitik uygulamalarda kullanıcı giriş yaptığında sunucu belleğinde veya Redis'te bir session_id oluşturulur ve her istekte veritabanına gidilerek bu oturumun geçerli olup olmadığı sorgulanırdı (Stateful Session). Ancak yüzlerce mikroservisin veya Serverless fonksiyonun çalıştığı modern bir mimaride her istekte merkezi oturum veritabanına gitmek büyük bir darboğaz yaratır.

JWT (JSON Web Token - RFC 7519), oturum bilgisini ve kullanıcı iddialarını (claims) doğrudan kendi içinde taşıyan, kriptografik olarak imzalanmış, durumsuz (stateless) ve URL-güvenli bir veri formatıdır. Bir JWT, noktalarla (.) ayrılmış üç Base64URL kodlu bölümden oluşur: Header.Payload.Signature

// 1. HEADER (Algoritma ve Token Tipi)
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "kurumsal-anahtar-2026-01"
}

// 2. PAYLOAD (Claims - İddialar ve Yetkiler)
{
  "iss": "https://auth.teknolojiofis.com",
  "sub": "usr_94820184",
  "aud": "https://api.teknolojiofis.com",
  "exp": 1792584900,
  "iat": 1792584000,
  "roles": ["b2b_bayi_yoneticisi", "fatura_onaylayici"],
  "tenant_id": "org_4412"
}

// 3. SIGNATURE (Kriptografik İmza)
RSASHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  PrivateKey
)

JWT Hakkında En Kritik Güvenlik Uyarısı: Kodlama (Encoding) Şifreleme (Encryption) Değildir!

Deneyimsiz geliştiricilerin yaptığı en tehlikeli hata, JWT'nin içindeki verilerin "şifreli ve gizli" olduğunu sanmaktır. Standart bir JWT (JWS - JSON Web Signature) şifrelenmemiştir; yalnızca Base64URL ile kodlanmıştır. Token'ı ele geçiren herhangi biri jwt.io adresine yapıştırarak veya basit bir atob() fonksiyonuyla Payload içindeki her şeyi düz metin olarak okuyabilir. Bu nedenle JWT içine asla parola, kredi kartı numarası, TC kimlik numarası veya gizli API anahtarları konulmamalıdır.

Peki herkes okuyabiliyorsa JWT nasıl güvenli olur? Güvenliği sağlayan şey 3. bölüm olan İmza (Signature) katmanıdır. Bir saldırgan Payload içindeki "role": "standart_kullanici" bilgisini "role": "super_admin" olarak değiştirip sunucuya gönderdiğinde, sunucu kendi elindeki Genel Anahtar (Public Key - RS256/EdDSA) veya Gizli Anahtar (Secret Key - HS256) ile imzayı kontrol eder; içerik bir harf bile değiştiği için imza doğrulaması anında başarısız olur ve istek reddedilir.

4. Modern Standart Akış: Authorization Code Flow with PKCE

Geçmişte mobil uygulamalar ve React/Angular/Vue gibi tarayıcı tabanlı SPA'ler (Single Page Applications) için kullanılan Implicit Flow (token'ın doğrudan URL adres çubuğundan döndürülmesi), tarayıcı geçmişi ve yönlendirme sızıntıları nedeniyle OAuth 2.1 standardıyla tamamen kullanımdan kaldırılmıştır (deprecated). Bugün hem sunucu taraflı hem de istemci taraflı tüm uygulamalar için tek altın standart Authorization Code Flow with PKCE (Proof Key for Code Exchange) akışıdır:

1. Code Verifier ve Code Challenge Üretimi: Kullanıcı "Giriş Yap" butonuna bastığında, istemci uygulama bellekte rastgele kriptografik bir dize (code_verifier) üretir ve bunun SHA-256 özetini (code_challenge) alarak kimlik sunucusuna yönlendirme yapar.
2. Kullanıcı Doğrulaması ve Yetki Kodu (Authorization Code): Kullanıcı kimlik sunucusunda şifresini ve MFA kodunu girer. Kimlik sunucusu doğrudan token vermek yerine, tarayıcıyı tek kullanımlık ve 60 saniye ömürlü bir authorization_code ile uygulamaya geri yönlendirir.
3. Arka Kanaldan Token Takası (Token Exchange): Uygulama, elindeki tek kullanımlık code ve ilk adımda ürettiği orijinal code_verifier değerini arka kanaldan (POST isteğiyle) kimlik sunucusuna gönderir.
4. PKCE Doğrulaması: Kimlik sunucusu gelen code_verifier değerinin SHA-256 özetini alır; eğer ilk adımdaki code_challenge ile birebir eşleşiyorsa (aradaki bir saldırgan kodu çalmış olsa bile code_verifier değerini bilemeyeceği için) Access Token, ID Token ve Refresh Token üretip teslim eder.

5. Access Token vs. Refresh Token Rotasyonu ve Token Saklama Güvenliği (HttpOnly Cookie vs. LocalStorage)

JWT durumsuz (stateless) olduğu için, bir kez üretildikten sonra süresi dolana kadar sunucu tarafından iptal edilmesi (revocation) doğası gereği zordur. Eğer bir Access Token'a 30 gün geçerlilik süresi verirseniz ve bu token çalınırsa, saldırgan 30 gün boyunca hesabınızı kullanabilir. Bu ikilemi çözmek için İki Katmanlı Token Mimarisi kullanılır:

• Kısa Ömürlü Access Token (5 - 15 Dakika): Her API isteğinde gönderilen JWT'dir. Süresi çok kısa olduğu için çalınsa bile etkisi dakikalar içinde sona erer.
• Uzun Ömürlü Refresh Token ve Rotasyon (7 - 30 Gün): Access Token süresi dolduğunda kullanıcıya tekrar şifre sormadan arka planda yeni bir Access Token almak için kullanılır. Refresh Token Rotation (Rotasyon) mekanizmasında, her yenileme isteğinde eski Refresh Token geçersiz kılınır ve yeni bir Refresh Token verilir. Eğer çalınmış eski bir Refresh Token ikinci kez kullanılmaya çalışılırsa (Replay Attack), sistem hırsızlığı anında fark eder ve o kullanıcıya ait tüm aktif token ailesini (Token Family) derhal iptal ederek hesabı koruma altına alır.

Milyon Dolarlık Soru: Token'lar Tarayıcıda Nerede Saklanmalıdır?

Geliştiricilerin %70'i kolay olduğu için JWT token'larını localStorage.setItem("token", jwt) ile tarayıcının yerel depolama alanına yazar. Oysa localStorage ve sessionStorage, sayfada çalışan herhangi bir JavaScript koduna tamamen açıktır. Uygulamanızda tek bir XSS (Cross-Site Scripting) açığı varsa veya kullandığınız bir NPM paketi ele geçirilirse, saldırgan tek satırlık bir script ile tüm kullanıcıların token'larını çalabilir.

Doğru Kurumsal Mimari (BFF - Backend-for-Frontend & HttpOnly Cookie):

• Refresh Token (ve mümkünse Access Token), JavaScript tarafından kesinlikle okunamayan (document.cookie erişimine kapalı) HttpOnly; Secure; SameSite=Strict (veya Lax) bayraklarına sahip çerezlerde (Cookies) saklanmalıdır.
• SPA uygulamalarda Access Token yalnızca JavaScript çalışma zamanı belleğinde (In-Memory değişken / Closure içinde) tutulmalı, sayfa yenilendiğinde ise HttpOnly çerezdeki Refresh Token aracılığıyla sessizce (Silent Refresh) yeniden alınmalıdır. Merkeziyetsiz cüzdan tabanlı kimlik doğrulama (SIWE - Sign-In with Ethereum) alternatifleri için Web3 ve Merkezsiz Web yazımızı da inceleyebilirsiniz.

6. SSO (Single Sign-On - Tek Oturum Açma): SAML 2.0 ve OIDC Karşılaştırması

5.000 çalışanı olan bir holdingde her çalışanın CRM, ERP, İK portalı, e-posta, Jira ve iç yönetim panelleri için 25 ayrı şifre belirlemesi hem unutulan şifreler nedeniyle BT destek maliyetlerini patlatır hem de çalışanların işten ayrıldığı gün (Offboarding) tüm sistemlerdeki hesaplarının tek tek kapatılmasını imkânsız hale getirir. SSO (Tek Oturum Açma), tüm bu uygulamaların kimlik doğrulama görevini merkezi bir Kimlik Sağlayıcıya (IdP - Identity Provider: Microsoft Entra ID / Azure AD, Okta, Keycloak, Google Workspace) devretmesidir.

Aşağıdaki tabloda modern kimlik ve yetkilendirme protokollerinin mimari farklarını karşılaştırdık:

Protokol / Teknoloji	Birincil Amacı	Veri Formatı	İletişim Kanalı	En Uygun Kullanım Senaryosu
OAuth 2.0	Yetkilendirme (Authorization - API Erişim Devri)	JSON (Opaque veya JWT Access Token)	REST / HTTP Yönlendirmeleri	Üçüncü parti API entegrasyonları, mikroservis yetkilendirmesi
OpenID Connect (OIDC)	Kimlik Doğrulama (Authentication) ve Modern SSO	JSON / JWT (id_token)	REST / JSON / HTTP	Modern web (SPA), mobil uygulamalar, B2C sosyal giriş ve yeni nesil SSO
SAML 2.0	Kurumsal Kimlik Doğrulama ve Federasyonlu SSO	XML (Dijital İmzalı SAML Assertion)	Tarayıcı POST / Redirect Bağlamaları	Büyük kurumsal holdingler, bankalar, kamu kurumları ve eski B2B SaaS entegrasyonları
JWT (JSON Web Token)	Durumsuz (Stateless) Veri ve İddia Taşıma Standardı	Base64URL Kodlu JSON + Kriptografik İmza	HTTP Header (Authorization: Bearer) veya Cookie	Mikroservisler arası kimlik aktarımı ve API Gateway doğrulaması

7. İleri Seviye Yetkilendirme Modelleri: RBAC, ABAC ve ReBAC (Zanzibar)

Kullanıcının kimliğini SSO veya OIDC ile doğruladıktan sonra, uygulama içinde hangi verileri değiştirebileceğini yönetmek için üç temel yetkilendirme mimarisi kullanılır. Özellikle B2B Bayi Portalı veya Kurumsal Yazılım Geliştirme projelerinde bu ayrım hayati önem taşır:

1. RBAC (Role-Based Access Control - Rol Tabanlı Erişim Kontrolü): İzinler doğrudan kullanıcılara değil, rollere (Admin, Muhasebe_Uzmani, Bayi_Satis_Temsilcisi) atanır. Yönetimi en kolay modeldir ancak "Sadece kendi bölgesindeki bayilerin 100.000 TL altındaki faturalarını mesai saatleri içinde onaylayabilir" gibi dinamik kurallarda rol patlamasına (Role Explosion) yol açar.
2. ABAC (Attribute-Based Access Control - Nitelik Tabanlı Erişim Kontrolü): Yetki kararı; kullanıcının nitelikleri (departman, kıdem), kaynağın nitelikleri (doküman gizlilik derecesi, tutar) ve ortam nitelikleri (IP adresi, saat, cihaz güvenliği) bir politika motorunda (Open Policy Agent - OPA / AWS Cedar) değerlendirilerek verilir.
3. ReBAC (Relationship-Based Access Control - İlişki Tabanlı Erişim Kontrolü): Google Docs veya Notion gibi sistemlerde kullanılan (Google Zanzibar mimarisi; SpiceDB, OpenFGA) modeldir. Yetki, nesneler arasındaki grafik ilişkisine ("Ahmet, X Klasörünün sahibidir → Y Dokümanı X Klasörünün içindedir → Dolayısıyla Ahmet Y Dokümanını düzenleyebilir") göre milisaniyeler içinde hesaplanır.

8. Sıfır Güven (Zero Trust) Mimarisi, SCIM Otomasyonu ve Passkeys (FIDO2)

Kurumsal kimlik yönetimi yalnızca giriş ekranından ibaret değildir. Bir B2B SaaS ürünü geliştirdiğinizde kurumsal müşterileriniz sizden SCIM 2.0 (System for Cross-domain Identity Management) desteği talep edecektir. SCIM sayesinde, müşteri kendi İK sisteminde (Workday veya Azure AD) yeni bir çalışan işe aldığında veya bir çalışanın işine son verdiğinde, saniyeler içinde sizin uygulamanıza otomatik bir webhook/REST çağrısı gelir; kullanıcının hesabı otomatik açılır, doğru departman rolüne atanır veya işten ayrıldığı saniye tüm aktif oturumları sonlandırılır. Eski sistemlerdeki kimlik doğrulama protokollerinin analizi ve modernizasyonu için REA: Yapay Zeka ile Tersine Mühendislik rehberimizden de faydalanabilirsiniz.

Ayrıca oltalama (phishing) saldırılarına karşı %100 koruma sağlayan Passkeys (WebAuthn / FIDO2) standardı, parolaları tamamen ortadan kaldırarak kullanıcının cihazındaki güvenli donanım çipinde (TPM / Secure Enclave) saklanan asimetrik kriptografik anahtar çiftleriyle (FaceID / TouchID) saniyeler içinde giriş yapılmasını sağlamaktadır.

9. Makineden Makineye (M2M) Yetkilendirme, BFF Deseni ve Kritik JWT Güvenlik Açıkları

Her yazılım iletişimi ekranda oturan gerçek bir insan (kullanıcı) tarafından başlatılmaz. Gece saat 03:00'te çalışan bir fatura mutabakat servisinin kargo şirketinin API'sine bağlanması veya Sipariş Mikroservisinin Stok Mikroservisini çağırması durumunda ortada tarayıcı yönlendirmesi yapacak veya şifre girecek bir insan yoktur. Bu senaryolarda OAuth 2.0 Client Credentials Grant (İstemci Kimlik Bilgileri Akışı) ve mTLS (Karşılıklı TLS) kullanılır:

• Client Credentials Akışı (M2M - Machine-to-Machine): İstemci sunucu, kendisine tahsis edilen client_id ve client_secret (veya imzalı bir istemci sertifikası) ile doğrudan kimlik sunucusunun /oauth/token uç noktasına başvurur ve makine yetkilerini içeren bir Access Token alır.
• mTLS (Mutual TLS / Certificate-Bound Tokens - RFC 8705): Bankacılık (Açık Bankacılık / PSD2) ve yüksek güvenlikli mikroservis ağlarında (Service Mesh - Istio/Linkerd), verilen Access Token doğrudan istemci sunucunun X.509 TLS sertifikasının parmak izine (thumbprint) bağlanır. Böylece token ağ üzerinde çalınsa bile, aynı özel TLS sertifikasına sahip olmayan başka bir makineden kullanılması matematiksel olarak imkânsız hale gelir.
• BFF (Backend-for-Frontend) Güvenlik Mimarisi: En yüksek güvenlik seviyesini arayan modern React/Next.js/Vue uygulamalarında tarayıcıya hiçbir zaman Access Token veya Refresh Token gönderilmez. Tarayıcı ile aynı alan adında çalışan hafif bir BFF (Ön Uç İçin Arka Uç) vekil sunucusu OAuth 2.0 akışını yürütür, token'ları kendi sunucu belleğinde/Redis'te saklar ve tarayıcıyla yalnızca şifreli, HttpOnly; SameSite=Strict bir oturum çerezi üzerinden konuşur.

Üretim Ortamında Kaçınılması Gereken 3 Ölümcül JWT Zafiyeti

1. "alg: none" (İmzasız Algoritma) Saldırısı: Eski veya yanlış yapılandırılmış bazı JWT kütüphaneleri, Header kısmına "alg": "none" yazıldığında imza doğrulamasını tamamen atlayıp token'ı geçerli kabul edebilmektedir. JWT doğrulama fonksiyonunuzda kabul edilen algoritmaları (örneğin yalnızca ["RS256"]) açıkça beyaz listeye (whitelist) alın.
2. Algoritma Karıştırma (RS256 → HS256 Key Confusion): Sunucunuz asimetrik RS256 kullanırken, saldırgan herkesçe bilinen Genel Anahtarınızı (Public Key) alıp bunu simetrik bir HS256 gizli anahtarı (Secret) gibi kullanarak sahte bir token imzalayabilir. Doğrulama katmanında anahtar tipi ile algoritma eşleşmesini zorunlu kılın.
3. Eksik aud (Audience) ve iss (Issuer) Kontrolü: Yalnızca imzanın geçerli olması yetmez! Aynı merkezi SSO sunucusunu kullanan "Yemekhane Uygulaması" için üretilmiş geçerli imzalı bir JWT token, eğer aud (Hedef Kitle) kontrolü yapılmazsa "Finans Yönetim API'si" tarafından da geçerli kabul edilebilir. Her API servisi gelen token'ın aud alanında kendi servis kimliğinin yazdığını doğrulamalıdır.

Sıkça Sorulan Sorular (SSS)

1. JWT imzalamada HS256 (Simetrik) mı yoksa RS256 / EdDSA (Asimetrik) mı kullanılmalıdır?

Eğer tek bir monolitik uygulamanız varsa ve token'ı üreten de doğrulayan da aynı sunucuysa HS256 (HMAC-SHA256) yeterlidir. Ancak birden fazla mikroservisiniz veya üçüncü parti servisleriniz varsa kesinlikle RS256 veya EdDSA (Asimetrik Anahtar Çifti) kullanılmalıdır. Böylece Özel Anahtar (Private Key) yalnızca merkezi Auth sunucusunda gizli kalır; diğer tüm mikroservisler ise JWKS (JSON Web Key Set) uç noktasından aldıkları Genel Anahtar (Public Key) ile token'ları güvenle doğrular.

2. Bir kullanıcının hesabı askıya alındığında süresi henüz dolmamış JWT Access Token nasıl iptal edilir?

Kısa ömürlü (örneğin 5 dakikalık) Access Token mimarisinde çoğu sistem 5 dakikalık sürenin dolmasını bekler. Ancak bankacılık gibi saniyelik iptal gerektiren durumlarda Redis Tabanlı Kara Liste (Token Blacklist / Denylist) uygulanır: İptal edilen token'ın benzersiz jti (JWT ID) değeri, token'ın kalan ömrü (TTL) kadar Redis'e yazılır ve API Gateway her istekte bellek içi Redis kontrolü yapar.

3. Kendi kimlik doğrulama (Auth) sistemimizi sıfırdan yazmalı mıyız, yoksa hazır çözüm mü kullanmalıyız?

Parola sıfırlama, MFA, Brute-Force koruması, Refresh Token rotasyonu, OAuth sosyal girişler ve SAML SSO akışlarını sıfırdan hatasız kodlamak aylarca sürer ve en ufak kriptografik hata veri ihlaline yol açar. Bu nedenle açık kaynaklı kendi sunucunuzda barındırabileceğiniz Keycloak, Ory Kratos/Hydra, Authentik, Better-Auth veya yönetilen Auth0, Clerk, Supabase Auth, AWS Cognito çözümlerini kullanmak mühendislik açısından çok daha doğru bir karardır.

4. SAML 2.0 eski bir teknoloji mi? Neden kurumsal şirketler hâlâ SAML istiyor?

Evet, SAML 2.0 2005 yılında standartlaşmış XML tabanlı bir protokoldür ve modern OIDC'ye göre kurulumu daha karmaşıktır. Ancak bankalar, sigorta şirketleri, savunma sanayii ve büyük holdinglerin mevcut Active Directory / LDAP ve güvenlik duvarı altyapıları SAML federasyonu üzerine kurulu olduğu için Enterprise B2B yazılım satışı yapabilmek adına hem OIDC hem de SAML 2.0 desteği sunmak ticari bir zorunluluktur.

5. Mikroservis mimarisinde JWT doğrulaması nerede yapılmalıdır?

En sağlıklı tasarım deseni İki Aşamalı Doğrulama (Edge + Service Level) modelidir. İlk olarak dış dünyadan gelen istek API Gateway katmanında karşılanır; imza ve süre (exp) doğrulaması burada yapılarak geçersiz istekler iç ağa girmeden reddedilir. Ardından iç mikroservisler de "Sıfır Güven" (Zero Trust) prensibi gereği kendilerine gelen JWT'deki yetki kapsamlarını (scopes/roles) kendi iş mantıklarına göre kontrol eder.