Uygulama Geliştirmede Session Token — Nedir, Çalışma Prensibi ve JWT’den Farkları

Session Token Nedir?

Session Token (oturum tanımlayıcısı), sunucunun kullanıcı kimlik doğrulamasından sonra oluşturduğu ve oturum verileriyle ilişkilendirdiği benzersiz bir dizedir. Belirteç, kullanıcı hakkında hiçbir bilgi içermez — bu yalnızca sunucuda depolanan verilere açılan bir anahtardır. Bu yaklaşıma stateful kimlik doğrulama denir: sunucu her etkin oturumun durumunu saklar ve her istekte bunu doğrular.

Oturum verileri şunları içerir: kullanıcı kimliği, oturum açma zamanı, IP adresi, user-agent, izin listesi, son etkinlik zamanı. İstemci bir session token ile istek gönderdiğinde, sunucu oturum deposunda ilgili kaydı bulur, geçerliliğini kontrol eder ve isteği işlemek için verileri alır. Oturum kaydı yoksa veya süresi dolmuşsa, sunucu bir kimlik doğrulama hatası döndürür ve yeniden oturum açılmasını ister.

OWASP, 2025’e göre, session token anında erişim iptali gerektiren uygulamalar için standart olmaya devam etmektedir — örneğin, bir yöneticinin bir kullanıcının oturumunu anında sonlandırabilmesi gereken bankacılık sistemleri ve kurumsal portallarda. Bu tür sistemlerde, session token, ek engelleme mekanizmaları olmadan stateless belirteçler için ulaşılamaz olan tam erişim kontrolü sağlar.

Session Token Nasıl Çalışır

Süreç, istemcinin kimlik bilgilerini kimlik doğrulama sunucusuna göndermesiyle başlar. Sunucu, kullanıcı adını ve şifreyi doğrular, depoda (genellikle Redis veya veritabanı) bir oturum kaydı oluşturur ve istemciye benzersiz bir session token döndürür. İstemci belirteci kaydeder ve sonraki her istekle birlikte gönderir; sunucu da her seferinde oturumun varlığını ve geçerliliğini kontrol eder.

Sunucu Oturumu ve Depolama

Redis, bellek içi depolama ve TTL (yaşam süresi) desteği sayesinde en popüler oturum deposudur. Her oturum, anahtarın session token ve değerin oturum verilerini içeren bir JSON nesnesi olduğu bir anahtar-değer çifti olarak saklanır. TTL, süresi dolan oturumları otomatik olarak kaldırır. Alternatifler: Memcached (yalnızca bellek, diskte kalıcılık yok), PostgreSQL/MySQL (kalıcı ancak daha yavaş) ve DynamoDB (AWS altyapısı için).

Redis’te oturum yapısı örneği: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Sunucu, her istekte lastAccess’i güncelleyerek hareketsizlik zaman aşımı uygulanmasına olanak tanır — bir hareketsizlik döneminden sonra oturumun otomatik olarak sonlandırılması.

Cookie vs Başlık

Session Token iki şekilde iletilebilir: HTTP çerezi yoluyla veya Authorization HTTP başlığı yoluyla. Çerezler, web uygulamaları için geleneksel yöntemdir: sunucu, HttpOnly (JavaScript’ten erişilemez), Secure (yalnızca HTTPS) ve SameSite (CSRF koruması) bayraklarıyla bir çerez ayarlar. Mobil uygulamalar için, yerel istemcilerde çerez mekanizması her zaman uygun olmadığından Authorization: Bearer <session_token> başlığı daha yaygın olarak kullanılır.

Session Token Yaşam Döngüsü

Session token’ın yaşam döngüsü üç aşamadan oluşur: oluşturma, etkin oturumu sürdürme ve sonlandırma. Her aşama, belirtecin sızmasını veya ele geçirilmesini önlemek için uygun güvenlik yapılandırması gerektirir.

Oluşturma, Saklama ve Silme

Oluşturma — sunucu, 128–256 bit uzunluğunda kriptografik olarak güvenli rastgele bir dize oluşturur (örneğin, Java’da SecureRandom veya Python’da os.urandom aracılığıyla). Belirteç tahmin edilemez olmalıdır — entropi olmadan UUID veya zaman damgası kullanımı kabul edilemez. İstemcide saklama: iOS’ta — Keychain, Android’de — EncryptedSharedPreferences, web’de — HttpOnly çerezi. Silme, çıkış yapıldığında gerçekleşir: istemci belirteci depodan kaldırır, sunucu Redis’ten oturum kaydını siler. Çıkış yapıldıktan sonra session token kullanılamaz hale gelir — sunucu ilgili bir kayıt bulamaz.

SANS Institute, 2025’e göre, oturum sonlandırmanın doğru şekilde uygulanması (sunucu tarafı temizlikle çıkış), çalınmış belirteçleri kullanan saldırıların %70’e kadarını önler. Yalnızca istemcide belirteci silmek değil, aynı zamanda sunucuda oturumu geçersiz kılmak da kritik öneme sahiptir.

Session Token vs JWT

Session Token ve JWT, kimlik doğrulamada iki farklı yaklaşımı temsil eder. Session Token stateful’dur (sunucu durumu saklar), JWT stateless’tir (veriler belirtecin içinde). Aralarındaki seçim, uygulama mimarisine ve güvenlik gereksinimlerine bağlıdır.

Session Token Ne Zaman Seçilmeli

Session Token şu durumlarda tercih edilir: anında oturum iptali gerektiğinde (bankacılık, yönetim panelleri), uygulama paylaşımlı Redis ile bir veya daha fazla sunucuda çalışıyorsa, oturum verileri büyükse ve JWT’ye sığmıyorsa veya ekip belirteç kod çözme yoluyla veri sızıntısı riskini en aza indirmek istiyorsa. Bu senaryolarda, session token şüpheli etkinlik durumunda anında erişim engelleme sağlar — Redis’ten tek bir kaydı silmek, kullanıcının tüm oturumlarını geçersiz kılmak için yeterlidir.

Redis, 2025’e göre, oturum anahtarı düzeyinde TTL (EXPIRE komutu) kullanımı, arka plan görevlerinde ek yük olmadan süresi dolan oturumları otomatik olarak temizler. 1 saat TTL ve 10.000 eş zamanlı kullanıcı yüküne sahip oturumlar için Redis, 1 KB oturum boyutunda yaklaşık 1 GB RAM tüketir ve bu da onu çoğu uygulama için uygun maliyetli hale getirir.

Session Token Güvenliği

Session token’ın güvenliği iki ilkeye dayanır: belirteç tahmin edilemez olmalı ve iletim ve depolama sırasında korunmalıdır. Başlıca tehditler, belirtecin ele geçirilmesi (man-in-the-middle, XSS), tahmin edilmesi (zayıf oluşturma) ve oturum sabitlemesidir (session fixation).

Belirteç Hırsızlığına Karşı Koruma

Koruma şunları içerir: belirteçli tüm istekler için HTTPS kullanımı, kısa oturum TTL’si (15–60 dakika hareketsizlik) ayarlama, oturumu IP ve user-agent’e bağlama (her istekte ek doğrulama), çerezler için Secure ve HttpOnly bayraklarını kullanma ve hassas işlemlerden (şifre değişikliği, yetki yükseltme) sonra düzenli session token rotasyonu. OWASP ayrıca, girişten sonra yeni bir oturum oluştururken eski oturumu geçersiz kılan Oturum Yönetimi uygulanmasını önerir — bu, oturum sabitlemesini önler.

OWASP ASVS, 2025’e göre, bir oturum en az iki faktöre bağlı olmalıdır: belirtecin kendisi (istemcinin sahip olduğu) ve IP/user-agent (sunucunun bildiği). Bu faktörler eşleşmezse, sunucu oturumu sonlandırmalı ve yeniden kimlik doğrulaması istemelidir.

Kotlin’de Uygulama Örneği

Aşağıda, Spring Boot ve Redis kullanarak Kotlin’de sunucu tarafı session token uygulaması örneği verilmiştir. Sunucu, SecureRandom aracılığıyla kriptografik olarak güvenli bir belirteç oluşturur, TTL ile Redis’te oturumu kaydeder ve her istekte doğrular. Kod üç ana işlemi gösterir: oturum oluşturma, doğrulama ve geçersiz kılma.

data class Session(
    val userId: Long,
    val role: String,
    val createdAt: Long,
    val lastAccess: Long
)

object SessionManager {
    private val redis = JedisPool("localhost", 6379)

    fun createSession(userId: Long, role: String): String {
        val token = generateSecureToken()
        val session = Session(userId, role, now(), now())
        redis.resource.use { conn ->
            conn.setex("session:$token", 3600, toJson(session))
        }
        return token
    }

    fun validateSession(token: String): Session? {
        redis.resource.use { conn ->
            val json = conn.get("session:$token") ?: return null
            return fromJson(json)
        }
    }

    fun invalidateSession(token: String) {
        redis.resource.use { it.del("session:$token") }
    }

    private fun generateSecureToken(): String {
        val bytes = ByteArray(32)
        SecureRandom().nextBytes(bytes)
        return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)
    }
}

Bu uygulama, Redis’e iş parçacığı güvenli bağlantı için JedisPool kullanır. createSession yöntemi, 1 saatlik (3600 saniye) bir TTL ayarlar — bu süreden sonra Redis kaydı otomatik olarak siler. validateSession yöntemi, var olmayan veya süresi dolmuş oturumlar için null döndürür ve sunucunun geçersiz bir belirteçle isteği doğru şekilde işlemesine ve HTTP 401 döndürmesine olanak tanır.