Token'lar ile İlgili Sık Sorulan Sorular
Her metoda ayrı JWT poliçesi tanımlamak güvenlik açısından doğru bir yaklaşım olur mu?
Cevap: Hayır. JWT yapısı gereği tüm metotlara tek seferde uygulanması daha doğru olan bir kimlik doğrulama yöntemidir. Metotlar için yetkilendirme yapılmak istenirse scope tanımı ile Yetkilendirme sayfasında tarif edildiği şekilde bir yaklaşım daha doğru olur.
Eski token'lara ne oluyor?
Cevap: Token Ölümsüz Olsun seçeneği seçilmiş olan bir token hiç bir zaman geçerliliğini yitirmez. Bu seçilmediğinde, arka planda belli aralıklarla çalışmakta olan bir görev, süresi dolmuş OAuth2 token'ları temizler. JWT token'lar ise Apinizer üzerinde zaten tutulmadığı için gönderilirse politika hatasına takılır. Bundan bağımsız olarak token alma isteklerinin log kayıtları ise hiç bir zaman silinmemektedir.
Token Yenileme Sayısı (Refresh Token Count) parametresi ile belirtilen haklar kullanıldığında, en son alınan token kullanılmaya devam edebiliyor mu? Yoksa yaşama süresi içinde bir daha yenilenmeye çalışılırsa bu token geçerliliğini yitirir mi?
Cevap: Token Yenileme Sayısı (Refresh Token Count) parametresi ile belirtilen adeti geçen yenileme talepleri başarısızlıkla sonuçlanır. Bu şekilde yapılan bir yenileme isteği, herhangi bir değişikliğe yol açmaz ve token yaşam süresini doldurana dek yaşamaya devam eder.
Her bir başarılı yenileme, kullanılmakta olan OAuth2 token'ını geçersizleştirerek yeni bir token üretir. JWT token ise yapısı gereği oluşturulduktan sonra değiştirilemeyeceğinden, yenisi oluşsa dahi eskisi de yaşam süresi boyunca yaşamaya devam eder.
Token içerisindeki zaman damgalarının cinsi nedir ve nasıl okunur?
Cevap: Token decode edildiğinde içinde görülebilecek olan iat ve exp alanları token'ın alındığı anı ve geçerli olacağı son anı içinde bulunduran değişkenlerdir. Burada zaman Epoch Time olarak yazılır ve okunabilir hale çevrildiğinde UTC Date formatında görüntülenir. Örnek olarak "1724143156" değeri "Salı, 20 Ağustos 2024 11:39:16 GMT+03:00" olarak okunabilir.
Yaşam süresi bitmiş bir token'a yenileme isteği atılırsa, token yenilenmiş olur mu?
Cevap: Yenileme istekleri token'ın yaşam süresinden bağımsızdır. Önemli olan Yenileme Token'ının (refresh token) yaşam süresidir. Bu süre token alındığı anda başlar. Kullanıcı ister token aldığı anda, isterse (Yenileme Token'ının yaşam süresi dolmadan önceki bir anda olmak üzere) token öldükten sonra yenileme yapar.
- Örnek 1 - Toplamda 60 saniye çalışacak bir token'a 3 kez yenileme hakkı ve her yenilemede 60 saniye yaşam süresi tanımlanmışsa, bu token'ın toplamda 60 + (60 - 60) + (2 * 60) = 180 saniye çalışması mümkündür. Çünkü ilk Yenileme Token'ının süresi token alındığı an itibariyle yaşamaya başlar ve bu örnekte token kadar yaşayabilir.
- Örnek 2 - Toplamda 60 saniye çalışacak bir token'a 3 kez yenileme hakkı ve her yenilemede 180 saniye yaşam süresi tanımlanmışsa bu token'ın toplamda 60 + (180 - 60) + (2 * 180) = 540 saniye çalışması mümkündür. Çünkü ilk Yenileme Token'ının süresi token alındığı an itibariyle yaşamaya başlar ve bu örnekte token öldükten sonra 120 saniye daha yaşayabilir.
Bir API Proxy için alınan token ile başka bir API Proxy'e istek g önderebilir miyim?
Cevap: Hayır, bir token sadece alındığı API Proxy için kullanılabilir. Bununla birlikte, özel bir durum olarak API Proxy Grubu anahtarı ile alınan bir token, grup içindeki bütün API Proxy'ler için kullanılabilir.
Yenileme token'ının hakkını doldurdum, bu sınırı geçecek şekilde yenilemeye çalışırsam ne olur?
Cevap: Yenileme sınırını aşacak ilk yenileme isteğinde bu yenileme isteğinin kullanım hakkının dolduğuna dair bir hata mesajı alınır. Sonraki isteklerde ise bu token temizlenmiş olacağından "token bulunamadı" şeklinde bir hata mesajı alınır. Bu süreçte, son yenilemede edinilen token, yaşam süresi bitmediği sürece kullanılmaya devam edebilir.
Her bir yenileme isteğinde bir daha Yenileme Token'ı geliyor. Bu değişen bir durum mu?
Cevap: Üretilen Yenileme Token'ı, her bir token için tekil ve eşsizdir. Unutulma ihtimaline karşın her bir token yenilemesinde, yenilenen token ile birlikte tekrar gösterilir.
Token Ölümsüz Olsun seçeneği işaretlenmiş iken, dış etkenlerle token'ın kullanılamayacağı durumlar var mıdır?
Cevap: Evet. Aşağıdaki durumlarda token geçerliliğini yitirir:
API Proxy Management ise;
- Token'ın alındığı API Proxy undeploy etmek.
- Token'ın alındığı API Proxy'nin gizli anahtarı(private key) değiştirmek.
- Token, JWT token ise Ortam'ın (Environment) JWT token doğrulama anahtarını değiştirmek.
Credential Management ise;
- Token'ın alındığı Credential'ı silmek.
- Token'ın alındığı Credential' ın gizli anahtarı(private key) değiştirmek.
- Token, JWT token ise Ortam'ın (Environment) JWT token doğrulama anahtarını değiştirmek.
Token alırken "Bu Poliçe'den Yönet" ile "ACL'den Yönet" arasındaki fark nedir?
Cevap: İki seçenek, token üretiminin nerede yönetildiğini belirler. Bu Poliçe'den Yönet (Manage From This Policy) seçildiğinde token, ilgili JWT/OAuth2 politikasının kendi API Anahtarı bilgileriyle /auth/jwt veya /auth/token uç noktasından alınır; token üretimini politikanın kendisi yönetir. ACL'den Yönet (Manage From ACL) seçildiğinde ise token üretimi politikadan ayrılır ve kimlik bilgisi (credential) kayıtları üzerinden /credential/jwt veya /credential/token uç noktasından alınır; böylece birden çok politika aynı kimlik bilgisi havuzunu paylaşabilir. Her iki yöntemin adım adım anlatımı için Token Alma Yöntemleri sayfasına bakabilirsiniz.
OAuth2 token ile JWT token arasındaki fark nedir?
Cevap: JWT token, tüm bilgiyi (scope, son kullanma zamanı, uygulama bilgisi vb.) kendi içinde taşıyan, imzalı ve kendine yeten (self-contained) bir token'dır; Apinizer üzerinde saklanmaz ve doğrulama imza üzerinden yapılır. OAuth2 token ise bilgi taşımayan rastgele bir dizedir (opaque); ilgili bilgiler sunucu tarafında saklanır ve her istekte sunucuya sorularak doğrulanır. Dağıtık ve stateless doğrulama ya da alıcı sisteme bilgi taşımak isteniyorsa JWT, merkezi saklama ve iptal kontrolü isteniyorsa OAuth2 daha uygundur.
Aldığım token ile birlikte scope da dönüyor mu?
Cevap: Evet. Token isteğinde çözümlenen scope, alınan token ile birlikte yanıt gövdesinde scope alanı olarak döner. JWT alındığında scope ayrıca token'ın içine de gömülür; OAuth2'de ise yalnızca yanıt gövdesinde yer alır. Bu davranış hem Bu Poliçe'den Yönet hem de ACL'den Yönet modunda aynıdır. Yanıttaki scope alanının adını veya scope'un yanıta dahil edilip edilmeyeceğini Token Yönetim Ayarları sayfasından yapılandırabilirsiniz.
Talep ettiğim scope'lardan bazıları tanımlı değilse token alabilir miyim?
Cevap: Bu, Token Yönetim Ayarları sayfasındaki Scope Uyumsuzluğunda Davranış ayarına bağlıdır. Katı (varsayılan) modda, talep edilen scope'lardan herhangi biri tanımlı değilse token verilmez ve HTTP 401 invalid_scope hatası döner. Esnek modda yalnızca tanımlı olan scope'larla token verilir, geçersiz olanlar sessizce atılır. İsteği Yoksay modunda talep edilen liste yoksayılır ve token, tanımlı tüm scope'larla verilir.
Scope istedim ama yanıtta scope boş geldi veya hiç gelmedi, neden?
Cevap: En sık karşılaşılan üç neden vardır. Birincisi, ilgili kullanıcıya veya kimlik bilgisine rol (scope) tanımlı olmamasıdır; bu durumda Katı modda bile scope boş döner. İkincisi, isteğin hiç scope içermemesi ve İstekte Scope Yoksa Davranış ayarının varsayılan olan Scope'suz Token olmasıdır; bu durumda scope alanı yanıta eklenmez. Üçüncüsü, Token Yönetim Ayarları sayfasında Scope alan ını response'a dahil et seçeneğinin kapatılmış olmasıdır. Kullanıcıya rol tanımlama adımları için Token Alma Yöntemleri sayfasındaki scope bölümüne bakabilirsiniz.
Token yanıtındaki alan isimlerini (örn. access_token, scope) değiştirebilir miyim?
Cevap: Evet. Token Yönetim Ayarları sayfasındaki Token Yanıt Alan İsimleri bölümünden access_token, token_type, expires_in, refresh_token ve scope alanlarının yanıt gövdesinde döndüğü adları değiştirebilirsiniz. access_token dışındaki alanlar tamamen yanıttan çıkarılabilir; access_token ise RFC 6749 §5.1 gereği zorunlu olduğundan yalnızca yeniden adlandırılabilir, kaldırılamaz.