"JWT vs Cookie" hakkında bazı yazılar okudum ama onlar kafamı daha da karıştırdı ...

1. Biraz istiyorum açıklama , "kurabiye vs belirteci tabanlı kimlik doğrulaması" hakkında konuşan insanlar, çerezler burada sadece bakınız oturum çerezleri ? Anladığım kadarıyla, tanımlama bilgisi bir araç gibidir , belirteç tabanlı bir kimlik doğrulama (oturum açmış kullanıcıyı istemci tarafında tanımlayabilen bir şey depolamak ) veya oturum tabanlı bir kimlik doğrulaması (istemci tarafında bir sabit saklamak) uygulamak için kullanılabilir. sunucu tarafındaki oturum bilgileriyle eşleşen )

2. JSON web jetonuna neden ihtiyacımız var ? Belirteç tabanlı kimlik doğrulamasını uygulamak için standart tanımlama bilgisini kullanıyordum (oturum kimliği kullanmıyordum, sunucu belleği veya dosya depolamasını kullanmıyordum ): Set-Cookie: user=innocent; preferred-color=azureve gözlemlediğim tek fark JWT'nin hem yükü hem de imzayı içermesidir ... oysa siz seçebilirsiniz http başlığı için imzalı veya düz metin tanımlama bilgisi arasında . Bence imzalı çerez ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') daha fazla alan verimli, tek dezavantajı, istemcinin jetonu okuyamaması, yalnızca sunucunun okuyabilmesi ... ama bence sorun değil çünkü JWT'deki hak talebinin isteğe bağlı olması gibi, jetonun anlamlı ol

Taşıyıcı belirteçleri ile çerezler arasındaki en büyük fark, tarayıcının otomatik olarak çerez göndermesidir ; burada taşıyıcı belirteçlerinin açıkça HTTP isteğine eklenmesi gerekir.

Bu özellik, tanımlama bilgilerini, bir kullanıcının bağlantı kullanarak oturum açtığı ve sayfalar arasında gezindiği web sitelerini güvenli hale getirmek için iyi bir yol haline getirir.

Çerezleri otomatik olarak gönderen tarayıcının da büyük bir dezavantajı vardır, bu da CSRF saldırılarıdır. Bir CSRF saldırısında, kötü amaçlı bir web sitesi, tarayıcınızın o etki alanına gelen isteklere kimlik doğrulama tanımlama bilgilerini otomatik olarak ekleyeceği ve tarayıcınızı bir isteği gerçekleştirmesi için kandıracağı gerçeğinden yararlanır.

Https://www.example.com adresindeki web sitesinin POST, yeni şifreyi https://www.example.com/changepassword olarak kullanıcı adı veya eski şifrenin gönderilmesine gerek kalmadan değiştirerek şifrelerini değiştirmelerine izin verdiğini varsayalım .

Tarayıcınızda bu adrese bir POST'u tetikleyen bir sayfa yükleyen kötü amaçlı bir web sitesini ziyaret ettiğinizde o web sitesinde hala oturum açmışsanız, tarayıcınız kimlik doğrulama tanımlama bilgilerini aslına uygun şekilde ekleyerek saldırganın parolanızı değiştirmesine olanak tanır.

Çerezler, web hizmetlerini korumak için de kullanılabilir, ancak günümüzde en çok taşıyıcı belirteçler kullanılmaktadır. Çerezleri web hizmetinizi korumak için kullanırsanız, aynı menşeli politika başka bir etki alanına çerez göndermeyeceğinden , bu hizmetin kimlik doğrulama çerezlerinin ayarlandığı etki alanında yaşaması gerekir .

Ayrıca çerezler, tarayıcı tabanlı olmayan uygulamaların (mobilden tablete uygulamalar gibi) API'nizi tüketmesini zorlaştırır.

Genel Bakış

İstediğiniz şey, istemciden sunucuya JSON Web Belirteçleri (JWT'ler) göndermek için tanımlama bilgileri ile taşıyıcı belirteçleri arasındaki farktır.

Hem çerezler hem de taşıyıcı belirteçleri veri gönderir.

Aralarındaki bir fark, tanımlama bilgilerinin isteğe bağlı verilerin gönderilmesi ve depolanması, taşıyıcı belirteçlerin ise özellikle yetkilendirme verilerini göndermesidir.

Bu veriler genellikle bir JWT olarak kodlanır.

Kurabiye

Çerez, bir web tarayıcısında saklanan ve bir son kullanma tarihi ve ilişkili etki alanına sahip bir ad-değer çiftidir.

Çerezleri bir web tarayıcısında ya JavaScript ile ya da bir HTTP Cevap başlığı ile saklarız.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Web tarayıcısı, tanımlama bilgilerinin etki alanına her istekle birlikte otomatik olarak tanımlama bilgileri gönderir.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Taşıyıcı Jetonu

Taşıyıcı belirteci, Authorizationherhangi bir HTTP İsteğinin başlığına giren bir değerdir . Otomatik olarak herhangi bir yerde depolanmaz, son kullanma tarihi yoktur ve ilişkili etki alanı yoktur. Bu sadece bir değer. Bu değeri müşterilerimizde manuel olarak depolar ve bu değeri manuel olarak HTTP Yetkilendirme başlığına ekleriz.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT ve Token Tabanlı Kimlik Doğrulama

OpenID, OAuth veya OpenID Connect gibi belirteç tabanlı kimlik doğrulaması yaptığımızda, güvenilir bir otoriteden bir erişim belirteci (ve bazen id_token) alırız. Genellikle bunu saklamak ve korumalı kaynaklar için HTTP İstekleri ile birlikte göndermek isteriz. Bunu nasıl yaparız?

Seçenek 1, jetonları bir çerezde saklamaktır. Bu, depolamayı yönetir ve ayrıca jetonları otomatik Cookieolarak her isteğin başlığındaki sunucuya gönderir . Sunucu daha sonra çerezi ayrıştırır, belirteçleri kontrol eder ve buna göre yanıt verir.

Diğer bir seçenek, belirteci yerel / oturum depolamasında saklamak ve ardından Authorizationher isteğin başlığını manuel olarak ayarlamaktır . Bu durumda, sunucu başlığı okur ve tıpkı bir çerez gibi ilerler.

Daha fazla bilgi edinmek için bağlantılı RFC'leri okumaya değer.

MvdD'nin çerezlerin otomatik olarak gönderilmesi hakkında söylediklerine ek olarak:

1. Çerez bir araç olabilir, ancak en önemli işlevi tarayıcıyla nasıl etkileşim kurduğudur. Çerezler sunucu tarafından belirlenir ve çok özel yollarla isteklerde gönderilir. Öte yandan JWT, yalnızca bir ortamdır, belirli bir yapıdaki bazı gerçeklerin bir iddiasıdır. Bu kadar istekli olsaydınız, kimlik doğrulama tanımlama bilginiz olarak bir JWT koyabilirsiniz. Bunları karşılaştıran makaleleri okuduğunuzda, genellikle ön uç kodla bir taşıyıcı belirteci olarak gönderilen bir JWT ile arka uçtaki bazı önbelleğe alınmış oturum veya kullanıcı verilerine karşılık gelen bir kimlik doğrulama tanımlama bilgisinden bahsediyorlar.
2. JWT birçok özellik sunar ve bunları taraflar arasında kullanılabilmeleri için bir standart haline getirir. Bir JWT, birçok farklı yerde bazı gerçeklerin imzalı bir iddiası olarak hareket edebilir. Bir çerez, içine hangi verileri koyarsanız koyun veya imzalarsanız, yalnızca bir tarayıcı ile belirli bir arka uç arasında kullanılması gerçekten anlamlıdır. JWT, tarayıcıdan arka uca, farklı taraflarca kontrol edilen arka uçlar arasında (OpenId Connect bir örnektir) veya bir tarafın arka uç hizmetleri içinde kullanılabilir. İmzalı tanımlama bilgilerinize ilişkin özel örneğinizle ilgili olarak, bu kullanım durumunda JWT ile muhtemelen aynı işlevleri ("oturum kimliğini kullanmadan, sunucu belleğini veya dosya depolamasını kullanmadan") gerçekleştirebilirsiniz, ancak kitaplıklarda ve hakem incelemesinde kaybedersiniz. standart, CSRF konularına ek olarak diğer cevapta da bahsedilmiştir.

Özetle: Okuduğunuz gönderiler, muhtemelen tarayıcıdan sunucu kimlik doğrulaması amaçlarına yönelik kimlik doğrulama tanımlama bilgisiyle taşıyıcı belirteci olarak JWT'yi karşılaştırıyor. Ancak JWT çok daha fazlasını yapabilir, standartlaştırma ve muhtemelen düşündüğünüz kullanım durumunun dışında kullanım için özellikler getirir.

Çerezler, isteklerle birlikte otomatik olarak gönderilmeleri sayesinde CSRF saldırıları riskini artırabilirken, HttpOnlybayrak ayarlandığında XSS saldırıları riskini azaltabilir , çünkü sayfaya enjekte edilen herhangi bir komut dosyası okuyamaz. kurabiye.

CSRF: Bir kullanıcı, saldırganın sitesindeki bir bağlantıya tıklar (veya resimleri görüntüler), bu da tarayıcının kurbanın sitesine bir istek göndermesine neden olur. Kurban tanımlama bilgilerini kullanırsa, tarayıcı otomatik olarak tanımlama bilgisini isteğe dahil eder ve GET isteği salt okunur olmayan herhangi bir eyleme neden olabilirse, mağdur site saldırıya karşı savunmasızdır.

XSS: Bir saldırgan, kurban sitesine bir komut dosyası yerleştirir (kurban sitesi yalnızca girdiler doğru bir şekilde sterilize edilmediğinde savunmasızdır) ve saldırganın komut dosyası, javascript'in sayfada yapmasına izin verilen her şeyi yapabilir. JWT belirteçlerini yerel depolamada depolarsanız, saldırganın komut dosyası bu belirteçleri okuyabilir ve bu belirteçleri kontrol ettikleri bir sunucuya da gönderebilir. Çerezleri HttpOnlybayrakla kullanırsanız, saldırganın komut dosyası başlangıçta çerezinizi okuyamaz. Bununla birlikte, başarılı bir şekilde enjekte ettikleri komut dosyası, javascript'in yapabileceği her şeyi yine de yapabilir, bu nedenle hala IMO'ya sahipsiniz (yani, çerezi daha sonra kullanmak üzere kendi sunucularına göndermek için okuyamayabilirken) bunlar olabilir ) yine çerez dahil edecek olan xhr kullanarak vicitim siteye istekleri göndermek.

Referans - JSON Web Simgesi İhtiyacı

Kurabiye

Çerezler durumunda, kullanıcının kimliği doğrulandıktan sonra Gmail Sunucusu benzersiz bir oturum kimliği oluşturacaktır. Bu oturum kimliğine karşılık olarak, Gmail sunucusunun kullanıcıyı tanıması ve işlemleri gerçekleştirmesine izin vermesi için ihtiyaç duyduğu tüm kullanıcı bilgilerini bellekte depolar.
Ayrıca sonraki tüm istekler ve yanıtlar için bu oturum kimliği de iletilecektir. Şimdi sunucu bir istek aldığında oturum kimliğini kontrol edecek. Bu oturum kimliğini kullanmak, ilgili herhangi bir bilgi olup olmadığını kontrol edecektir. Daha sonra kullanıcının kaynağa erişmesine ve yanıtı oturum kimliğiyle birlikte geri göndermesine izin verecektir.

Çerezlerin Dezavantajları

• Çerezler / oturum kimliği bağımsız değildir. Bu bir referans belirtecidir. Her doğrulama sırasında, Gmail sunucusunun kendisine karşılık gelen bilgileri getirmesi gerekir.
• Birden çok API ve sunucuyu içeren mikro hizmet mimarisi için uygun değildir

JWT

• JWT bağımsızdır. Bu bir değer belirtecidir. Bu nedenle, her doğrulama sırasında Gmail sunucusunun kendisine karşılık gelen bilgileri alması gerekmez.
• Dijital olarak imzalandı, böylece herhangi biri değiştirirse sunucu bunu bilecek
• En çok Mikro Hizmet Mimarisi için uygundur
• Son kullanma zamanını belirtmek gibi başka avantajları da vardır.