Kullanıcı hak taleplerimi JWT jetonunda saklamalı mıyım?

Bir kaynak sunucusuna istekleri doğrulamak için HTTP başlıklarında JWT belirteçleri kullanıyorum. Kaynak sunucu ve kimlik doğrulama sunucusu, Azure'da iki ayrı çalışan rolüdür.

İddiaları jetonda saklamalı mıyım yoksa başka bir şekilde talebe / yanıta mı eklemem gerektiği konusunda karar veremem. Talepler listesi, istemci tarafı UI öğelerinin oluşturulmasını ve sunucudaki verilere erişimi etkiler. Bu nedenle, istek işleme alınmadan önce sunucu tarafından alınan taleplerin gerçek ve doğrulanmış olduğundan emin olmak istiyorum.

İstemlere örnekler: CanEditProductList, CanEditShopDescription, CanReadUserDetails.

Onlar için JWT jetonunu kullanmak istememin nedenleri:

İstemlerin istemci tarafında düzenlenmesine karşı daha iyi koruma (örn. Saldırı talepleri listesi).
Her talepte taleplere bakmaya gerek yok.

JWT belirtecini kullanmak istemememin nedenleri:

Kimlik doğrulama sunucusu daha sonra uygulama merkezli hak talepleri listesini bilmelidir.
Jeton, hack girişinin tek bir noktası haline gelir.
JWT belirteçlerinin uygulama düzeyinde veriler için tasarlanmadığını söyleyen birkaç şey okudum.

Bana öyle geliyor ki, her ikisinin de dezavantajları var, ancak bu iddiaların jetonun içine dahil edilmesine doğru eğildim ve bunu daha önce bununla uğraşan insanlar tarafından yürütmek istiyorum.

NOT: Tüm API istekleri için HTTPS kullanacağım, bu yüzden belirteç 'yeterince' güvenli olacak gibi görünüyor. AngularJS, C #, Web API 2 ve MVC5 kullanıyorum.

— Astravagrant
kaynak

şimdi okuyorum .... ve eğer bir güncelleme istiyorum. Ben aynı şeyle karşı karşıya olduğum gibi, ben ne yaptı ilgilenen olacaktır .. düşünme ve bazı parçaların nasıl çalışmak niyetinde eksik. kullanıcı yetkilendirme jetonu alır, ancak daha sonra iddiaların nasıl taşınacağı ... bulgularınız hakkında açıklayabilir misiniz ... muhtemelen bana yardımcı olacağı için.

— Seabizkit

Yanıtlar:

Benim jwt sadece tanımlayıcı iddiaları (userid, vb) (şifreli) saklar.

Sonra sunucuda (API) jetonu aldığımda bir arama sunucusu tarafı (db veya yerel ağ api çağrısı) yapabilir ve kullanıcı kimliğine (uygulamalar, roller, vb.) Tüm ilişkileri alabilirim.

Bununla birlikte, jwt'ye daha fazla şey eklemek istiyorsanız, büyük olasılıkla her istekte gönderileceğinden, boyutuna dikkat edin, ancak hassas talep verilerini şifrelediğinizden emin olun.

— wchoward
kaynak

Şerefe, DL. API sunucusundaki rolleri vb. Önbelleğe alıyor musunuz veya her istek aldığınızda DB'ye iki kez vuruyor musunuz? (örneğin roller için bir kez ve talep edilen gerçek veriler için bir kez). Önbelleğe alırsanız, hangi yöntemi kullandığınızı bilmek isterim. Ayrıca, zaten şifrelenmiş jetonun 'içerisindeki' kullanıcı kimliğini daha fazla şifrelediğiniz anlamına mı geliyorsunuz? Teşekkürler.

— Astravagrant

Ben henüz benim uygulama içine henüz almadıysanız, ama evet ben bir önbellek sunucusu kullanmayı düşünüyordum böylece db sık vurmak olmaz ve bir rol değişirse önbellek yeni izin vermek için kaldırılabilir rolü kaydedilecek önbellek yüklenecek sorgulandı. Benim durumumda, muhtemelen açık memcached dayalı ama yapılandırmak ve kullanmak daha kolay olan Amazon AWS elsticache kullanmak istiyorum.

— wchoward

Ayrıca kaynak sunucuda gerekli tüm bilgileri almanın ve bir jetonda saklamamanın daha iyi bir fikir olduğunu düşünüyorum.

— Mateusz Migała

yani her istek için kullanıcıların rollerini alırsınız ... hak talepleri ..., bana bir makaleye veya bunun uygulanabilir olduğunu gösteren bir şeye işaret edebilir misiniz? şu anda oturumu kullanıyorum, ama bir şeyler yapmanın daha iyi bir yolunu arıyorsunuz, ancak her istek için arama doğru gelmiyor mu?

— Seabizkit

Kimlik doğrulama (kullanıcının kim olduğu) gibi geliyor ve yetkilendirme (kullanıcının yapmasına izin verilenler) istediğiniz kadar net bir şekilde bölünmüyor.

Kimlik doğrulama sunucusunun kullanıcının ne hakkı olduğunu bilmesini istemiyorsanız, o JWT'deki hak taleplerini tıpkı önerilen gibi kullanıcı kimliği ile sınırlandırın. Yetkilendirme sunucusu olarak bilinen başka bir sunucunun kullanıcının haklarına bakmasını sağlayabilirsiniz.

Yetkilendirme adımı, istemci tarafından ilk kez bir kimlik doğrulama belirteci sunulduğunda kaynak sunucu tarafından gerçekleştirilebilir. Kaynak sunucu daha sonra istemciye yetkilendirme iddiaları içeren bir simge gönderir.

Not: Her iki JWT de farklı anahtarlarla imzalanmalıdır.

Artıları:

Kimlik doğrulama ve yetkilendirme ayrı olarak yönetilir.
Kaynak sunucunun her istekte yetkilendirme araması gerekmez.
Kullanıcı arayüzünün yetkilendirmeyi görme erişimi var, ancak yetkilendirme yapmıyor.

con:

İstemcinin bir yerine iki jetonu işlemesi gerekir.
Yetkilendirme sunucusu eklemek, yönetilecek başka bir hareketli parça ekler.

— Chad Clark
kaynak

Kullanıcı arayüzünde yetkilendirmeyi kontrol ettiğinizde bile, bir istek geldiğinde sunucu tarafında yetkilendirmeyi kontrol etmeniz gerektiğini unutmayın.

— Chad Clark