JWT ve OAuth kimlik doğrulaması arasındaki temel farklar nelerdir?

JWT kullanarak durum bilgisi olmayan kimlik doğrulama modeline sahip yeni bir SPA'm var. Sık sık basit bir jeton başlığı yerine her istek için 'Taşıyıcı belirteçleri' göndermemi istemek gibi kimlik doğrulama akışları için OAuth'a başvurmam istenir, ancak OAuth'un basit bir JWT tabanlı kimlik doğrulamasından çok daha karmaşık olduğunu düşünüyorum. Temel farklılıklar nelerdir, JWT kimlik doğrulamasının OAuth gibi davranmasını sağlamalıyım?

Ben de XSRF önlemek için benim XSRF-TOKEN olarak JWT kullanıyorum ama ben onları ayrı tutmak isteniyor? Onları ayrı tutmalı mıyım? Buradaki herhangi bir yardım takdir edilecektir ve topluluk için bir dizi yönerge oluşturabilir.

TL; DR Tek bir istemci uygulaması, tek bir API gibi çok basit senaryolarınız varsa, OAuth 2.0'a gitmek için işe yaramayabilir, öte yandan, birçok farklı istemci (tarayıcı tabanlı, yerel mobil, sunucu tarafı) OAuth 2.0 kurallarına uymak, onu kendi sisteminizi yuvarlamaya çalışmaktan daha yönetilebilir hale getirebilir.

Başka bir cevapta belirtildiği gibi, JWT ( Learn JSON Web Tokens ) sadece bir token formatıdır, dijital olarak imzalandığı için taraflar arasında veri doğrulanabilecek ve güvenilebilecek şekilde veri iletmek için kompakt ve bağımsız bir mekanizma tanımlar. Ek olarak, bir JWT'nin kodlama kuralları, bu belirteçlerin HTTP bağlamında kullanımını çok kolaylaştırır.

Kendi kendine yeten (gerçek jeton belirli bir konu hakkında bilgi içerir) aynı zamanda vatansız kimlik doğrulama mekanizmalarını uygulamak için iyi bir seçimdir ( Bak anne, oturum yok! ). Bu rotaya giderken ve bir tarafın korumalı bir kaynağa erişim izni vermesi gereken tek şey belirtecin kendisidir, söz konusu belirteç taşıyıcı belirteci olarak adlandırılabilir.

Pratikte, yaptığınız şey zaten taşıyıcı belirteçlerine göre sınıflandırılabilir. Ancak, OAuth 2.0 ile ilgili spesifikasyonlarda belirtilen taşıyıcı belirteçleri kullanmadığınızı düşünün (bkz. RFC 6750 ). Bu, AuthorizationHTTP üst bilgisine dayanarak ve Bearerkimlik doğrulama düzenini kullanarak anlamına gelir .

JWT'nin, kesin detayları bilmeden CSRF'yi önlemek için kullanılmasıyla ilgili olarak, bu uygulamanın geçerliliğini belirlemek zordur, ancak dürüst olmak gerekirse doğru ve / veya değerli görünmemektedir. Aşağıdaki makale ( Çerezler ve Jetonlar: Kesin Kılavuz ), özellikle XSS ve XSRF Koruması bölümü olmak üzere bu konuda yararlı bir okuma olabilir .

Son bir tavsiye parçası, tam OAuth 2.0'a gitmenize gerek olmasa bile , özel başlıklarla gitmek yerine erişim simgenizi Authorizationbaşlık içinde geçirmenizi şiddetle tavsiye ederim . Gerçekten taşıyıcı belirteçleri ise, RFC 6750 kurallarına uyuyorsa, her zaman özel bir kimlik doğrulama düzeni 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 işlenir. Bu nedenle, kaynak sunucularına erişim belirteçleri göndermek için bu başlıkların kullanılması, genel olarak kimliği doğrulanmış isteklerin ve özellikle Yetkilendirme başlıklarının sızıntı veya istenmeyen depolama olasılığını azaltır.

(kaynak: RFC 6819, bölüm 5.4.1 )

OAuth 2.0 bir protokol tanımlar, yani jetonların nasıl aktarılacağını belirtir, JWT bir jeton biçimini tanımlar.

OAuth 2.0 ve "JWT kimlik doğrulaması", İstemcinin belirteci Kaynak Sunucu'ya sunduğu (2.) aşamasına geldiğinde benzer görünüme sahiptir: belirteç bir başlıkta iletilir.

Ancak "JWT kimlik doğrulaması" standart değildir ve Müşterinin jetonu ilk etapta nasıl elde edeceğini belirtmez (1. aşama). OAuth'un algılanan karmaşıklığı buradan gelir: İstemcinin Yetkilendirme Sunucusu adı verilen bir şeyden erişim belirteci edinmesinin çeşitli yollarını da tanımlar .

Gerçek fark JWT sadece sembolik bir biçim olmasıdır Yani, OAuth 2.0 bir protokol (yani olabilir bir belirteç biçimi olarak bir JWT'yi kullanın).

İlk olarak, JWT ve OAuth'u ayırmak zorundayız. Temel olarak, JWT bir jeton biçimidir. OAuth, JWT'yi jeton olarak kullanabilen bir yetkilendirme protokolüdür. OAuth, sunucu tarafı ve istemci tarafı depolama alanı kullanır. Eğer gerçek çıkış yapmak istiyorsanız OAuth2 ile gitmelisiniz. JWT jetonu ile kimlik doğrulaması aslında çıkış yapamaz. Çünkü simgeleri takip eden bir Kimlik Doğrulama Sunucunuz yok. 3. taraf istemcilere bir API sağlamak istiyorsanız, OAuth2'yi de kullanmanız gerekir. OAuth2 çok esnektir. JWT uygulaması çok kolaydır ve uygulanması uzun sürmez. Uygulamanız bu tür bir esnekliğe ihtiyaç duyuyorsa, OAuth2 ile devam etmelisiniz. Ancak bu kullanım senaryosuna ihtiyacınız yoksa, OAuth2'yi uygulamak zaman kaybıdır.

XSRF belirteci her yanıt üstbilgisinde her zaman istemciye gönderilir. CSRF jetonunun JWT jetonunda gönderilip gönderilmemesi önemli değildir, çünkü CSRF jetonu kendisiyle sabitlenmiştir. Bu nedenle, JWT'de CSRF jetonu göndermek gereksizdir.

JWT (JSON Web Jetonları) - Bu sadece bir jeton biçimidir. JWT jetonları, JSON kodlu veri yapılarıdır; yayıncı, konu (talepler), sona erme süresi vb. Hakkında bilgi içerir. Kurcalamaya dayanıklılık ve özgünlük için imzalanmıştır ve simetrik veya asimetrik yaklaşım kullanılarak jeton bilgilerini korumak için şifrelenebilir. JWT, SAML 1.1 / 2.0'dan daha basittir ve tüm cihazlar tarafından desteklenir ve SWT'den (Basit Web Simgesi) daha güçlüdür.

OAuth2 - OAuth2, kullanıcının göz atmaya dayalı web uygulamaları, yerel mobil uygulamalar veya masaüstü uygulamaları gibi istemci yazılımlarını kullanarak verilere erişmek istediği bir sorunu çözer. OAuth2 yalnızca yetkilendirme amaçlıdır, istemci yazılımı erişim belirteci kullanarak son kullanıcı adına kaynaklara erişme yetkisine sahip olabilir.

OpenID Connect - OpenID Connect, OAuth2'nin üzerine kurulur ve kimlik doğrulama ekler. OpenID Connect, OAuth2'ye UserInfo Endpoint, ID Token, OpenID Connect sağlayıcılarının keşfi ve dinamik kaydı ve oturum yönetimi gibi bazı kısıtlamalar ekler. JWT, jeton için zorunlu biçimdir.

CSRF koruması - Jetonu tarayıcının çerezinde saklamıyorsanız CSRF korumasını uygulamanız gerekmez.

Daha fazla bilgiyi buradan okuyabilirsiniz http://proficientblog.com/microservices-security/

Burada cevap veren herkes OAUTH'ın tartışmalı noktasını kaçırmış gibi görünüyor

Wikipedia'dan

OAuth, erişim yetkisi için açık bir standarttır ve genellikle İnternet kullanıcılarının web sitelerine veya uygulamalarına diğer web sitelerindeki bilgilere erişim izni vermeleri için şifreleri vermeden bir yol olarak kullanılır. [1] Bu mekanizma, Google, Facebook, Microsoft ve Twitter gibi şirketler tarafından kullanıcıların hesaplarıyla ilgili bilgileri üçüncü taraf uygulamaları veya web siteleriyle paylaşmalarına izin vermek için kullanılır.

Burada kilit nokta access delegation. OTP'ler gibi çok faktörlü kimlik doğrulamasıyla desteklenen id / pwd tabanlı bir kimlik doğrulaması olduğunda neden herkes OAUTH oluşturacak ve yollara (OAUTH kapsamları gibi) erişimin güvenliğini sağlamak için kullanılan JWT'ler tarafından güvence altına alınabilir ve Giriş

Tüketicilerin kaynaklarına (bitiş noktalarınıza) yalnızca tekrar uç noktalarınızda barındırdığınız güvenilir web siteleri (veya uygulamaları) üzerinden erişmeleri durumunda OAUTH kullanmanın bir anlamı yoktur.

OAUTH kimlik doğrulamasına yalnızca kaynak sahiplerinin (kullanıcıların) kaynaklarınıza (uç noktalarınıza) üçüncü taraf bir istemci (harici uygulama) üzerinden erişmek istedikleri birOAUTH provider durumdaysanız gidebilirsiniz . Ve aynı amaç için yaratılmıştır, ancak genel olarak kötüye kullanabilirsiniz.

Bir başka önemli not: JWT ve OAUTH
kelimelerini özgürce kullanıyorsunuz, authenticationancak ikisi de kimlik doğrulama mekanizmasını sağlamıyor. Evet, biri bir belirteç mekanizması ve diğeri protokoldür, ancak kimlik doğrulaması yapıldıktan sonra yalnızca yetkilendirme (erişim yönetimi) için kullanılır. OAUTH'u OPENID türü kimlik doğrulaması veya kendi istemci kimlik bilgilerinizle desteklemelisiniz

JWT ve OAuth arasındaki temel farkları bulur

1. OAuth 2.0 bir protokol tanımlar ve JWT bir token formatı tanımlar.

2. OAuth, JWT'yi bir belirteç biçimi veya bir taşıyıcı belirteç olan erişim belirteci olarak kullanabilir.

3. OpenID connect genellikle bir jeton formatı olarak JWT kullanır.

JWT, taraflar arasında güvenli bir şekilde bilgi iletimi için kompakt ve müstakil bir yol tanımlayan açık bir standarttır. Kodlanmış taleplerin (belirteçlerin) iki taraf (istemci ve sunucu) arasında aktarılmasına izin verdiğimiz ve belirteç bir istemcinin tanımlanması üzerine verildiği bir kimlik doğrulama protokolüdür. Sonraki her talepte jetonu göndeririz.

Oysa OAuth2, çerçeve tarafından tanımlanan genel prosedürlere ve kurulumlara sahip olduğu bir yetkilendirme çerçevesidir. JWT, OAuth2 içinde bir mekanizma olarak kullanılabilir.

Bununla ilgili daha fazla bilgiyi buradan edinebilirsiniz

OAuth veya JWT? Hangisini kullanmalı ve neden?

Soru yaygın bir sorudur, ancak pek mantıklı değildir. JWT bir Token türüdür ve OAuth tokenlerin nasıl dağıtılacağını açıklayan bir Çerçevedir.

"Çerçeve" ile neyi kastediyoruz? Yalnızca istek ve yanıtların sırası ve belirteç istemek için kullanılabilecek ve kullanılması gereken biçimler. OAuthv2, farklı senaryolar için ayrı "akışları" veya hibe türlerini tanımlar ve belirli akışların güvenliğini artırmak için farklı uzantılara (PKCE gibi) sahiptir.

Bir OAuthV2 hibesi yoluyla bir token isteğinin sonucu ... bir token. Bu şey daha sonra bir "taşıyıcı jetonu" olarak kullanılır, yani jetonu elinde tutan herhangi bir taraf, bir api hizmet talebi yaparken sunabilir (ör. "Saklanan değer kartımdaki denge nedir?"). Bir Taşıyıcı belirteci olarak nakit para gibi çalışır. Eğer tutuyorsanız, kullanabilirsiniz. (Nakit paradan farklı olarak, bir token onu kullan ve kaybet değildir. Belki daha iyi bir benzetme, toplu taşıma sisteminde tüm gün sürmek için bir bilet veya Disneyworld'de tüm gün bir bilettir.)

JWT belirli bir tür belirtecidir ve JWT kesinlikle OAuth Taşıyıcı belirteci olarak kullanılabilir. Aslında, bu en yaygın uygulamadır. Bunun ışığında, "JWT vs OAuth" elma ve elma arabalarının bir karşılaştırmasıdır.

Çoğu zaman insanlar "OAuth jetonu" her zaman opak bir jeton - doğal bir anlam içermeyen rastgele bir alfasayısal karakter dizisi - anlamına gelir ve OAuth jetonu dispanseri tarafından verilen ve daha sonra sadece aynı OAuth dispanser sistemi tarafından onaylanabilir. Ama bu tek OAuth jetonu değil. Opak bir belirteç bir tür belirteçtir; JWT farklı türde bir OAuth jetonu olarak kullanılabilir.

JWT, aksine, opak değildir. JWT bir "işaretçi" veya bilgiye referans değildir. Aslında, jetonu olan herhangi bir tarafça çıkarılabilen ve yorumlanabilen birçok özel bilgi içerir. JWT gerçek bilgi içerdiğinden, bir JWT büyük olabilir; İçindeki baytlara ve imzalamak için kullanılan algoritmaya bağlı olarak 300 bayt, 500 bayt veya daha fazla. İnsanlar "JWT" ​​ne demek istediklerini "söylediklerinde, JWT'nin herhangi bir sahibi onu açabilir, doğrulayabilir ve daha sonra sunulan iddialara dayanarak yetkilendirme kararları verebilir. JWT'nin doğrulanması şu anlama gelir: yapısının doğrulanması, base64 kodlamasının kodunun çözülmesi, anahtarın doğru olduğunun doğrulanması, imzanın doğrulanması, daha sonra jetonda gerekli taleplerin bulunduğunun doğrulanması, son kullanma tarihinin kontrol edilmesi. Basit bir şey değil, bunun yerine çok adımlı bir süreçtir, ancak elbette bununla çeşitli programlama dillerinde çok sayıda kitaplık vardır ve elbette bunu Apigee Edge API proxy'si içinde yapmanıza yardımcı olan VerifyJWT politikası vardır. Mesele şu ki, herhangi bir tutucu veya alıcı bir jetonu doğrulayabilir. Bu nedenle, JWT'nin "Federasyon" u desteklediğini söylüyoruz - herkes bir jeton üretebilir ve herkes bir jetonu okuyabilir ve doğrulayabilir.

özel talepler. Hem JWT hem de opak OAuth jetonları konu hakkında özel talepler taşıyabilir. güvenlik. Her ikisi de taşıyıcı tokenlerdir. Her ikisinin de sır olarak korunması gerekir. son. Her ikisi de bir son kullanma tarihi ile işaretlenebilir. Her ikisi de yenilenebilir. Kimlik doğrulama mekanizması veya deneyimi. Her ikisi de aynı kullanıcı deneyimini sunabilir.

Jwt imzalı erişim belirteçlerinin düzenlenmesi ve onaylanması için katı bir talimatlar dizisidir. Belirteçler, bir uygulama tarafından bir kullanıcıya erişimi sınırlamak için kullanılan hak taleplerini içerir

Öte yandan OAuth2 protokol değil, yetkilendirilmiş yetkilendirme çerçevesi. kullanıcıların ve uygulamaların hem özel hem de genel ortamlardaki diğer uygulamalara özel izinler vermesine izin vermek için çok ayrıntılı bir kılavuz düşünün. OAUTH2'nin üstünde yer alan OpenID Connect size Kimlik Doğrulama ve Yetkilendirme sağlar. Bu, birden çok farklı rolün, sisteminizdeki kullanıcıların, API gibi sunucu tarafı uygulamalarının ve web siteleri veya yerel mobil uygulamalar gibi istemcilerin her bir kimlikle nasıl kimlik doğrulaması yapabileceğini ayrıntıları

Not oauth2 farklı uygulamalar için genişletilebilir jwt, esnek uygulama ile çalışabilir