İletişim

Erişim Token'ı (Access Token) Nedir?

Kısa tanım

Erişim token'ı (access token), bir istemcinin korunan bir API'ye belirli izinlerle ve sınırlı bir süre boyunca erişebildiğini gösteren kimlik bilgisidir. OAuth 2.0'da yetkilendirme sunucusu tarafından üretilir ve genellikle Authorization: Bearer başlığıyla gönderilir. Çalınma riskine karşı ömrü kısa tutulur; süresi dolduğunda kullanıcıyı yeniden giriş yaptırmadan yeni bir erişim token'ı almak için daha uzun ömürlü bir refresh token kullanılır.

Diğer adları: Access Token, Erişim belirteci, Bearer token, Refresh token, Yenileme token'ı

Kısa ömürlü ve kapsamlı erişim token'ının API'de kontrol edilip kabul edildiğini veya süresi dolunca reddedildiğini gösteren akış

Token'ı taşıyan, yetkiyi taşır

Erişim token'larının büyük çoğunluğu “bearer” türündedir. RFC 6750'nin tanımıyla bearer token, elinde bulunduran herkesin, meşru sahibiyle aynı şekilde kullanabildiği bir güvenlik belirtecidir; ek bir kanıt istenmez. Bu yüzden token'ı korumak, parolayı korumak kadar önemlidir. Standart gönderim biçimi başlıktır:

GET /v1/faturalar?durum=acik HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6ImsxIn0.eyJzdWIiOiJ1XzQyIn0.c2lnbmF0dXJl

Token'ı URL'de sorgu parametresi olarak göndermek loglara ve geçmişe sızmasına yol açar; OAuth güvenlik rehberi RFC 9700 bunu açıkça yasaklar. Geçersiz veya süresi dolmuş token'a API 401 ve WWW-Authenticate: Bearer error="invalid_token", yetersiz kapsama ise 403 ve insufficient_scope ile yanıt verir.

Opak token mı, JWT mi?

Opak token anlamsız, rastgele bir dizedir. API, token'ın kime ait olduğunu ve hangi izinleri taşıdığını yetkilendirme sunucusuna sorarak (token introspection, RFC 7662) ya da ortak bir veritabanına bakarak öğrenir. İptal anında etkili olur, ama her istekte bir sorgu gerekir.

JWT biçimindeki token ise bilgiyi kendi içinde, imzalı olarak taşır. API imzayı yerelde doğrulayıp kararını verir; yetkilendirme sunucusuna her istekte gitmez. Bedeli, token'ın süresi dolana kadar iptal edilmesinin zor olmasıdır. Hangi biçim seçilirse seçilsin token API için üretilir: istemci uygulama içeriğini okumaya veya ona göre karar vermeye çalışmamalıdır. Kullanıcının kim olduğunu öğrenmek istemcinin işiyse bunun için OpenID Connect'in ID token'ı vardır.

Ömür neden kısa tutulur?

Sızan bir erişim token'ı süresi dolana kadar kullanılabilir. Ömrü dakikalarla, en fazla bir saat civarıyla sınırlamak, olası bir sızıntının zarar penceresini daraltır. Standart belirli bir süre dayatmaz; değer, verinin hassasiyetine ve iptal mekanizmasının ne kadar hızlı çalıştığına göre seçilir. Süreyle birlikte yetkinin genişliği de daraltılmalıdır: RFC 9700, token'ın yalnızca gereken izinleri taşımasını ve belirli bir kaynak sunucusuyla sınırlandırılmasını (audience restriction) önerir.

Refresh token: uzun ömürlü, dar kullanımlı

Kısa ömürlü token'lar kullanıcıyı sık sık yeniden giriş yapmaya zorlamasın diye yetkilendirme sunucusu bir de refresh token verebilir. Refresh token hiçbir zaman API'ye gönderilmez; yalnızca yetkilendirme sunucusunun token endpoint'ine, yeni bir erişim token'ı istemek için gider:

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

grant_type=refresh_token&refresh_token=8xLOxBtZp8&client_id=fatura-app

Uzun ömürlü olduğu için refresh token'ın korunması daha kritiktir. Yaygın önlemler şunlardır:

  • Rotasyon: Her kullanımda yeni bir refresh token verilir ve eskisi geçersiz olur. Eski token tekrar kullanılırsa bu bir çalınma işaretidir; sunucu o token ailesinin tamamını iptal edebilir. RFC 9700'e göre gizli anahtar saklayamayan (public) istemcilerde refresh token'lar ya rotasyonla ya da göndericiye bağlanarak korunmak zorundadır.
  • Göndericiye bağlama: DPoP (RFC 9449) veya mTLS ile token, yalnızca belirli bir anahtarı elinde tutan istemci tarafından kullanılabilir hâle gelir.
  • İki ayrı süre: Belirli bir süre kullanılmayan refresh token düşmeli, kullanılsa bile mutlak bir üst sınırdan sonra yeniden giriş istenmelidir.
  • Çıkışta iptal: Kullanıcı çıkış yaptığında veya parolasını değiştirdiğinde refresh token'lar sunucuda iptal edilmelidir (token revocation, RFC 7009).

Tarayıcıda nerede saklanmalı?

Token'ları localStorage'a yazmak yaygın ama risklidir: sayfada çalışan herhangi bir script, örneğin bir XSS açığından sızan kod, onları okuyup dışarı gönderebilir. OWASP da token'ların localStorage veya sessionStorage'da tutulmamasını önerir. Tarayıcı tabanlı uygulamalarda giderek yaygınlaşan yaklaşım, token'ları sunucu tarafında tutan bir ara katmandır (backend-for-frontend): tarayıcı yalnızca HttpOnly bir oturum çerezi görür, API çağrılarını sunucu token'la yapar. Mobil uygulamalarda ise işletim sisteminin güvenli anahtar deposu (iOS Keychain, Android Keystore) kullanılır.

İlgili terimler

← Sözlüğe dön