JWT (JSON Web Token) sona erme süresinin otomatik uzatılması

Yeni REST API'mıza JWT tabanlı kimlik doğrulaması uygulamak istiyorum. Ancak son kullanma süresi belirteçte ayarlandığından, otomatik olarak uzatmak mümkün mü? Kullanıcıların uygulamayı o dönemde etkin bir şekilde kullanıyorlarsa her X dakikada bir oturum açmasını istemiyorum. Bu büyük bir UX başarısızlığı olurdu.

Ancak sona erme süresini uzatmak yeni bir jeton oluşturur (ve eskisi sona erene kadar hala geçerlidir). Ve her istekten sonra yeni bir jeton oluşturmak bana aptalca geliyor. Aynı anda birden fazla jeton geçerli olduğunda güvenlik sorunu gibi görünür. Tabii ki eski kullanılmış olanı bir kara liste kullanarak geçersiz kılabilirim ama simgeleri saklamam gerekirdi. Ve JWT'nin avantajlarından biri de depolama değildir.

Auth0'ın bunu nasıl çözdüğünü buldum. Sadece JWT jetonunu değil, aynı zamanda bir yenileme jetonunu da kullanırlar: https://docs.auth0.com/refresh-token

Ama yine de, bunu uygulamak için (Auth0 olmadan) yenileme jetonlarını saklamam ve sürelerini muhafaza etmem gerekir. O zaman gerçek fayda nedir? Neden yalnızca bir jeton (JWT değil) ve son kullanma tarihini sunucuda tutmuyorsunuz?

Başka seçenekler var mı? JWT kullanımı bu senaryo için uygun değil mi?

Auth0'da çalışıyorum ve yenileme belirteci özelliğinin tasarımında yer aldım.

Her şey uygulama türüne bağlıdır ve burada önerilen yaklaşımımız.

Web uygulamaları

İyi bir desen, simgenin süresi dolmadan yenilemektir.

Simgenin sona erme tarihini bir hafta olarak ayarlayın ve kullanıcı web uygulamasını her açışında ve her saatte bir simgeyi yenileyin. Bir kullanıcı uygulamayı bir haftadan daha uzun bir süre boyunca açmazsa, tekrar giriş yapmak zorunda kalacak ve bu kabul edilebilir bir web uygulaması UX.

Jetonu yenilemek için API'nızın geçerli, süresi dolmamış bir JWT alan ve yeni sona erme alanı ile aynı imzalı JWT'yi döndüren yeni bir uç noktaya ihtiyacı vardır. Ardından web uygulaması belirteci bir yerde saklar.

Mobil / Yerel uygulamalar

Çoğu yerel uygulama bir kez ve sadece bir kez oturum açar.

Fikir, yenileme kodunun hiçbir zaman sona ermemesi ve her zaman geçerli bir JWT ile değiştirilebilmesidir.

Asla sona ermeyen bir belirteçle ilgili sorun, asla asla anlamına gelmez. Telefonunuzu kaybederseniz ne yaparsınız? Bu nedenle, kullanıcı tarafından bir şekilde tanımlanabilir olması gerekir ve uygulamanın erişimi iptal etmek için bir yol sağlaması gerekir. Cihazın adını kullanmaya karar verdik, örneğin "maryo'nun iPad'i". Daha sonra kullanıcı uygulamaya gidebilir ve "maryo'nun iPad" ine erişimi iptal edebilir.

Başka bir yaklaşım, belirli olaylarda yenileme jetonunu iptal etmektir. İlginç bir olay parolayı değiştiriyor.

JWT'nin bu kullanım durumları için yararlı olmadığına inanıyoruz, bu yüzden rastgele oluşturulmuş bir dize kullanıyoruz ve onu yanımızda saklıyoruz.

Yetkilendirmeyi kendiniz ele aldığınızda (yani Yetkilendirme0 gibi bir sağlayıcı kullanmayın) aşağıdakiler işe yarayabilir:

1. Diyelim ki 15 dk.
2. Uygulama, jeton gerektiren herhangi bir işlemden önce jeton son kullanma tarihini kontrol eder (jeton son kullanma tarihini içerir). Simgenin süresi dolmuşsa, ilk olarak API'dan jetonu 'yenilemesini' ister (bu UX'e şeffaf bir şekilde yapılır).
3. API jeton yenileme isteği alır, ancak önce kullanıcı veritabanına o kullanıcı profiline karşı 'reauth' bayrağının ayarlanıp ayarlanmadığını (jeton kullanıcı kimliği içerebilir) kontrol eder. Bayrak varsa, jeton yenilemesi reddedilir, aksi takdirde yeni bir jeton verilir.
4. Tekrar et.

Örneğin kullanıcı parolasını sıfırladığında, veritabanı arka ucundaki 'reauth' bayrağı ayarlanır. Kullanıcı bir daha oturum açtığında bayrak kaldırılır.

Ayrıca, bir kullanıcının en az 72 saatte bir giriş yapması gereken bir politikanız olduğunu varsayalım. Bu durumda, API jeton yenileme mantığınız da kullanıcının veritabanından son giriş tarihini kontrol eder ve bu temelde jeton yenilemesini reddeder / izin verir.

Uygulamalarımızı arka uçta RESTful apis ile HTML5'e taşırken dolaşıyordum. Geldiğim çözüm şuydu:

1. Müşteriye, başarılı bir şekilde oturum açtıktan sonra oturum süresi 30 dakika olan (veya her zamanki sunucu tarafı oturum süresi ne olursa olsun) bir jeton verilir.
2. İstemci tarafındaki zamanlayıcı, süresinin dolmasından önce belirteci yenilemek üzere bir hizmeti çağırmak için oluşturulur. Yeni jeton, gelecekteki aramalarda mevcut olanın yerini alacaktır.

Gördüğünüz gibi, bu sık sık yenileme belirteci isteklerini azaltır. Kullanıcı, yenileme belirteci çağrısı tetiklenmeden önce tarayıcıyı / uygulamayı kapatırsa, önceki belirtecin süresi dolar ve kullanıcının yeniden oturum açması gerekir.

Kullanıcı hareketsizliğini karşılamak için daha karmaşık bir strateji uygulanabilir (örneğin, açık bir tarayıcı sekmesini ihmal ettiniz). Bu durumda, yenileme belirteci çağrısı, tanımlanan oturum süresini aşmaması gereken beklenen sona erme süresini içermelidir. Uygulamanın buna göre son kullanıcı etkileşimini takip etmesi gerekecektir.

Uzun süre sonu belirleme fikrini sevmiyorum, bu nedenle bu yaklaşım, daha az sıklıkta kimlik doğrulaması gerektiren yerel uygulamalarla iyi çalışmayabilir.

Arka uçta ek güvenli depolama olmadan JWT'leri geçersiz kılmak için alternatif bir çözüm jwt_version, kullanıcılar tablosuna yeni bir tamsayı sütunu uygulamaktır . Kullanıcı oturumu kapatmak veya mevcut belirteçlerin süresinin dolmasını istiyorsa, jwt_versionalanı arttırır.

Yeni bir JWT oluştururken, jwt_versionJWT yüküne kodlayın , isteğe bağlı olarak yeni JWT'nin tüm diğerlerinin yerini alması gerekiyorsa değeri önceden artırın.

JWT doğrulanırken jwt_versionalan ile karşılaştırılır user_idve yetkilendirme yalnızca eşleşirse verilir.

Güzel bir soru- ve sorunun kendisinde zengin bilgi var.

Makale Yenile Kredi: Ne zaman bunların kullanımı ve JWTS ile nasıl etkileşime Bu senaryo için iyi bir fikir verir. Bazı noktalar: -

• Yenileme belirteçleri, yeni bir erişim belirteci almak için gerekli bilgileri taşır.
• Yenileme simgelerinin süresi de dolar ancak oldukça uzun ömürlüdür.
• Yenileme simgeleri sızdırmadığından emin olmak için genellikle katı depolama gereksinimlerine tabidir.
• Yetkilendirme sunucusu tarafından da kara listeye alınabilirler.

Ayrıca auth0 / angular-jwt angularjs'e de göz atın

Web API için. ASP .NET Web API 2 ve Owin kullanarak AngularJS Uygulamasında OAuth Yenileme İşaretlerini Etkinleştir'i okuyun

Aslında bunu PHP'de API için bir istemci kütüphanesi yapmak için Guzzle istemcisini kullanarak uyguladım, ancak konsept diğer platformlar için çalışmalıdır.

Temel olarak, iki jeton yayınlıyorum, kısa (5 dakika) bir ve uzun bir hafta sonra sona erecek. İstemci kitaplığı, bazı isteklere 401 yanıtı alırsa kısa belirtecin bir yenilemesini denemek için ara katman yazılımı kullanır. Daha sonra orijinal isteği tekrar deneyecek ve eğer yenileyebiliyorsa, kullanıcıya şeffaf bir şekilde doğru yanıtı alacaktır. Başarısız olursa, sadece 401'i kullanıcıya gönderir.

Kısa jetonun süresi dolmuş ancak yine de orijinalse ve uzun jeton geçerli ve orijinalse, uzun jetonun kimlik doğrulaması yaptığı hizmette özel bir uç nokta kullanarak kısa jetonu yenileyecektir (bu, kullanılabileceği tek şeydir). Daha sonra yeni bir uzun jeton almak için kısa jetonu kullanacak, böylece kısa jetonu her yenilediğinde bir hafta daha uzatacaktır.

Bu yaklaşım ayrıca, bir kara liste listesini saklamak zorunda kalmadan kullanımımız için kabul edilebilir olan en fazla 5 dakika içinde erişimi iptal etmemizi sağlar.

Geç düzenleme: Kafamda taze olduktan sonra bu ayları yeniden okumak, daha kısa çağrıları yenilerken erişimi iptal edebileceğinizi belirtmeliyim, çünkü daha pahalı çağrılar için bir fırsat verir (örneğin, kullanıcının yasaklandı) hizmetinize yapılan her çağrıda ücret ödemeden.

Aşağıda, JWT erişim simgenizi iptal etme adımları verilmiştir:

1) Giriş yaptığınızda, istemciye yanıt olarak 2 jeton (Erişim belirteci, Yenileme belirteci) gönderin.
2) Erişim belirteci daha az sona erme süresine sahip olacak ve Yenileme uzun süre sona erecektir.
3) Müşteri (Ön uç) yenileme kodunu yerel deposunda ve erişim kodunu çerezlerde saklar.
4) Müşteri, apis çağırmak için erişim belirtecini kullanacaktır. Ancak süresi dolduğunda, yerel depolama alanından yenileme jetonunu seçin ve yeni jetonu almak için auth server api'yi arayın.
5) Kimlik doğrulama sunucunuzda, yenileme belirtecini kabul edecek ve geçerliliğini kontrol edecek ve yeni bir erişim belirteci döndürecek bir API görünür.
6) Yenileme belirtecinin süresi dolduğunda, Kullanıcı oturumu kapatır.

Daha fazla ayrıntıya ihtiyacınız varsa lütfen bana bildirin, kodu (Java + Spring boot) da paylaşabilirim.

JWT-autorefresh

Düğüm (React / Redux / Universal JS) kullanıyorsanız yükleyebilirsiniz npm i -S jwt-autorefresh.

Bu kütüphane, JWT belirteçlerinin yenilenmesini, erişim belirtecinin süresinin dolmasından önce (belirteçte kodlanan exp talebine dayalı olarak) kullanıcı tarafından hesaplanan saniye sayısına göre zamanlar. Kapsamlı bir test paketine sahiptir ve herhangi bir garip etkinliğe ortamınızdan yanlış yapılandırmalarla ilgili açıklayıcı bir mesaj eşlik etmesini sağlamak için birkaç koşulu kontrol eder.

Tam örnek uygulama

import autorefresh from 'jwt-autorefresh'

/** Events in your app that are triggered when your user becomes authorized or deauthorized. */
import { onAuthorize, onDeauthorize } from './events'

/** Your refresh token mechanism, returning a promise that resolves to the new access tokenFunction (library does not care about your method of persisting tokens) */
const refresh = () => {
  const init =  { method: 'POST'
                , headers: { 'Content-Type': `application/x-www-form-urlencoded` }
                , body: `refresh_token=${localStorage.refresh_token}&grant_type=refresh_token`
                }
  return fetch('/oauth/token', init)
    .then(res => res.json())
    .then(({ token_type, access_token, expires_in, refresh_token }) => {
      localStorage.access_token = access_token
      localStorage.refresh_token = refresh_token
      return access_token
    })
}

/** You supply a leadSeconds number or function that generates a number of seconds that the refresh should occur prior to the access token expiring */
const leadSeconds = () => {
  /** Generate random additional seconds (up to 30 in this case) to append to the lead time to ensure multiple clients dont schedule simultaneous refresh */
  const jitter = Math.floor(Math.random() * 30)

  /** Schedule autorefresh to occur 60 to 90 seconds prior to token expiration */
  return 60 + jitter
}

let start = autorefresh({ refresh, leadSeconds })
let cancel = () => {}
onAuthorize(access_token => {
  cancel()
  cancel = start(access_token)
})

onDeauthorize(() => cancel())

yasal uyarı: Ben bakıcıyım

Belirteç verilerine bir değişken ekleyerek bu sorunu çözdüm:

softexp - I set this to 5 mins (300 seconds)

expiresInKullanıcının tekrar oturum açmak zorunda kalması için seçeneği istediğiniz zamana ayarlıyorum . Maden 30 dakikaya ayarlandı. Bu, değerinden büyük olmalıdır softexp.

İstemci tarafı uygulamam sunucu API'sına istek gönderdiğinde (belirtecin gerekli olduğu, örn. Müşteri listesi sayfası), sunucu gönderilen belirtecin orijinal geçerlilik ( expiresIn) değerine göre hala geçerli olup olmadığını kontrol eder . Geçerli değilse, sunucu bu hataya özgü bir durumla yanıt verir, örn. INVALID_TOKEN.

Belirteç expiredIndeğere bağlı olarak hala geçerliyse , ancak değeri zaten aştıysa softexp, sunucu bu hata için ayrı bir durumla yanıt verir, örn. EXPIRED_TOKEN:

(Math.floor(Date.now() / 1000) > decoded.softexp)

İstemci tarafında, EXPIRED_TOKENyanıt alırsa , sunucuya bir yenileme isteği göndererek belirteci otomatik olarak yenilemelidir. Bu kullanıcı için şeffaf ve istemci uygulaması otomatik olarak halledilir.

Sunucudaki yenileme yöntemi, belirtecin hala geçerli olup olmadığını denetlemelidir:

jwt.verify(token, secret, (err, decoded) => {})

Sunucu, yukarıdaki yöntemde başarısız olursa belirteçleri yenilemeyi reddedecektir.

Bu yaklaşıma ne dersiniz:

• Her istemci isteği için, sunucu belirtecin sona erme zamanını (currentTime - lastAccessTime) ile karşılaştırır.
• Eğer expirationtime <(CurrentTime - lastAccessedTime) , bu CurrentTime son lastAccessedTime değiştirir.
• Tarayıcıda expirationTime değerini aşan bir süre boyunca herhangi bir işlem yapılmaması durumunda veya tarayıcı penceresinin kapatılması ve expirationTime> (currentTime - lastAccessedTime) durumunda , sunucu jetonun süresini doldurabilir ve kullanıcıdan tekrar oturum açmasını isteyebilir.

Bu durumda jetonu yenilemek için ek son noktaya ihtiyacımız yok. Herhangi bir ücret takdir ediyorum.

Bugün, birçok insan algılanan basitlik uğruna neyi bıraktıklarının farkında olmadan JWT'lerle oturum yönetimi yapmayı tercih ediyor . Cevabım soruların 2. bölümünde ele alınmaktadır:

O zaman gerçek fayda nedir? Neden yalnızca bir jeton (JWT değil) ve son kullanma tarihini sunucuda tutmuyorsunuz?

Başka seçenekler var mı? JWT kullanımı bu senaryo için uygun değil mi?

JWT'ler temel oturum yönetimini bazı sınırlamalarla destekleyebilir. Kendini tanımlayan belirteçler olarak, sunucu tarafında herhangi bir durum gerektirmezler. Bu onları çekici kılar. Örneğin, hizmetin bir kalıcılık katmanı yoksa, yalnızca oturum yönetimi için bir katman getirmesi gerekmez.

Ancak, vatansızlık da eksikliklerinin önde gelen nedenidir. Yalnızca bir kez sabit içerik ve sona erme tarihi ile yayınlandıklarından, tipik bir oturum yönetimi kurulumuyla istediğiniz şeyleri yapamazsınız.

Yani, talep üzerine onları geçersiz kılamazsınız. Bu, önceden verilen belirteçlerin süresinin sona ermesinin bir yolu olmadığından güvenli bir çıkış yapılamayacağınız anlamına gelir . Aynı nedenden ötürü boşta kalma zaman aşımı da uygulayamazsınız . Bir çözüm bir kara liste tutmaktır, ancak bu durumu ortaya çıkarır.

Bu sakıncaları daha ayrıntılı olarak açıklayan bir yazı yazdım . Açık olmak gerekirse, daha fazla karmaşıklık ekleyerek (kayan oturumlar, yenileme jetonları vb.) Bunları geçici olarak çözebilirsiniz.

Diğer seçeneklere gelince, müşterileriniz hizmetinizle yalnızca bir tarayıcı aracılığıyla etkileşime giriyorsa, çerez tabanlı bir oturum yönetimi çözümü kullanmanızı önemle tavsiye ederim. Ayrıca, şu anda web'de yaygın olarak kullanılan bir liste kimlik doğrulama yöntemlerini derledim .