OAuth 2.0 ile Uygulama Entegrasyonu Nasıl Yapılır?

OAuth 2.0, dağıtık sistemlerde ve modern bulut mimarilerinde kullanıcı parolalarını üçüncü taraf istemcilerle paylaşmadan kaynaklara güvenli erişim yetkisi tanımlayan temel protokoldür.

Uygulama ekosistemlerinin mikroservisler ve harici API entegrasyonları üzerinden genişlemesi, kimlik doğrulama ve yetkilendirme mekanizmalarının katı güvenlik standartlarına bağlanmasını zorunlu kılmıştır. OAuth 2.0 ile Uygulama Entegrasyonu Nasıl Yapılır? sorusu; doğru izin türünün (grant type) seçilmesinden istemci yapılandırmasına, yetkilendirme kodlarının güvenli değişiminden token yaşam döngüsü ve PKCE korumasına kadar uzanan teknik adımları kapsar. Bu teknik rehber, yazılım mimarları, ürün yöneticileri ve teknik karar vericiler için kurumsal ölçekte hatasız bir REST API yetkilendirme altyapısı kurmanın metodolojisini açıklamaktadır.

OAuth 2.0 Nedir ve Kurumsal Mimaride Neden Tercih Edilmelidir?

OAuth 2.0 (Open Authorization), IETF RFC 6749 standardı ile tanımlanmış, HTTP tabanlı servisler için bir yetkilendirme (authorization) çerçevesidir. Geleneksel istemci-sunucu kimlik doğrulama modellerinde, üçüncü taraf uygulamaların kısıtlı kaynaklara erişebilmesi için kullanıcıların kullanıcı adı ve parolalarını doğrudan istemciye teslim etmesi gerekirdi. Bu yaklaşım, parolanın istemci tarafında güvensiz biçimde saklanması, kullanıcıların kaynak bazlı yetki ayrımı yapamaması ve tek bir servisin ele geçirilmesi durumunda tüm hesap güvenliğinin tehlikeye girmesi gibi kritik güvenlik açıkları doğurmaktaydı. OAuth 2.0, kaynak sahibi ile istemci uygulama arasına bir yetkilendirme katmanı ekleyerek bu riskleri bertaraf eder.

Kurumsal yazılım mimarilerinde OAuth 2.0’ın temel varlık sebebi, kullanıcı kimlik bilgilerinin üçüncü taraf yazılımlara hiçbir koşulda açık edilmemesidir. Bunun yerine istemciye, belirli bir kaynağa (Resource), belirli bir süreyle (Time-to-Live / TTL) ve kısıtlı yetkilerle (Scope) erişim imkanı tanıyan kriptografik olarak imzalanmış veya opak belirteçler (Access Token) verilir. Bu yapı, hem kurum içi mikroservislerin birbiriyle haberleşmesinde (Machine-to-Machine / M2M) hem de kurumsal SaaS platformlarının harici ekosistemlerle entegre edilmesinde sıfır güven (Zero Trust) prensibinin işletilmesini sağlar.

REST API ekosisteminde OAuth 2.0 entegrasyonu, veri izolasyonu ve yasal düzenlemelere (KVKK, GDPR, ISO 27001) tam uyumluluk sağlamak adına bir tercih değil, mimari bir zorunluluktur. Kullanıcı parolasını merkezi kimlik sağlayıcıda tutarak sistem geneline yetki jetonları dağıtmak, güvenlik denetimlerini basitleştirir, oturum iptallerini (revocation) merkezi hale getirir ve olası bir veri ihlalinde saldırı yüzeyini daraltır.

Kimlik Doğrulama (Authentication) ve Yetkilendirme (Authorization) Ayrımı

Yazılım geliştirme süreçlerinde en sık karşılaşılan kavram yanılgılarından biri, kimlik doğrulama (authentication) ile yetkilendirme (authorization) süreçlerinin birbirine karıştırılmasıdır. Kimlik doğrulama; bir kullanıcının, servisin veya uygulamanın iddia ettiği kişi ya da varlık olduğunu kanıtlama işlemidir ("Sen kimsin?"). Yetkilendirme ise kimliği doğrulanmış bir aktörün, hedef sistem üzerinde hangi kaynaklara erişebileceğini ve hangi işlemleri gerçekleştirebileceğini belirleme sürecidir ("Ne yapmaya yetkin var?").

OAuth 2.0, saf bir yetkilendirme protokolüdür. Kullanıcının nasıl oturum açtığı, iki faktörlü kimlik doğrulama (2FA) kullanıp kullanmadığı veya biyometrik veri sağlayıp sağlamadığıyla ilgilenmez; yalnızca yetkilendirme sürecinin sonucunda üretilen token akışını yönetir. Eğer kurumsal bir projede tekli oturum açma (Single Sign-On / SSO) veya kullanıcı profil bilgilerinin doğrulanması isteniyorsa, OAuth 2.0 üzerine inşa edilen kimlik katmanı olan OpenID Connect (OIDC) protokolü tercih edilmelidir. OIDC, OAuth 2.0 akışına bir id_token ekleyerek kimlik doğrulama katmanını yetkilendirme protokolüyle hibrit şekilde birleştirir.

+-------------------------------------------------------------------+
|                        OpenID Connect (OIDC)                      |
|                  Kimlik Doğrulama (Authentication)                |
|                    - Kullanıcı Profili, ID Token                  |
+-------------------------------------------------------------------+
|                            OAuth 2.0                              |
|                    Yetkilendirme (Authorization)                  |
|                    - Access Token, Refresh Token, Scope           |
+-------------------------------------------------------------------+
|                         HTTP / TLS / TCP                          |
|                       Güvenli Taşıma Katmanı                      |
+-------------------------------------------------------------------+

REST API Güvenliğinde Endüstri Standardı Olarak OAuth 2.0

REST API mimarileri durumsuz (stateless) prensiple çalışır; yani sunucu, istemciyle gerçekleştirdiği her bağımsız HTTP isteğinde önceki durumları hafızada tutmaz. Bu modelde oturum yönetimi (session management) için çerez tabanlı (cookie-based) eski yöntemleri kullanmak, mikroservis ölçeğinde ve çapraz etki alanı (Cross-Origin) isteklerinde ciddi kısıtlamalar yaratır. OAuth 2.0, bu durumsuz mimariyle kusursuz biçimde hizalanır.

Yetkilendirme belirteçleri, her HTTP isteğinin başlığında (Header) taşınır:

GET /api/v1/customers/financial-records HTTP/1.1
Host: api.enterprise-domain.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json

Yukarıdaki istekte yer alan Bearer şeması, tokenı elinde bulunduran aktörün başka bir kanıta ihtiyaç duymaksızın ilgili kaynağa erişebileceğini ifade eder. Yetkilendirme sunucusu tarafından üretilen bu jeton, API Gateway veya hedef mikroservis tarafından merkezi bir veritabanı sorgusuna dahi gerek kalmadan (özellikle asimetrik şifrelenmiş JWT kullanıldığında) doğrulanabilir. Böylece sistem performansı düşmeden kurumsal ölçekte yüksek verimli API güvenliği elde edilir.

OAuth 2.0 Mimarisi ve Temel Roller

OAuth 2.0 protokolünün kurumsal bir entegrasyonda doğru kurgulanabilmesi için RFC 6749 şartnamesinde tanımlanan dört ana rolün sınırlarının kesin çizgilerle belirlenmesi gerekir. Bu roller arasındaki görev ayrılığı, güvenlik katmanlarının bağımsız olarak ölçeklenmesine ve denetlenmesine zemin hazırlar.

Kurumsal mimarilerde bu dört rol genellikle farklı sunucu kümelerine, etki alanlarına ve hatta farklı bulut sağlayıcılarına dağıtılmış durumdadır. Her aktörün sorumluluğunun bilinmesi, olası zafiyetlerin tespitinde ve sistem bileşenlerinin doğru konumlandırılmasında kritik rol oynar.

Kaynak Sahibi (Resource Owner) ve İstemci (Client)

Kaynak sahibi (Resource Owner), verinin asıl sahibidir. Bu rol çoğu senaryoda son kullanıcıdır; ancak sunucular arası otomatik entegrasyonlarda sistem yöneticisi veya tüzel varlığın kendisi de kaynak sahibi statüsünde değerlendirilebilir. Kaynak sahibi, istemcinin kendi adına hangi verilere, ne kadar süreyle erişebileceğini belirleyen onay ekranlarıyla (Consent Screen) etkileşime girer.

İstemci (Client) ise verilere ulaşmak isteyen uygulamadır. OAuth 2.0 şartnamesi istemcileri gizlilik ve güvenlik kabiliyetlerine göre iki temel kategoriye ayırır:

1. Gizli İstemciler (Confidential Clients): İstemci sırrını (Client Secret) güvenli bir şekilde saklayabilen, son kullanıcının kaynak koduna veya çalışma zamanı belleğine erişemediği sistemlerdir. Geleneksel sunucu taraflı web uygulamaları (Node.js, Java Spring, .NET Core MVC, Python Django) bu sınıftadır.

2. Halka Açık İstemciler (Public Clients): Kaynak kodları veya çalışma zamanı ortamları kullanıcı veya üçüncü taraflarca deşifre edilebilen, bu nedenle bir istemci sırrını güvenle saklayamayan uygulamalardır. Tek Sayfa Uygulamaları (Single Page Applications - React, Vue, Angular), mobil uygulamalar (iOS, Android) ve masaüstü yazılımlar bu kapsama girer.

Yetkilendirme Sunucusu (Authorization Server) ve Kaynak Sunucusu (Resource Server)

Yetkilendirme Sunucusu (Authorization Server), güvenlik mimarisinin beynidir. Kullanıcı kimliğini doğrulamak, izin kapsamlarını (scopes) yönetmek, yetkilendirme kodlarını (authorization codes) üretmek ve bu kodları Access Token ve Refresh Token ile takas etmek bu sunucunun sorumluluğundadır. Kurumsal yapılarda genellikle merkezi bir Kimlik ve Erişim Yönetimi (IAM) altyapısı bu rolü üstlenir.

Kaynak Sunucusu (Resource Server) ise istemcinin asıl ulaşmak istediği iş mantığını ve veritabanı kayıtlarını barındıran REST API servisidir. Kaynak sunucusu, gelen her HTTP isteğinde Authorization: Bearer <token> başlığını inceler. Token geçerli, süresi dolmamış ve istenen uç nokta için gerekli kapsamları (scopes) içeriyorsa talebe cevap verir; aksi takdirde HTTP 401 Unauthorized veya HTTP 403 Forbidden durum kodlarını döner.

Proje Gereksinimlerine Göre Doğru İzin Türünü (Grant Type) Seçmek

OAuth 2.0 protokolü, farklı uygulama mimarileri ve güvenilirlik seviyeleri için çeşitli yetkilendirme akışları (Grant Types) tanımlamıştır. Yanlış bir grant türü seçmek, tüm güvenlik modelini çökertebileceği gibi entegrasyon sürecinde çözülmesi zor mimari tıkanıklıklara da yol açabilir. Güncel RFC standartları ve OAuth 2.1 taslakları ışığında modern kurumsal sistemlerde kullanılan ana izin türlerini doğru ayrıştırmak gerekir.

Uygulama Mimarisi Analizi:
┌─────────────────────────────────────────────────────────────┐
│ Entegrasyon Senaryosu Nedir?                                │
└──────────────┬──────────────────────────────────────────────┘
               │
       ┌───────┴──────────────────────────────┐
       │                                      │
[Kullanıcı Katılımı Var]             [Kullanıcı Katılımı Yok]
       │                                      │
       ▼                                      ▼
[İstemci Türü Nedir?]             ┌───────────────────────┐
 ┌─────┴──────────────────┐       │ Client Credentials    │
 │                        │       │ Grant (M2M / Daemons) │
 ▼                        ▼       └───────────────────────┘
[Confidential Client]   [Public Client]
(Backend Web Apps)      (SPA / Mobil Apps)
 │                        │
 ├────────────────────────┴──────────────────────┐
 ▼                                               ▼
┌───────────────────────────────────────┐ ┌───────────────────────────────┐
│ Authorization Code Grant              │ │ Authorization Code + PKCE     │
│ (İstemci Sırrı Güvenli Sunucuda)     │ │ (Zorunlu Güvenlik Standardı)  │
└───────────────────────────────────────┘ └───────────────────────────────┘

Authorization Code Grant (Web ve Mobil Uygulamalar İçin Güvenli Akış)

Authorization Code Grant, son kullanıcının devreye girdiği ve bir istemci uygulamanın kullanıcı verilerine erişmek istediği senaryolarda altın standarttır. Bu akışta istemci uygulama, erişim belirtecini doğrudan almak yerine önce geçici bir "yetkilendirme kodu" (Authorization Code) elde eder.

Yetkilendirme kodunun elde edilmesi kullanıcı tarayıcısı üzerinden yönlendirmelerle gerçekleşirken, bu kodun asıl access_token ile takas edilmesi istemcinin arka uç sunucusu ile yetkilendirme sunucusu arasında doğrudan (arka kanal - back-channel) HTTP POST çağrısıyla yapılır. Bu sayede token hiçbir zaman tarayıcı geçmişine, yönlendirme URL'lerine veya istemci tarafı komut dosyalarına ifşa edilmez.

Mobil ve Tek Sayfa Uygulamaları (SPA) gibi Halka Açık İstemciler (Public Clients) için bu akış PKCE (Proof Key for Code Exchange - RFC 7636) eklentisiyle birlikte kullanılmak zorundadır. PKCE, yetkilendirme kodunun kötü niyetli uygulamalar tarafından çalınması durumunda dahi token takasının yapılmasını engelleyen dinamik bir kriptografik doğrulama mekanizması ekler.

Client Credentials Grant (Sunucudan Sunucuya - M2M İletişim)

Client Credentials Grant (RFC 6749 Bölüm 4.4), işin içinde herhangi bir son kullanıcının bulunmadığı, doğrudan iki sunucu veya mikroservisin birbiriyle iletişim kurduğu (Machine-to-Machine / M2M) senaryolar için tasarlanmıştır. Bu akışta istemcinin kendisi kaynak sahibidir.

Arka planda çalışan cron işleri, veri senkronizasyon kuyrukları, raporlama daemon'ları veya bağımsız mikroservisler; doğrudan kendilerine tanımlanan client_id ve client_secret ikilisini kullanarak yetkilendirme sunucusuna başvurur ve bir access_token temin eder. Bu akışta kullanıcı arayüzü, yönlendirme (redirect) veya onay ekranı bulunmaz.

POST /oauth/v2/token HTTP/1.1
Host: auth.enterprise-domain.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=svc_reporting_worker&client_secret=sec_k983Hf8xL201mzP&scope=reports:generate

Implicit Grant ve Resource Owner Password Credentials (Kullanımdan Kalkan Akışlar)

Güvenlik standartlarının gelişmesiyle birlikte geçmişte yaygın olarak kullanılan bazı izin türleri, ciddi güvenlik zafiyetleri barındırdıkları gerekçesiyle OAuth 2.0 Security Best Current Practice (BCP) ve OAuth 2.1 şartnameleri kapsamında tamamen kullanımdan kaldırılmıştır (deprecated).

• Implicit Grant: Geçmişte tarayıcı tabanlı SPA uygulamaları için tasarlanan bu akışta, access token doğrudan URL parçacığında (#access_token=...) geri döndürülmekteydi. Bu durum tokenın tarayıcı geçmişine kaydedilmesine, erişim loglarına sızmasına ve XSS saldırılarıyla kolayca çalınmasına neden oluyordu. Günümüzde SPA'lar için kesin çözüm PKCE destekli Authorization Code akışıdır.

• Resource Owner Password Credentials (ROPC): Kullanıcının kullanıcı adı ve şifresini doğrudan istemci uygulamaya girdiği ve istemcinin bu bilgilerle token aldığı akıştır. Parolayı istemciye teslim etmeme felsefesini tamamen çiğnediği için legacy sistemlerin taşınması haricinde kesinlikle yasaklanmıştır.

OAuth 2.0 ile REST API Entegrasyonu Nasıl Yapılır? (Adım Adım Kurulum)

Bir uygulamayı OAuth 2.0 altyapısına entegre etmek; istemci kaydından başlayarak kapsam belirleme, yetkilendirme kodu alma ve bu kodu geçerli bir erişim belirteciyle takas etme süreçlerini içeren dört temel adımdan oluşur. Aşağıdaki adımlar, Authorization Code akışını temel alarak kurumsal bir REST API entegrasyonunun nasıl yapılandırılacağını somut kod ve istek örnekleriyle açıklamaktadır.

Adım 1: İstemci Kaydı (Client ID ve Client Secret Oluşturma)

Entegrasyonun ilk adımı, istemci uygulamanın Yetkilendirme Sunucusuna (IdP / Authorization Server) tanıtılmasıdır. Bu işlem sağlayıcının (örneğin Auth0, Keycloak, Google Cloud Identity veya şirket içi IAM paneli) yönetim konsolundan gerçekleştirilir.

Kayıt esnasında sistem iki kritik kimlik bilgisi üretir:

• Client ID (İstemci Kimliği): Uygulamanızı benzersiz şekilde tanımlayan, gizli olmayan, genel kullanıma açık bir UUID veya string değerdir.

• Client Secret (İstemci Sırrı): Yalnızca istemcinizin ve yetkilendirme sunucusunun bildiği, parola niteliğindeki kriptografik anahtardır. Bu anahtar asla istemci tarafı kodlarda (JavaScript, mobil binary vb.) veya açık Git depolarında saklanmamalıdır.

Ayrıca bu aşamada, yetkilendirme işlemi tamamlandıktan sonra kullanıcının yönlendirileceği Redirect URI (Geri Dönüş Bağlantısı) adresleri sisteme beyaz liste (whitelist) olarak kaydedilir (Örn: https://app.enterprise-crm.com/oauth/callback).

Adım 2: Kapsam (Scope) ve İzin Yapılandırması

Kapsam (Scope), OAuth 2.0'da bir istemcinin kullanıcı adına talep ettiği yetkilerin sınırlarını belirleyen mekanizmadır. Yetki aşımını engellemek için her zaman "En Az Yetki İlkesi" (Principle of Least Privilege) uygulanmalıdır.

Kapsamlar boşluklarla ayrılarak HTTP isteklerine eklenir. Kurumsal bir REST API tasarımında kapsamlar genellikle kaynak:eylem hiyerarşisiyle modellenir:

read:customers       -> Müşteri verilerini okuma yetkisi
write:customers      -> Müşteri kaydı oluşturma/güncelleme yetkisi
delete:customers     -> Müşteri silme yetkisi (kritik)
invoices:export      -> Fatura dışa aktarma yetkisi

Adım 3: Yetkilendirme Kodunun Talep Edilmesi ve Yönlendirme (Redirect URI) İşlemleri

İstemci uygulama, son kullanıcıyı Yetkilendirme Sunucusunun /authorize uç noktasına yönlendirir. Bu istek tarayıcı penceresinde açılır ve kullanıcıdan oturum açıp istenen izinleri onaylaması istenir.

GET /oauth/v2/authorize?
  response_type=code
  &client_id=crm_corp_app_prod_8723
  &redirect_uri=https%3A%2F%2Fapp.enterprise-crm.com%2Foauth%2Fcallback
  &scope=read%3Acustomers%20invoices%3Aexport
  &state=xyzSecureRandomStateString8923
  &code_challenge=E9Melhoa2OwvFrGMTJguCH5rtx64ZUqiJZip1Bij098
  &code_challenge_method=S256 HTTP/1.1
Host: auth.enterprise-domain.com

Kullanıcı izinleri onayladığında, Yetkilendirme Sunucusu kullanıcıyı kayıtlı redirect_uri adresine geçici bir yetkilendirme kodu (code) ve gönderilen state parametresi ile geri yönlendirir:

HTTP/1.1 302 Found
Location: https://app.enterprise-crm.com/oauth/callback?
  code=auth_code_9a87f1b2c3d4e5f6
  &state=xyzSecureRandomStateString8923

Adım 4: Kodun Access Token ile Değiştirilmesi

İstemcinin arka uç sunucusu, yönlendirme URL'sinden yakaladığı code değerini alarak yetkilendirme sunucusunun /token uç noktasına doğrudan bir HTTP POST isteğinde bulunur. Bu istek arka planda (server-to-server) gerçekleştiği için tarayıcı müdahalesine kapalıdır.

POST /oauth/v2/token HTTP/1.1
Host: auth.enterprise-domain.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=crm_corp_app_prod_8723
&client_secret=sec_98f7a6b5c4d3e2f1a0b9
&code=auth_code_9a87f1b2c3d4e5f6
&redirect_uri=https%3A%2F%2Fapp.enterprise-crm.com%2Foauth%2Fcallback
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Yetkilendirme sunucusu parametreleri doğrular ve istemciye JSON formatında erişim jetonlarını teslim eder:

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfODkzMjEiLCJzY29wZXMiOlsicmVhZDpjdXN0b21lcnMiLCJpbnZvaWNlczpleHBvcnQiXSwiaXNzIjoiYXV0aC5lbnRlcnByaXNlLWRvbWFpbi5jb20iLCJleHAiOjE3MjQ3NjQ4MDB9.iZ0yX...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "rfr_89a7f6e5d4c3b2a10987654321",
  "scope": "read:customers invoices:export"
}

Token Yönetimi ve Güvenli Yaşam Döngüsü (Lifecycle)

OAuth 2.0 entegrasyonlarında güvenlik, tokenların alındığı anda bitmez; asıl zorluk bu tokenların nasıl saklanacağı, taşınacağı ve yaşam döngülerinin nasıl yönetileceğidir. Yanlış yapılandırılmış bir token yönetim katmanı, tüm sistemin ele geçirilmesine zemin hazırlayabilir.

Token yaşam döngüsü; belirtecin oluşturulması, REST isteklerinde taşınması, geçerliliğinin doğrulanması, süresi dolduğunda yenilenmesi ve gerektiğinde anında iptal edilmesi (revocation) süreçlerini kapsar.

Access Token (Erişim Belirteci) Kullanımı ve Doğrulanması

Access Token, istemcinin Kaynak Sunucusuna (Resource Server) yapacağı her HTTP çağrısında yetkisini kanıtlayan anahtardır. Modern mimarilerde Access Token'lar genellikle iki farklı formatta yapılandırılır:

1. JSON Web Tokens (JWT - RFC 7519): Kendinden açıklamalı (self-contained) token formatıdır. Yetkilendirme sunucusu tarafından özel bir asimetrik anahtarla (RSA / ECDSA - örn. RS256) imzalanır. Token içeriğinde (payload) kullanıcının kimliği (sub), yayıncı (iss), geçerlilik süresi (exp) ve sahip olunan izinler (scopes) JSON olarak yer alır. Kaynak sunucu, yetkilendirme sunucusuna sormadan sadece açık anahtar (JWKS - JSON Web Key Set) ile bu tokenı milisaniyeler içinde doğrular.

2. Opak Tokenlar (Opaque / Reference Tokens): Anlamsız rastgele bir karakter dizisinden oluşur. Kaynak sunucusu gelen bu tokenı doğrulamak için her defasında Yetkilendirme Sunucusunun /introspect (RFC 7662) uç noktasına ağ çağrısı yapmak zorundadır. Güvenlik seviyesi çok yüksek olmakla birlikte ağ gecikmesi yaratır.

Bir JWT Payload örneği:

{
  "iss": "https://auth.enterprise-domain.com/",
  "sub": "usr_corp_99412",
  "aud": "https://api.enterprise-domain.com/v1/",
  "exp": 1724768400,
  "nbf": 1724764800,
  "iat": 1724764800,
  "jti": "d8b3c9a1-4e2f-4a8b-9c1d-7e3f5a2b1c0d",
  "scope": "read:customers invoices:export",
  "tenant_id": "tnt_enterprise_emea"
}

Refresh Token (Yenileme Belirteci) ile Kesintisiz Oturum Yönetimi

Access Token'ların yaşam süreleri güvenlik gereği kısa tutulur (genellikle 15 dakika ile 1 saat arası). Süre dolduğunda kullanıcının sürekli yeniden oturum açmasını engellemek amacıyla Refresh Token (Yenileme Belirteci) kullanılır. Refresh tokenlar daha uzun ömürlüdür (günler veya aylar) ve yalnızca yeni bir access token talep etmek için kullanılır.

Kurumsal mimarilerde Refresh Token kullanımında Refresh Token Rotation (Dönüşümlü Yenileme Belirteci) stratejisi uygulanmalıdır. Bu mekanizmada, bir refresh token her kullanıldığında geçersiz kılınır ve istemciye yeni bir access token ile birlikte yepyeni bir refresh token teslim edilir. Eğer eski bir refresh token tekrar kullanılmaya çalışılırsa, sistem bunun bir token hırsızlığı olduğunu algılar ve o oturum zincirine bağlı tüm yetkileri derhal iptal eder.

POST /oauth/v2/token HTTP/1.1
Host: auth.enterprise-domain.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=crm_corp_app_prod_8723
&client_secret=sec_98f7a6b5c4d3e2f1a0b9
&refresh_token=rfr_89a7f6e5d4c3b2a10987654321

Token Saklama Koşulları: Tarayıcı ve Sunucu Tarafındaki Güvenlik Önlemleri

Tokenların istemci ortamında saklandığı yer, XSS (Cross-Site Scripting) ve CSRF (Cross-Site Request Forgery) saldırılarına karşı ilk savunma hattıdır.

• Sunucu Taraflı Uygulamalar (Confidential): Tokenlar şifrelenmiş sunucu oturumlarında (Redis, memcached) veya veritabanında güvenli bir şekilde saklanmalıdır. İstemci sırrı ortam değişkenlerinde (Environment Variables / Vault) tutulmalıdır.

• Tarayıcı Tabanlı SPA Uygulamaları: Tokenları localStorage veya sessionStorage içinde saklamak, sitede oluşabilecek en ufak bir XSS açığında tokenların doğrudan çalınmasına yol açar. En güvenli yöntem, tokenları HttpOnly, Secure ve SameSite=Strict (veya SameSite=Lax) bayraklarına sahip çerezlerde (Cookie) saklamak veya BFF (Backend-for-Frontend) mimarisi kullanarak tarayıcıya token hiç iletmeden tüm OAuth trafiğini bir proxy katmanında yönetmektir.

OAuth 2.0 Entegrasyonunda Kritik Güvenlik Zafiyetleri ve Alınması Gereken Önlemler

OAuth 2.0 protokolü teorik olarak çok güvenli olsa da entegrasyon aşamasında yapılan konfigürasyon hataları ve ihmaller sistemi saldırılara açık hale getirebilir. OWASP ve IETF güvenlik raporlarına göre OAuth entegrasyonlarındaki ihlallerin büyük çoğunluğu protokolün kendisinden değil, hatalı implementasyonlardan kaynaklanmaktadır.

Geliştiricilerin ve sistem mimarlarının bilmesi gereken başlıca zafiyet vektörleri ve bunlara karşı alınacak teknik tedbirler aşağıda detaylandırılmıştır.

CSRF Saldırılarına Karşı State Parametresi Kullanımı

OAuth akışında CSRF (Cross-Site Request Forgery), bir saldırganın kurbanın tarayıcısına kendi yetkilendirme kodunu enjekte etmesiyle gerçekleşir. Saldırgan, hedef platformdaki kendi hesabına ait yetkilendirme sürecini başlatır, gelen code değerini yakalar ve bu bağlantıyı kurbana tıklatır. Kurbanın istemci uygulaması, bu kodu kurbanın oturumuyla eşleştirerek saldırganın hesabını kurbanın profiline bağlar.

Bu zafiyeti engellemek için state parametresi zorunlu kılınmalıdır:

1. İstemci, yetkilendirme isteğini başlatırken kriptografik olarak güvenli rastgele bir dizi (Cryptographically Secure Pseudo-Random String - CSRF Token) üretir ve bunu kullanıcının oturumunda (session) saklar.

2. Bu değer /authorize isteğinde state parametresi olarak iletilir.

3. Yetkilendirme sunucusu dönüş yaptığında, istemci dönen state değeri ile oturumdaki değeri birebir karşılaştırır. Eşleşme yoksa işlem derhal reddedilir.

Man-in-the-Middle (MitM) Riskleri ve Kesin TLS/SSL Zorunluluğu

OAuth 2.0 protokolünde yetkilendirme kodları, istemci sırları ve en önemlisi Bearer tokenlar ağ üzerinden açık metin olarak taşınırsa, ağ trafiğini dinleyen herhangi bir saldırgan (MitM / Ortadaki Adam Saldırısı) bu belirteçleri ele geçirebilir. Bearer token modelinde anahtarı elinde tutan herkes yetkili kabul edildiğinden, sızıntı doğrudan yetkisiz erişim anlamına gelir.

Bu sebeple tüm OAuth 2.0 uç noktalarında (/authorize, /token, /userinfo, API endpoints) TLS 1.3 (minimum TLS 1.2) kullanımı zorunlu tutulmalıdır. HTTP üzerinden yapılan tüm çağrılar reddedilmeli ve HSTS (HTTP Strict Transport Security) başlıkları aktif edilmelidir.

Yönlendirme URI (Redirect URI) Zafiyetlerinin Önlenmesi

Yetkilendirme sunucusuna kayıt edilen Redirect URI alanlarında esnek eşleştirme (wildcard veya regex - örn: https://*.example.com/*) kullanmak, açık yönlendirme (Open Redirect) zafiyetlerine zemin hazırlar. Saldırgan, parametre manipülasyonu ile yetkilendirme kodunun kendi kontrolündeki bir alt alana veya sayfaya yönlendirilmesini sağlayabilir.

• Redirect URI eşleştirmeleri tam dize eşleşmesi (Exact String Matching) ile yapılmalıdır.

• localhost yönlendirmeleri yalnızca geliştirme ortamlarında kullanılmalı, canlı (production) ortamda kesinlikle yasaklanmalıdır.

PKCE (Proof Key for Code Exchange) ile Mobil ve SPA Güvenliğini Artırmak

Mobil uygulamalarda özel şema yönlendirmeleri (Custom URI Schemes - örn: myapp://oauth-callback) işletim sistemi düzeyinde diğer kötü niyetli uygulamalar tarafından dinlenebilir. Yetkilendirme kodu çalınsa dahi saldırganın bunu kullanamaması için PKCE (RFC 7636) uygulanır.

PKCE İşleyiş Mantığı:
1. İstemci rastgele bir sır üretir: code_verifier (min 43, max 128 karakter)
2. Bunun SHA256 özetini alır: code_challenge = BASE64URL-ENCODE(SHA256(code_verifier))
3. /authorize isteğine code_challenge ve method=S256 gönderilir.
4. /token takası yapılırken orijinal code_verifier sunucuya iletilir.
5. Yetkilendirme sunucusu verifier'ın özetini alıp baştaki challenge ile karşılaştırır.
   Yalnızca eşleşirse token üretilir.

Standartlara Tam Uyumlu Bir Yetkilendirme Altyapısı Kurmak

Kurumsal bir ekosistemde OAuth 2.0 protokolünü başarıyla devreye almak; sadece token alışverişi kodlamaktan ibaret değildir. Sistem performansı, merkezi loglama, yetki denetimi ve kimlik sağlayıcı (IdP) seçimi gibi mimari kararlar, entegrasyonun uzun vadedeki sürdürülebilirliğini belirler.

Büyük ölçekli yapılarda tüm mikroservislerin tek tek token doğrulaması yapması yerine, trafiği karşılayan bir API Gateway (Kong, Apisix, AWS API Gateway, Azure API Management) katmanı konumlandırılır. API Gateway, gelen istekteki Bearer tokenı karşılar, imzasını ve sürekliliğini doğrular, token içerisindeki yetkileri HTTP başlıklarına dönüştürerek iç ağdaki mikroservislere iletir. Bu tasarım, iç servislerin token karmaşasından izole edilmesini ve mikroservis yanıt sürelerinin hızlanmasını sağlar.

                              KURUMSAL OAUTH 2.0 TOPOLOJİSİ

+------------------+         1. Yetki / Token Talebi         +-------------------------+
|  İstemci Uygulama | <====================================> | Authorization Server    |
| (Web / Mobil/M2M)|                                         | (Keycloak / Okta / IdP) |
+------------------+                                         +-------------------------+
         |
         | 2. API Çağrısı (Bearer JWT)
         v
+--------------------------------------------------------------------------------------+
|                                     API GATEWAY                                      |
|  - TLS Sonlandırma      - JWT İmza Doğrulama (JWKS)       - Rate Limiting            |
|  - Token Introspection  - Scope / Yetki Kontrolü          - Güvenlik Logları (SIEM)  |
+--------------------------------------------------------------------------------------+
         |
         +--------------------------+--------------------------+
         | (Doğrulanmış İç İstek)   | (Doğrulanmış İç İstek)   | (Doğrulanmış İç İstek)
         v                          v                          v
+------------------+       +------------------+       +------------------+
| Müşteri Servisi  |       | Fatura Servisi   |       | Raporlama Servisi|
| (Microservice A) |       | (Microservice B) |       | (Microservice C) |
+------------------+       +------------------+       +------------------+

Ölçeklenebilirlik, Bakım ve Loglama Stratejileri

Güvenli bir OAuth 2.0 altyapısında yetkilendirme sunucusunun oluşturduğu loglar, siber güvenlik operasyon merkezleri (SOC) ve SIEM sistemleri için hayati veri kaynağıdır. Hangi istemcinin, hangi kullanıcı adına, ne zaman ve hangi kapsamlarla token aldığı kayıt altına alınmalıdır.

1. Denetim İzi (Audit Logging): Başarılı ve başarısız tüm token talepleri, geçersiz client_secret denemeleri, eşleşmeyen redirect_uri çağrıları merkezi bir log sistemine (Elasticsearch, Splunk, Datadog) gönderilmelidir.

2. JWKS (JSON Web Key Set) Rotasyonu: Asimetrik anahtar çiftleri belirli periyotlarla (örneğin 90 günde bir) yenilenmeli; eski ve yeni anahtarlar geçiş sürecinde kid (Key ID) parametresi üzerinden uyum içinde çalıştırılmalıdır.

3. Merkezi Token İptali (Revocation - RFC 7009): Bir kullanıcının hesabının dondurulması veya bir yetkinin geri alınması durumunda, o kullanıcıya ait aktif tüm tokenların anında geçersiz kılınmasını sağlayan iptal mekanizmaları kurulmalıdır.

Sonuç olarak; standartlara tam uyumlu bir OAuth 2.0 entegrasyonu, yetkilendirme kodlarının ve tokenların güvenliğini sağlarken sistem bileşenlerinin gevşek bağlı (loosely coupled) kalmasına olanak tanır. Doğru grant seçimi, katı token saklama politikaları ve PKCE gibi modern güvenlik eklentileriyle desteklenmiş bir yapı, kurumsal verilerinizi dış dünyaya güvenle açmanın en sağlam yoludur.