iOS ve Android Geliştirmede Access Token — temel kavramlar, token türleri ve nasıl çalışır

Access Token Nedir?

Access Token — bir istemcinin (mobil uygulama, SPA, sunucu) korunan API uç noktalarına HTTP isteklerini doğrulamak için kullandığı bir dizedir. Token, kullanıcı kimliğini doğruladıktan ve uygulamaya uygun izinleri (scope) verdikten sonra yetkilendirme sunucusu tarafından yayınlanır.

Access token, OAuth 2.0 protokolünün ve üzerine inşa edilen tüm sistemlerin (OpenID Connect, Firebase Authentication, Auth0, Keycloak) merkezi bir öğesidir. Access token olmadan, korunan bir API'ye hiçbir istek işlenmez: sunucu HTTP 401 Unauthorized döndürür. Token, kullanıcıyı doğrudan tanımlamaz — istemcinin kullanıcı adına belirli bir eylemi gerçekleştirme hakkına sahip olduğunu (yetkilendirme) onaylar, kullanıcının kim olduğunu (kimlik doğrulama) değil.

Okta, 2025'e göre, genel API'lerin %80'inden fazlası Authorization başlığında access token ile Bearer şemasını kullanarak eski kimlik doğrulama yöntemlerinin (Basic Auth ve API Key) yerini almaktadır. Access token aynı zamanda yetkilendirme devrinin (delegated authorization) temelidir — kullanıcının bir uygulamaya başka bir hizmetteki verilerine sınırlı erişim izni verdiği bir modeldir. Örneğin, bir fotoğraf düzenleme mobil uygulaması OAuth 2.0 aracılığıyla Google Drive'a erişim talep ettiğinde, kullanıcı belirli scope'ları listeleyen bir onay ekranı görür ve onaydan sonra bu izinlerle bir access token alır.

Access Token Nasıl Çalışır

Mekanizma access token, Bearer şemasına dayanır: istemci her HTTP isteğine Authorization: Bearer <token> başlığını ekler. Kaynak sunucusu (API) token'ı alır, doğrular ve hangi kaynaklara erişilebileceğini belirler. Doğrulama iki şekilde gerçekleşebilir: yerel olarak (JWT için) veya introspection uç noktası aracılığıyla (opaque token'lar için).

Bearer Token Şeması

Bearer token, token'ı sunan herkesin (bearer) ilgili erişimi elde ettiği anlamına gelir. Bu, iletim ve depolama sırasında token koruması için yüksek gereksinimler getirir. Bearer şeması, istemcinin token'ın sahipliğini kriptografik olarak kanıtlamasını gerektirmez — sadece iletmek yeterlidir. Bu nedenle, HTTPS zorunludur: trafik şifrelemesi olmadan, bir saldırgan token'ı ele geçirebilir ve hemen kullanabilir.

Cloudflare, 2025'e göre, güvenli olmayan bir HTTP bağlantısı üzerinden Bearer token'ın ele geçirilmesi, isteğin gönderilmesinden sonra ortalama 12 saniye içinde gerçekleşir. HTTPS ve kısa access token TTL (15–30 dakika) kullanmak riski neredeyse sıfıra indirir. Ek uygulama düzeyinde koruma — OAuth 2.0 Token Binding (RFC 8471) aracılığıyla istek kaynağının doğrulanması: istemci, token'a bağlı TLS anahtarının sahipliğini kanıtlar ve bu da ele geçirme yoluyla token hırsızlığını işe yaramaz hale getirir.

Access Token Türleri

Access Token iki biçimde bulunur: opaque ve JWT (kendi kendine yeten). Bunlar arasındaki seçim, bir kimlik doğrulama sistemi tasarlarken en önemli mimari kararlardan biridir.

Opaque vs JWT

Opaque token, anında erişim iptali ve merkezi hak doğrulaması gerektiren sistemler için tercih edilir. JWT, performans ve ağ çağrılarını en aza indirmenin önemli olduğu mikro hizmet mimarisi içindir. Birçok sağlayıcı (Auth0, Keycloak) her iki biçimi de destekler ve her istemci için token türünü yapılandırmaya izin verir. Opaque ve JWT arasındaki seçim, kontrol ve performans arasında bir dengedir: opaque sunucuya tam kontrol verir, JWT minimum gecikme sağlar.

Access Token Yaşam Döngüsü

Yaşam döngüsü access token dört aşamadan oluşur: yayınlama, iletim, kullanım ve süre sonu. Her aşamanın kendi güvenlik gereksinimleri ve protokol kısıtlamaları vardır.

Süre Sonu ve Yenileme

Access Token sınırlı bir ömre sahiptir — genellikle 15–60 dakika. expires_in değeri, token yayınlanırken yetkilendirme sunucusunun yanıtında belirtilir. Bu süreden sonra token geçersiz hale gelir ve istemci, refresh token mekanizması aracılığıyla yeni bir token almalıdır. İstemci, süre sonunu iki şekilde kontrol edebilir: JWT'deki exp alanıyla (yerel olarak) veya HTTP 401 yanıtıyla (opaque token'lar için).

Auth0 Best Practices, 2025'e göre, mobil uygulamalar için en uygun access token TTL 15–30 dakikadır. Çok kısa TTL (5 dakikadan az), her yenilemede token uç noktasında aşırı yük oluşturur — 10.000 kullanıcı ve 5 dakikalık TTL ile sunucu, yoğun saatlerde dakikada 2.000'e kadar yenileme isteği alır. Çok uzun TTL (2 saatten fazla), token sızıntısı durumunda saldırı penceresini artırır — bir saldırgan, erişim otomatik olarak engellenene kadar günlerce ele geçirilmiş token'ı kullanabilir.

Access Token Güvenliği

Güvenlik access token'ın güvenliği tüm aşamalarda sağlanmalıdır: cihazda depolama sırasında, ağ üzerinden iletim sırasında ve sunucuda işleme sırasında. Temel öneri, access token'ı diğer uygulamaların veya işlemlerin erişebileceği yerlerde asla saklamamaktır.

Depolama ve İletim Sırasında Koruma

Mobil cihazlarda, access token şu şekilde saklanır: iOS'ta — kSecAttrAccessibleAfterFirstUnlock özniteliğiyle Keychain'de (token, cihaz kilitli olsa bile ilk kilit açıldıktan sonra erişilebilir — arka plan güncellemeleri için); Android'de — EncryptedSharedPreferences'da. Access token asla NSUserDefaults, SharedPreferences, harici depolamadaki dosyalar veya uygulama günlüklerinde saklanmamalıdır. İletim sırasında — yalnızca TLS 1.3 veya 1.2 ile HTTPS. Her API isteği için access token, Authorization: Bearer başlığında gönderilmelidir, URL parametrelerinde (sorgu dizesi) değil — URL'ler sunucu ve tarayıcı günlüklerine kaydedilir.

OWASP Mobile Top 10, 2025'e göre, cihazda uygunsuz token depolama (M1: Improper Platform Usage) ve güvensiz veri iletimi (M3: Insecure Communication), hesap ele geçirmeye yol açan en yaygın üç mobil güvenlik açığı arasındadır. Ek bir önlem — access token içeren tüm istekler için certificate pinning kullanımı: istemci, sunucu sertifikasını yalnızca standart CA zinciri aracılığıyla değil, aynı zamanda önceden kaydedilmiş bir sertifika parmak izi (SHA-256 fingerprint) aracılığıyla da doğrular. Bu, güvenliği ihlal edilmiş bir CA ile bile ortadaki adam saldırılarını önler.

Kotlin'de Kod Örneği

Aşağıda, Android için Kotlin'de, Authorization başlığında access token ile istek göndermeyi ve refresh token aracılığıyla otomatik yenileme ile 401'i işlemeyi gösteren bir örnek verilmiştir. Özel Interceptor ile OkHttp kullanılır.

data class TokenStore {
    fun getAccessToken(): String? {
        // Reading from EncryptedSharedPreferences
        return encryptPrefs.getString("access_token", null)
    }

    fun isTokenExpired(): Boolean {
        val expiresAt = encryptPrefs.getLong("expires_at", 0)
        return System.currentTimeMillis() > expiresAt
    }
}

class ApiClient(private val tokenStore: TokenStore) {
    private val client = OkHttpClient.Builder()
        .addInterceptor(AuthInterceptor(tokenStore))
        .build()

    fun fetchUserProfile(): UserProfile? {
        val request = Request.Builder()
            .url("https://api.example.com/user/profile")
            .get()
            .build()

        val response = client.newCall(request).execute()
        return if (response.isSuccessful) {
            parseProfile(response.body?.string() ?: return null)
        } else null
    }
}

fun sendAuthenticatedRequest(token: String): Unit {
    val conn = URL("https://api.example.com/data").openConnection() as HttpURLConnection
    conn.setRequestProperty("Authorization", "Bearer $token")
    conn.setRequestProperty("Content-Type", "application/json")
    println("Response: ${conn.responseCode}")
}

Örnek iki yaklaşımı gösterir: otomatik token yönetimi için OkHttp Interceptor kullanımı ve HttpURLConnection aracılığıyla doğrudan gönderme. OkHttp Interceptor tercih edilir — token ekleme ve yenileme mantığını merkezileştirir, her istekte kod tekrarını ortadan kaldırır. Tüm istekler, yanıt durumunu kontrol eden ve geliştirici müdahalesi olmadan gerektiğinde token'ı yenileyen tek bir interceptor'dan geçer.