REST tabanlı uygulama için JWT kimlik doğrulaması için kurumsal kalıplar?

JWT spesifikasyonu sadece yükü ve nasıl gönderildiğini açıklar, ancak kimlik doğrulama protokolünü açık bırakır, bu da esnekliğe izin verir, ancak maalesef esneklik anti-desenlere ve yanlış tasarıma yol açabilir.

Kullanabileceğim veya uyarlayabildiğim JWT kimlik doğrulaması için bazı iyi düşünülmüş ve test edilmiş kurumsal bilmece arıyorum, ancak tam bir şey bulamadım.

Ne düşünüyordum:

• Yetkilendirme üstbilgisi karşılanmadığında veya JWT belirteci geçersiz olduğunda veya süresi dolduğunda HTTP 401 gönder
• kimlik doğrulaması yapmak için REST kanalını kullanın / oturum açın, JSON nesnesi olarak kullanıcı adı ve şifre gönderin
• jetonu canlı tutmak için REST kanalını kullanın / saklayın, her N (5) dakikada bir arayın, yeni JWT jetonu alın ve her aramadan sonra mevcut olanı değiştirin (jelin M (15) dakika sonra süresi dolar)

Ancak, beni rahatsız eden şey, o / tutucu kanalın gerekliliğidir. Öte yandan, kullanıcı uzakta olsa bile (kimlik doğrulamanın yapılmasını istemiyorsak karar henüz karşılanmadıysa) kimlik doğrulamasının süresinin dolmasını engellemeye zorlar ve elbette bunlar ekstra çağrılar ve protokol için ekstra komplikasyon. İlginç olan, sunucunun belirteci otomatik olarak uzatmasıdır. Oturum tabanlı ortamda zaman damgasını sıfırlayarak olur, ancak burada sunucunun her seferinde değil, yeni jeton göndermesi gerekir, ancak jetonun süresi R (10, dakika) içinde sona erer. Ancak yanıt gövdesine yerleştirmek JSON yanıt protokolünü değiştirmek anlamına gelir (bu nedenle çözüm invazivdir ve saydam değildir) ve istemcinin işleyebileceği fazladan bir HTTP üstbilgisi koymak iyi bir kalıp olmayabilir. BEN'

Açık puanlarıma cevap veren hazır kurumsal kalıplar var mı? Protokol taslağım güvenilir bir fikir mi? Sıfırdan tasarıma hazır bir şey kullanmayı tercih ederim.

JWT ( JSON Web Token'a Giriş ) sadece bir jeton biçimidir, kimlik doğrulama bu spesifikasyon için tamamen kapsam dışı bir şeydir. Gerçekten de kimlik doğrulama sistemlerinde yaygın olarak kullanılır, ancak tamamen farklı senaryolar için de kullanabilirsiniz, bu nedenle bu spesifikasyona kimlik doğrulamasına özgü kısıtlamaları dahil etmemek mantıklıdır.

Kimlik doğrulama konusunda rehberlik arıyorsanız, OpenID Connect özellik ailesine başvurmalısınız . Ayrıca, sisteminiz HTTP API'lerinden oluşuyorsa ve bu API'ye kendi veya üçüncü taraf istemci uygulamanıza yetki verilen erişim sağlamak istiyorsanız, OAuth 2.0 belirtimine başvurmalısınız .

Kurumsal senaryolarda hala yaygın olarak kullanılan SAML ve WS-Federation gibi kimlik doğrulaması ile ilgili ek protokoller vardır, ancak bunların uygulanması daha karmaşıktır.

Özel açık noktalarınız hakkında:

• Taşıyıcı belirteci kimlik doğrulama şeması, isteklerin nasıl gerçekleştirileceğine ve olası hata kodlarına ilişkin talimatları içeren RFC 6750'de tanımlanmıştır .
• OAuth2 ve OpenID Connect her ikisi de olasılığı düşünür ve bir kullanıcı adı / parolayı bir jetonla değiştirmenin yolunu tanımlar.
• Bağımsız / değere dayalı belirteç (JWT) ömrünü uzatma sorunu , yenileme belirteçleri aracılığıyla OpenID Connect ve OAuth2 içinde giderilir .

OAuth2 ve OpenID Connect'in öncekilerden bazılarına göre uygulanması daha kolay görünse de, yine de bir miktar dikkat gerektirecek ve yalnızca önemli miktarda zaman ve kaynak harcamak istiyorsanız bunları kendiniz uygulayacak kadar karmaşıktır. Bu ağır yükü sizin için yapan üçüncü taraf kitaplıkları veya hizmetleri kullanmak genellikle daha iyi bir seçenektir.

Son olarak, bu protokoller birçok senaryoyu kapsamaktadır, bu nedenle bazı durumlarda aşırıya kaçabilirler.

Kalıcı bir kanala ihtiyacınız olduğunu düşünmüyorum. Yükünüz , belirteç oturum açıldığında oluşturulduğunda sunucu tarafından ( standartta , expanahtarda ) verilen son kullanma bilgilerini içerebilir (ve tavsiye etmeniz) . Süresi dolmuş bir simge kullanılırsa (açıkça, imza imzalanırsa jetondakine güvenen sunucu tarafından belirlenir), sunucu HTTP 401 ile reddederek istemcinin yeniden kimlik doğrulaması yapmasını ister.

Bu arada müşteriler proaktif olabilir. Yük bölümü şifrelenmez ve istemci bunu okuyabildiğinden, istemci bir isteğin ne zaman süresi dolmuş bir jetonla gönderileceğini belirleyebilir ve bu nedenle /loginjetonun süresi dolarsa tekrar arar .

Alternatif olarak, REST, hiper ortam bilgilerinin 'bir devlet motoru' olarak gönderilmesine izin verir ve bu nedenle isterseniz, JWT'nizin tek kullanımlık ve son kullanma tarihine sahip olursunuz. Her istek, hapi-auth-jwt2'nin yaptığı gibi, içerikte veya yanıt başlığında daha büyük olasılıkla istemciye yanıt olarak döndürülen yeni bir JWT oluşturur .