JWT kullanan durum bilgisi olmayan bir kimlik doğrulama modeline sahip yeni bir SPA'm var. Sık sık kimlik doğrulama akışları için OAuth'a başvurmam isteniyor, örneğin basit bir token başlığı yerine her istek için 'Bearer tokens' göndermem isteniyor, ancak OAuth'un basit bir JWT tabanlı kimlik doğrulamadan çok daha karmaşık olduğunu düşünüyorum. Temel farklar nelerdir, JWT kimlik doğrulamasının OAuth gibi davranmasını sağlamalı mıyım?
XSRF'yi önlemek için JWT'yi XSRF-TOKEN'im olarak da kullanıyorum ancak bunları ayrı tutmam mı isteniyor? Onları ayrı mı tutmalıyım? Buradaki herhangi bir yardım takdir edilecektir ve topluluk için bir dizi yönergeye yol açabilir.
TL;DR Tek bir istemci uygulaması, tek bir API gibi çok basit senaryolarınız varsa, OAuth 2.0'a gitmek işe yaramayabilir, diğer yandan çok sayıda farklı istemci (tarayıcı tabanlı, yerel mobil, sunucu tarafı vb.) varsa, OAuth 2.0 kurallarına bağlı kalmak, kendi sisteminizi yuvarlamaya çalışmaktan daha yönetilebilir hale getirebilir.
Başka bir yanıtta belirtildiği gibi, JWT (Learn JSON Web Tokens) sadece bir token formatıdır, dijital olarak imzalandığı için doğrulanabilecek ve güvenilebilecek bir şekilde taraflar arasında veri iletmek için kompakt ve bağımsız bir mekanizma tanımlar. Ayrıca, JWT'nin kodlama kuralları da bu belirteçlerin HTTP bağlamında kullanımını çok kolay hale getirir.
Bağımsız olduklarından (gerçek belirteç belirli bir özne hakkında bilgi içerir), durumsuz kimlik doğrulama mekanizmalarını uygulamak için de iyi bir seçimdir (diğer bir deyişle Bak anne, oturum yok!). Bu yolda ilerlerken ve bir tarafın korunan bir kaynağa erişim izni almak için sunması gereken tek şey belirtecin kendisiyse, söz konusu belirteç taşıyıcı belirteç olarak adlandırılabilir.
Pratikte, yaptığınız şey zaten hamiline yazılı jetonlara dayalı olarak sınıflandırılabilir. Ancak, OAuth 2.0 ile ilgili teknik özelliklerde belirtildiği gibi taşıyıcı belirteçleri kullanmadığınızı göz önünde bulundurun (bkz. RFC 6750). Bu, Authorization
HTTP başlığına güvenmek ve Bearer
kimlik doğrulama şemasını kullanmak anlamına gelir.
CSRF'yi önlemek için JWT kullanımı ile ilgili olarak, tam ayrıntıları bilmeden bu uygulamanın geçerliliğini tespit etmek zordur, ancak dürüst olmak gerekirse doğru ve / veya değerli görünmemektedir. Aşağıdaki makale (Cookies vs Tokens: The Definitive Guide), özellikle XSS ve XSRF Koruması bölümü olmak üzere bu konuda faydalı bir okuma olabilir.
Son bir tavsiye, tam OAuth 2.0'a ihtiyacınız olmasa bile, özel başlıklarla gitmek yerine erişim belirtecinizi `Yetkilendirme' başlığında geçirmenizi şiddetle tavsiye ederim. Eğer gerçekten taşıyıcı belirteçlerse RFC 6750'nin kurallarına uyun, değilse, her zaman özel bir kimlik doğrulama şeması oluşturabilir ve yine de bu başlığı kullanabilirsiniz.
Yetkilendirme başlıkları HTTP proxy'leri ve sunucuları tarafından tanınır ve özel olarak ele alınır. Bu nedenle, kaynak sunucularına erişim belirteçleri göndermek için bu tür başlıkların kullanılması, genel olarak kimliği doğrulanmış isteklerin ve özellikle Yetkilendirme başlıklarının sızdırılması veya istenmeyen şekilde saklanması olasılığını azaltır.
(kaynak: RFC 6819, bölüm 5.4.1)
OAuth 2.0 bir protokol tanımlar, yani belirteçlerin nasıl aktarılacağını belirtir, JWT ise bir belirteç formatı tanımlar.
OAuth 2.0 ve "JWT kimlik doğrulaması" İstemcinin belirteci Kaynak Sunucusuna sunduğu (2.) aşama söz konusu olduğunda benzer bir görünüme sahiptir: belirteç bir başlıkta iletilir.
Ancak "JWT kimlik doğrulaması" bir standart değildir ve İstemcinin belirteci ilk etapta (1. aşama) nasıl elde edeceğini belirtmez. OAuth'un algılanan karmaşıklığı da buradan kaynaklanmaktadır: İstemcinin Yetkilendirme Sunucusu olarak adlandırılan bir şeyden bir erişim belirteci elde edebileceği* çeşitli yolları da tanımlamaktadır.
Yani asıl fark JWT'nin sadece bir token formatı olması, OAuth 2.0'ın ise bir protokol olmasıdır (JWT'yi token formatı olarak kullanabilir).
Öncelikle JWT ve OAuth'u birbirinden ayırmamız gerekiyor. Temel olarak, JWT bir token formatıdır. OAuth ise JWT'yi token olarak kullanabilen bir yetkilendirme protokolüdür. OAuth, sunucu tarafı ve istemci tarafı depolama kullanır. Eğer gerçek logout yapmak istiyorsanız OAuth2 ile devam etmelisiniz. JWT token ile kimlik doğrulama aslında logout yapamaz. Çünkü belirteçleri takip eden bir Kimlik Doğrulama Sunucunuz yok. Eğer 3. parti istemcilere bir API sağlamak istiyorsanız, OAuth2 de kullanmalısınız. OAuth2 çok esnektir. JWT uygulaması çok kolaydır ve uygulaması uzun sürmez. Uygulamanızın bu tür bir esnekliğe ihtiyacı varsa, OAuth2'yi tercih etmelisiniz. Ancak bu kullanım senaryosuna ihtiyacınız yoksa, OAuth2'yi uygulamak zaman kaybıdır.
XSRF belirteci her zaman her yanıt başlığında istemciye gönderilir. CSRF belirtecinin bir JWT belirteci içinde gönderilip gönderilmemesi önemli değildir, çünkü CSRF belirteci kendisiyle güvence altına alınmıştır. Bu nedenle CSRF belirtecinin JWT içinde gönderilmesi gereksizdir.