Mobil Uygulamalarda Güvenli Oturum Yönetimi Nasıl Yapılır?

Mobil uygulamalarda oturum güvenliği; JSON Web Token (JWT), OAuth 2.0 ve OpenID Connect protokolleri, donanım destekli yerel şifreleme ve SSL/TLS tabanlı veri iletimi mimarileriyle sağlanır. Geliştirme süreçlerinde OWASP Mobile Application Security (MAS) standartlarının referans alınması, kurumsal veri sızıntılarını ve yetkisiz erişim risklerini minimize eder.

Mobil ekosistemde kullanıcı deneyimini bozmadan kurumsal veri güvenliğini sağlamak, doğru kurgulanmış bir kimlik doğrulama ve yetkilendirme mimarisi gerektirir. "Mobil Uygulamalarda Güvenli Oturum Yönetimi Nasıl Yapılır?" sorusunun yanıtı; istemci tarafında donanım seviyesinde korunan güvenli saklama alanlarından ağ katmanındaki sertifika sabitleme (certificate pinning) mekanizmalarına ve sunucu tarafındaki token rotasyon stratejilerine kadar uzanan çok katmanlı bir savunma modelinde yatar. Bu rehberde, mobil platformlarda güvenli oturum döngüsünün nasıl inşa edileceğini, şifreleme pratiklerini, platform tabanlı API entegrasyonlarını ve karşılaşılan teknik riskleri derinlemesine inceliyoruz.

Mobil ve Web Oturum Yönetimi Arasındaki Mimari Farklar

Geleneksel web uygulamalarında oturum yönetimi ağırlıklı olarak durum bilgisi tutan (stateful) çerezler (cookies) ve oturum kimlikleri (session ID) üzerinden yürütülür. Web tarayıcıları, sunucu tarafından Set-Cookie başlığıyla iletilen oturum bilgilerini otomatik olarak depolar ve sonraki her HTTP isteğinde ilgili etki alanına (domain) geri gönderir. Bu süreçte HttpOnly, Secure ve SameSite bayrakları (flags) gibi yerleşik tarayıcı güvenlik mekanizmaları, oturum çerezlerini Siteler Arası Betik Çalıştırma (XSS) ve Siteler Arası İstek Sahteciliği (CSRF) saldırılarına karşı doğal bir koruma kalkanına alır.

Mobil uygulamalarda ise durum bilgisi tutmayan (stateless) API mimarileri standarttır. Yerel (native) veya çapraz platform (cross-platform) mobil uygulamalar, geleneksel bir web tarayıcısı gibi yerleşik çerez havuzlarını varsayılan olarak yönetmez. Bunun yerine kimlik doğrulama, istemci tarafında tutulan ve her REST veya GraphQL API isteğinin Authorization başlığına (genellikle Bearer formatında) açıkça eklenen belirteçler (token) üzerinden sağlanır. Bu durum, istemcinin yetkilendirme belirteçlerini işletim sistemi düzeyinde nerede ve nasıl sakladığı sorusunu birincil güvenlik parametresi haline getirir.

Mobil ekosistemin bir diğer ayırt edici özelliği, cihazların değişken ağ koşullarına ve uzun süreli arka plan (background) yaşam döngülerine maruz kalmasıdır. Web kullanıcıları sekmeyi kapattığında veya tarayıcıyı sonlandırdığında oturum genellikle sonlandırılabilirken; mobil kullanıcılardan her uygulama açılışında yeniden kullanıcı adı ve parola girmeleri beklenemez. Kullanıcı tutundurma (retention) metriklerini korumak adına oturumların haftalarca, hatta aylarca açık kalması istenir. Bu ticari gereksinim, istemci tarafında saklanan yetkilendirme anahtarlarının fiziksel cihaz hırsızlığına, tersine mühendislik (reverse engineering) süreçlerine ve zararlı yazılımlara karşı en üst düzeyde korunmasını zorunlu kılar.

Mobil işletim sistemleri (iOS ve Android), uygulamaları "kum havuzu" (sandbox) adı verilen izole edilmiş işlem alanlarında çalıştırır. Her uygulamanın dosya sistemi diğer uygulamalardan yalıtılmıştır. Ancak cihazın root edilmesi (Android) veya jailbreak yapılması (iOS) durumunda bu kum havuzu mimarisi tamamen devre dışı kalır. Dolayısıyla web geliştiricilerinin nadiren endişelendiği "cihazın çalışma ortamının bizzat saldırganın kontrolünde olması" durumu, mobil oturum yönetiminin temel varsayımı olmak zorundadır.

Zayıf Oturum Yönetiminin Kurumsal Riskleri ve OWASP Standartları

Açık Web Uygulaması Güvenlik Projesi (OWASP), mobil ekosistemdeki en kritik zayıflıkları "OWASP Mobile Top 10" listesi altında sınıflandırmaktadır. Bu sınıflandırmada yer alan M4: Insecure Authentication (Güvensiz Kimlik Doğrulama) ve M5: Insufficient Cryptography (Yetersiz Kriptografi) başlıkları, doğrudan mobil oturum yönetimi zafiyetlerinden beslenir. İstemci tarafında oturum belirteçlerinin yetersiz şifrelenmesi veya sunucu tarafında geçersiz kılınamayan oturum politikaları, işletmeleri geniş çaplı veri ihlalleriyle karşı karşıya bırakır.

Zayıf oturum mimarilerinin doğurduğu en yaygın tehdit "Token Hijacking" (Belirteç Çalma) saldırılarıdır. Mobil uygulamanın kullandığı yetkilendirme belirteçleri düz metin dosyalarında, log çıktılarında veya paylaşılan depolama alanlarında tutulduğunda; cihazdaki kötü amaçlı başka bir uygulama veya cihazı geçici olarak eline geçiren bir üçüncü şahıs bu belirteci kolayca kopyalayabilir. Kopyalanan belirteç, sunucu tarafında oturum geçersiz kılma (invalidation) mekanizması bulunmuyorsa, süresi dolana kadar saldırgana meşru kullanıcı adına işlem yapma yetkisi tanır.

Bir diğer kritik risk ise "Session Fixation" (Sabit Oturum) ve zayıf oturum sonlandırma politikalarıdır. Kullanıcı şifresini değiştirdiğinde, hesabını askıya aldığında veya mobil uygulamadan "Çıkış Yap" (Logout) butonuna bastığında, eğer bu işlem yalnızca yerel veritabanındaki token'ı silmekle kalıyor ve sunucu tarafındaki oturum durumunu geçersiz kılmıyorsa sistem ciddi bir açık barındırıyor demektir. Eski token'a sahip olan bir saldırgan, kullanıcı çıkış yapmış olsa dahi arka uç API'lerine istek atmaya devam edebilir.

Kurumsal ölçekte bu zafiyetlerin faturası yalnızca teknik aksaklıklarla sınırlı kalmaz. KVKK (Kişisel Verilerin Korunması Kanunu), GDPR (Genel Veri Koruma Tüzüğü) ve finansal regülasyonlar (PCI-DSS) uyarınca, yetkisiz oturum kullanımı sonucu gerçekleşen veri sızıntıları milyonlarca liralık idari para cezalarına ve geri döndürülemez itibar kayıplarına yol açar. İşletmelerin siber güvenlik mimarilerini tasarlarken oturum güvenliğini bir ek özellik değil, yasal ve operasyonel bir zorunluluk olarak konumlandırmaları gerekir.

Güvenli Oturum Mimarisi: Temel Protokoller ve Standartlar

Mobil uygulamalarda ölçeklenebilir ve kurumsal düzeyde güvenli bir oturum yapısı kurmanın temel koşulu, endüstri standardı haline gelmiş protokollerin doğru varyasyonlarını uygulamaktır. Özel (proprietary) kimlik doğrulama algoritmaları geliştirmek yerine, küresel güvenlik denetimlerinden geçmiş OAuth 2.0, OpenID Connect (OIDC) ve JSON Web Token (JWT) standartları benimsenmelidir.

JSON Web Token (JWT) Mimarisi ve Kriptografik İmzalama

JSON Web Token (JWT), taraflar arasında JSON nesnesi formatında güvenli veri iletimi sağlayan açık bir standarttır (RFC 7519). Bir JWT; Başlık (Header), Yük (Payload) ve İmza (Signature) olmak üzere üç ana bileşenden oluşur ve bu parçalar nokta (.) karakteriyle ayrılarak Base64URL formatında kodlanır. Mobil oturum yönetiminde JWT, sunucu tarafında oturum tablosu sorgulamaya gerek kalmadan kullanıcının kimliğini ve yetkilerini doğrulamak için ideal bir mekanizmadır.

// JWT Header (Algoritma ve Token Türü)
{
  "alg": "RS256",
  "typ": "JWT"
}

// JWT Payload (Oturum Talepleri / Claims)
{
  "sub": "usr_94a7b28c",
  "name": "Ahmet Yılmaz",
  "roles": ["editor", "analyst"],
  "iat": 1787884800,
  "exp": 1787885700,
  "iss": "https://auth.kurum.com"
}

JWT kullanımında yapılan en büyük hata, Payload alanının şifreli olduğunu varsaymaktır. Base64URL kodlaması bir şifreleme değil, yalnızca bir formatlama yöntemidir; dolayısıyla token'ı ele geçiren herkes payload içeriğini düz metin olarak okuyabilir. Bu nedenle JWT payload'ı içerisine asla kullanıcı parolası, kredi kartı numarası, T.C. kimlik numarası veya özel API anahtarları gibi gizli veriler eklenmemelidir. Payload yalnızca kullanıcının benzersiz kimliği (sub), token'ın geçerlilik süresi (exp) ve rol bazlı yetkileri gibi operasyonel verileri taşımalıdır.

Kriptografik imza katmanında simetrik algoritmalar (örneğin paylaşılan tek bir gizli anahtar kullanan HMAC-SHA256 / HS256) yerine, asimetrik algoritmalar (RSA-SHA256 / RS256 veya ECDSA-SHA256 / ES256) tercih edilmelidir. Asimetrik mimaride kimlik doğrulama sunucusu (Auth Server) token'ı yalnızca kendisinde bulunan özel anahtarla (private key) imzalar; mobil istemciler ve mikroservis API'leri ise sunucunun kamuya açık anahtarıyla (public key - JWKS) bu imzayı doğrular. Bu yaklaşım, gizli anahtarın dağıtılması riskini tamamen ortadan kaldırır.

OAuth 2.0 ve OpenID Connect (OIDC) Entegrasyonu

OAuth 2.0 (RFC 6749), kimlik bilgilerini paylaşmadan üçüncü taraf veya birinci taraf istemcilerin kaynaklara erişmesini sağlayan bir yetkilendirme çerçevesidir. OpenID Connect (OIDC) ise OAuth 2.0 üzerine inşa edilen ve kimlik doğrulama (authentication) katmanını ekleyen bir protokoldür. OIDC entegrasyonu sayesinde mobil uygulama, kullanıcıya ait bir id_token (kimlik kanıtı) ve arka uç servislerine erişmek için bir access_token (yetki anahtarı) elde eder.

Mobil istemciler, güvenli bir sunucu gibi kaynak kodlarını ve istemci sırlarını (client secret) gizli tutamazlar. Tersine mühendislik araçlarıyla (JADX, Ghidra, Frida) derlenmiş bir APK veya IPA dosyası incelenerek kod içine gömülmüş tüm sabit anahtarlar çıkarılabilir. Bu nedenle mobil uygulamalar OAuth 2.0 terminolojisinde "Genel İstemci" (Public Client) olarak sınıflandırılır. Genel istemciler için standart "Authorization Code Grant" akışının tek başına kullanılması güvensizdir.

PKCE (Proof Key for Code Exchange) ile Yetkilendirme Kodu Koruması

Yetkilendirme Kodu Ele Geçirme (Authorization Code Interception) saldırılarını engellemek amacıyla OAuth 2.0 akışına PKCE uzantısı (RFC 7636) entegre edilmelidir. PKCE, mobil uygulamanın her oturum açma isteği için rastgele dinamik bir kriptografik doğrulama dizisi üretmesini sağlar.

Süreç şu adımlarla işler:

1. Mobil istemci kriptografik olarak güvenli rastgele bir dizi üretir (code_verifier).

2. Bu dizinin SHA-256 özeti alınarak Base64URL ile kodlanır ve bir code_challenge oluşturulur.

3. Uygulama, tarayıcı tabanlı kimlik doğrulama ekranını açarken yetkilendirme sunucusuna code_challenge değerini iletir.

4. Kullanıcı kimliğini doğruladıktan sonra sunucu, özel bir URI şeması (Custom URL Scheme) veya Universal Links/App Links aracılığıyla uygulamaya bir authorization_code döner.

5. Uygulama, bu kodu ve ilk başta ürettiği ham code_verifier değerini sunucunun token uç noktasına gönderir.

6. Sunucu, code_verifier'ın özetini alarak ilk adımdaki code_challenge ile eşleştiğini doğrular ve ancak bu eşleşme sağlandığında access_token iletir.

Bu mekanizma sayesinde, cihazdaki kötü niyetli bir başka uygulama Custom URL Scheme trafiğini dinleyerek yetkilendirme kodunu ele geçirse dahi, elinde orijinal code_verifier bulunmadığı için bu kodu access token'a dönüştüremez.

Token'ların Mobil Cihazda Güvenli Saklanması

Mobil uygulama mimarisinde en sık rastlanan güvenlik zafiyetlerinden biri, sunucudan başarıyla alınan access ve refresh token'ların istemci üzerinde standart depolama alanlarına düz metin olarak yazılmasıdır. Android platformunda SharedPreferences, iOS platformunda ise NSUserDefaults veya plist dosyaları şifrelenmemiş XML/JSON tabanlı dosyalardır. Root/Jailbreak yapılmış cihazlarda bu dosyalara dosya yöneticileriyle doğrudan erişilebilir; ayrıca cihaz yedeklemeleri (iTunes veya ADB backup) sırasında bu veriler üçüncü parti bilgisayarlara sızabilir.

+-------------------------------------------------------------------------+
|                  MOBİL GÜVENLİ DEPOLAMA KATMANI                        |
+-------------------------------------------------------------------------+
|  iOS Platformu:                                                         |
|  - Keychain Services API                                                |
|  - Donanım Katmanı: Secure Enclave (AES-256)                            |
|  - Erişim Kısıtı: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly     |
+-------------------------------------------------------------------------+
|  Android Platformu:                                                     |
|  - EncryptedSharedPreferences / AndroidX Security                       |
|  - Donanım Katmanı: Android KeyStore (TEE / StrongBox)                  |
|  - Kripto Algoritma: MasterKeys AES256_GCM                              |
+-------------------------------------------------------------------------+

iOS Mimarisi: Keychain Services ve Secure Enclave Kullanımı

iOS işletim sisteminde oturum belirteçleri ve kriptografik anahtarlar için tasarlanmış resmi depolama alanı Keychain Services API'sidir. Keychain, verileri SQLite tabanlı şifreli bir veritabanında saklar ve bu veritabanının şifre çözme anahtarları donanım seviyesinde izole edilmiş Secure Enclave işlemcisi tarafından yönetilir.

Keychain'e veri yazarken erişilebilirlik seviyesi (accessibility attribute) doğru yapılandırılmalıdır. Kurumsal standartlara göre en güvenli yapılandırma kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly bayrağıdır:

• Bu bayrak, cihaz kilitliyken verilerin şifreli kalmasını ve okunmamasını sağlar.

• ThisDeviceOnly eki, verinin iCloud veya iTunes yedeklemelerine dahil edilmesini engeller; böylece kullanıcı yedeklemesini başka bir cihaza yüklediğinde token yeni cihaza transfer edilmez ve oturumun yeni cihazda yeniden açılması zorunlu kılınır.

Biyometrik doğrulama (Face ID / Touch ID) gerektiren kritik kurumsal uygulamalarda, Keychain öğelerine SecAccessControl nesnesi atanabilir. Bu sayede token okunmak istendiğinde iOS işletim sistemi düzeyinde otomatik olarak biyometrik doğrulama penceresi tetiklenir ve başarılı doğrulama olmadan token bellekten okunamaz.

Android Mimarisi: EncryptedSharedPreferences ve Keystore

Android tarafında güvenli oturum depolaması için Google'ın geliştirdiği AndroidX Security kütüphanesi kapsamında yer alan EncryptedSharedPreferences ve donanım destekli Android KeyStore sistemi kullanılmalıdır.

Bu mimarinin çalışma prensibi çift katmanlı şifrelemeye (Two-Tier Key Encryption) dayanır:

1. Keyset Şifreleme (Master Key): Android KeyStore içerisinde, cihazın Güvenilir Yürütme Ortamı (TEE - Trusted Execution Environment) veya donanımsal StrongBox çipi tarafından desteklenen bir ana anahtar (Master Key) üretilir. Bu anahtar cihazın normal işletim sistemi belleğine asla çıkarılmaz.

2. Veri Şifreleme: EncryptedSharedPreferences, anahtarları AES-256-SIV algoritmasıyla, token değerlerini ise AES-256-GCM algoritmasıyla şifreler. Şifreleme anahtarları yalnızca KeyStore'daki Master Key tarafından çözülebilir.

// Android Güvenli Token Saklama Örneği (Kotlin)
val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .setUserAuthenticationRequired(false) // Biyometri gerekiyorsa true yapılabilir
    .build()

val securePreferences = EncryptedSharedPreferences.create(
    context,
    "secure_session_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

// Token'ı şifreli olarak kaydetme
securePreferences.edit()
    .putString("access_token", accessToken)
    .putString("refresh_token", refreshToken)
    .apply()

Cihazın yedeklenmesi durumunda güvenlik riskini bertaraf etmek için AndroidManifest.xml dosyasında android:allowBackup="false" tanımlanmalı veya backup_rules.xml üzerinden şifreli tercih dosyaları yedekleme kapsamı dışında bırakılmalıdır.

[Mobil İstemci]                                    [Auth Sunucusu]
       |                                                  |
       |--- 1. POST /token (Refresh Token A) ------------>|
       |                                                  | (Token A geçerli mi?)
       |                                                  | (Token A'yı iptal et)
       |                                                  | (Token B üret)
       |<-- 2. Yanıt: Access Token 2 + Refresh Token B ---|
       |                                                  |