Jeton Kimlik Doğrulaması ve Çerezler

Belirteç kimlik doğrulaması ile çerezleri kullanarak kimlik doğrulaması arasındaki fark nedir?

Ember Auth Rails Demosunu uygulamaya çalışıyorum, ancak "Neden token kimlik doğrulaması?" Sorusundaki Ember Auth SSS'de açıklandığı gibi token kimlik doğrulamasını kullanmanın nedenlerini anlamıyorum.

Tipik bir web uygulaması, istek / yanıt niteliği nedeniyle çoğunlukla vatansızdır . HTTP protokolü durumsuz protokolün en iyi örneğidir . Ancak çoğu web uygulaması durum gerektirdiğinden , durumu sunucu ile istemci arasında tutmak için çerezler, sunucunun istemciye her yanıta gönderebileceği şekilde kullanılır. Bu, istemciden yapılan bir sonraki isteğin bu çerezi içereceği ve dolayısıyla sunucu tarafından tanınacağı anlamına gelir. Bu şekilde sunucu , uygulamanın durumu hakkında çoğunlukla her şeyi bilen ancak sunucuda depolanan durumsuz istemciyle bir oturum gerçekleştirebilir . Bu senaryoda, müşteri hiçbir andevlet , Ember.js böyle çalışmaz .

Ember.js'de işler farklı. Ember.js, programcının işini kolaylaştırır, çünkü sunucuda durum verilerini sormak zorunda kalmadan durumu her an bilerek, istemcide sizin için durumu tutar .

Ancak, istemcide bekleme durumu bazen vatansız durumlarda bulunmayan eşzamanlılık sorunları da getirebilir . Bununla birlikte, Ember.js sizin için de bu sorunlarla ilgilenir, özellikle ember verileri bunu göz önünde bulundurarak oluşturulur. Sonuç olarak, Ember.js durum bilgisi olan müşteriler için tasarlanmış bir çerçevedir .

Ember.js , oturumun , durumun ve ilgili çerezlerin neredeyse tamamen sunucu tarafından ele alındığı tipik bir durumsuz web uygulaması gibi çalışmaz . Ember.js, durumunu tamamen javascript'te (diğer bazı çerçeveler gibi DOM'da değil , müşterinin belleğinde) tutar ve oturumu yönetmek için sunucuya ihtiyaç duymaz. Bu, örneğin uygulamanız çevrimdışı moddayken Ember.js'nin birçok durumda daha çok yönlü olmasına neden olur.

Güvenlik nedenleriyle , kimlik doğrulaması için her istek yapıldığında sunucuya bir tür belirteç veya benzersiz anahtarın gönderilmesi gerekir , bu şekilde sunucu gönderme belirtecini (başlangıçta sunucu tarafından verilen) arayabilir ve istemciye bir yanıt göndermeden önce geçerli olup olmadığını doğrulayın.

Benim düşünceme göre, Ember Auth SSS'de belirtildiği gibi çerezler yerine bir kimlik doğrulama belirteci kullanmanın ana nedeni öncelikle Ember.js çerçevesinin doğası ve ayrıca durum bilgisi olan web uygulaması paradigmasına daha fazla uymasıdır . Bu nedenle, bir Ember.js uygulaması oluştururken çerez mekanizması en iyi yaklaşım değildir.

Umarım cevabım sorunuza daha fazla anlam katar.

Http vatansızdır. Sizi yetkilendirmek için, sunucuya gönderdiğiniz her isteği "imzalamanız" gerekir.

Jeton kimlik doğrulaması

• Sunucuya bir istek bir "belirteç" ile imzalanır - genellikle belirli http üstbilgilerinin ayarlanması anlamına gelir, ancak bunlar http isteğinin (POST gövdesi vb.) Herhangi bir bölümünde gönderilebilir

• Artıları:

  • Yalnızca yetkilendirmek istediğiniz istekleri yetkilendirebilirsiniz. (Çerezler - her istek için yetkilendirme çerezi bile gönderilir.)
  • XSRF'ye bağışıklık (Kısa XSRF örneği - Size e-postada benzeyen bir bağlantı göndereceğim <img src="http://bank.com?withdraw=1000&to=myself" />ve bank.com'a çerez kimlik doğrulaması yoluyla giriş yaptıysanız ve bank.com'un XSRF aracı yok korumanız varsa, tarayıcınızın bu URL'ye yetkili bir GET isteği tetikleyeceği gerçeğiyle hesabınızdan para çekeceğim.) Çerez tabanlı kimlik doğrulamasıyla yapabileceğiniz sahtecilikle mücadele tedbirleri olduğunu unutmayın - ancak bunları uygulamanız gerekir.
  • Çerezler tek bir alan adına bağlıdır. Foo.com alan adında oluşturulan bir çerez, bar.com alan adı tarafından okunamaz, istediğiniz herhangi bir alana jeton gönderebilirsiniz. Bu, özellikle yetkilendirme gerektiren birden çok hizmet tüketen tek sayfa uygulamaları için kullanışlıdır - bu nedenle myapp.com etki alanında myservice1.com ve myservice2.com'a yetkili istemci tarafı istekleri gönderebilen bir web uygulamam olabilir.
• Eksileri:
  • Jetonu bir yerde saklamalısınız; çerezler "kutunun dışında" saklanır. Akla gelen konumlar localStorage (con: tarayıcı penceresini kapattıktan sonra bile belirteç kalıcıdır), sessionStorage (pro: tarayıcı penceresini kapattıktan sonra belirteç atılır, con: yeni bir sekmede bağlantı açıldığında bu sekme oluşturulur anonim) ve çerezleri (Pro: tarayıcı penceresini kapattıktan sonra belirteç atılır. Bir oturum çerezi kullanırsanız, yeni bir sekmede bir bağlantı açtığınızda kimliğiniz doğrulanır ve siz görmezden geldiğiniz için XSRF'ye bağışık olursunuz kimlik doğrulama için çerez olarak, yalnızca jeton depolama olarak kullanıyorsunuz. Con: çerezler her istek için gönderilir. Bu çerez yalnızca https olarak işaretlenmezse, orta saldırılarda adama açık olursunuz.)
  • Jeton tabanlı kimlik doğrulamasına karşı XSS ​​saldırısı yapmak biraz daha kolaydır (yani sitenizde enjekte edilmiş bir komut dosyası çalıştırabiliyorsam, simgenizi çalabilirim; ancak, çerez tabanlı kimlik doğrulaması da gümüş bir madde değildir - Yalnızca http, istemci tarafından okunamaz, istemci sizin adınıza yetkilendirme çerezini otomatik olarak içerecek isteklerde bulunabilir.)
  • Yalnızca yetkili kullanıcılar için çalışması beklenen bir dosyayı indirme istekleri için Dosya API'sını kullanmanızı gerektirir. Aynı istek, çerez tabanlı kimlik doğrulaması için kutudan çıkar.

Çerez kimlik doğrulaması

• Sunucuya bir istek her zaman yetkilendirme çerezi tarafından oturum açılır.
• Artıları:
  • Çerezler "yalnızca http" olarak işaretlenebilir, bu da istemci tarafında okunmasını imkansız hale getirir. Bu, XSS saldırı koruması için daha iyidir.
  • Kutudan çıkar çıkmaz - istemci tarafında herhangi bir kod uygulamanız gerekmez.
• Eksileri:
  • Tek bir alana bağlı. (Bu nedenle, birden fazla hizmete istekte bulunan tek sayfalık bir uygulamanız varsa, ters proxy gibi çılgın şeyler yapabilirsiniz.)
  • XSRF'ye karşı savunmasız. Sitenizi siteler arası istek sahteciliğine karşı korumak için ek önlemler almanız gerekir.
  • Her bir istek için gönderilir (kimlik doğrulaması gerektirmeyen istekler için bile).

Genel olarak, jetonların size daha iyi esneklik sağladığını söyleyebilirim (çünkü tek bir alana bağlı değilsiniz). Olumsuz kendiniz oldukça kodlama yapmak zorunda olduğunu.

• Jetonların bir yerde saklanması gerekir (yerel / oturum depolama alanı veya çerezler)

• Jetonların süresi çerezler gibi dolar, ancak daha fazla kontrole sahipsiniz

• Yerel / oturum depolaması etki alanlarında çalışmaz, işaretleme çerezi kullanın

• Ön kontrol talepleri her bir CORS talebine gönderilecektir

• Bir şeyi akışa almanız gerektiğinde, imzalı bir istek almak için jetonu kullanın

• XSS ile başa çıkmak XSRF'den daha kolaydır

• Jeton her istek üzerine gönderilir, büyüklüğüne dikkat edin

• Gizli bilgileri saklarsanız, jetonu şifreleyin

• JSON Web Jetonları OAuth'da kullanılabilir

• Jetonlar gümüş mermi değildir, yetkilendirme kullanım durumlarınızı dikkatlice düşünün

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Google çalışanları için :

• KARIŞTIRMAYIN statefulness ile devlet transferi mekanizmalarının

STATEFULNESS

• Stateful = yetkilendirme bilgilerini sunucu tarafında kaydet, bu geleneksel yol
• Durum bilgisi içermeyen = Yetkilendirme bilgilerini, bütünlük sağlamak için bir imza ile birlikte istemci tarafında kaydedin

MEKANİZMASI

• Çerez = tarayıcılar tarafından özel işlem gören (erişim, depolama, son kullanma tarihi, güvenlik, otomatik aktarım) özel bir başlık
• Özel Başlıkları = örn Authorization, herhangi bir özel tedavi olmadan sadece başlık olduğu, istemci transferi tüm yönleriyle kontrol zorundadır
• Diğer . Diğer aktarım mekanizmaları kullanılabilir, örneğin sorgu dizesi bir süreliğine kimlik kimliğini aktarmak için bir seçimdi, ancak güvensizliği nedeniyle terk edildi

GÜVENLİK KARŞILAŞTIRMASI

• "Durum bilgisi olan yetkilendirme", sunucunun kullanıcı yetkilendirme bilgilerini sunucuda saklayıp sakladığı anlamına gelir ve bu da yetkilendirmeleri uygulama durumunun bir parçası haline getirir
• Bu, istemcinin yalnızca bir "kimlik doğrulama kimliği" tutması gerektiği anlamına gelir ve sunucu, kimlik doğrulama bilgilerini veritabanından okuyabilir
• Bu, sunucunun etkin yetkilendirmeler havuzu (oturum açmış kullanıcılar) tuttuğunu ve bu bilgileri her istek için sorgulayacağını gösterir.
• "Durum bilgisi olmayan yetkilendirme", sunucunun kullanıcı yetkilendirme bilgilerini saklamadığı ve saklamadığı, hangi kullanıcıların oturum açtığını bilmediği ve yetkilendirme bilgisi üretmek için istemciye güvendiği anlamına gelir
• Yeni bir isim verilir, böylece istemci, bu daha adil auth kimliğine daha muhtemelen vb izinleri, son kullanma süresi, siz (kullanıcı kimliği) kim gibi tam auth bilgi saklayabilir ve edecektir belirteci
• Açıkçası istemciye güvenilemez, bu nedenle kimlik doğrulama verileri, hash(data + secret key)gizli anahtarın yalnızca sunucu tarafından bilindiği bir imza ile birlikte saklanır , böylece belirteç verilerinin bütünlüğü doğrulanabilir
• Belirteç mekanizmasının yalnızca dürüstlük sağladığını, ancak gizliliği değil, müşterinin bunu uygulaması gerektiğini unutmayın
• Bu aynı zamanda her istek için müşterinin ekstra bant genişliği gerektiren eksiksiz bir jeton göndermesi gerektiği anlamına gelir.

MEKANİZMA KARŞILAŞTIRMASI

• "Çerez" yalnızca bir başlıktır, ancak tarayıcılarda önceden yüklenmiş bazı işlemlerle
• Çerez sunucu tarafından ayarlanabilir ve istemci tarafından otomatik olarak kaydedilebilir ve aynı alan adı için otomatik olarak gönderilir
• Çerez, httpOnlyistemci JavaScript erişimini engelleyecek şekilde işaretlenebilir
• Önceden yüklenmiş işlemler, tarayıcılar (örn. Mobil) dışındaki platformlarda kullanılamayabilir ve bu da fazladan çaba gerektirebilir
• "Özel başlıklar" yalnızca önceden yüklenmiş işlemleri olmayan özel başlıklardır
• Müşteri, her istek için özel başlık bölümünü almak, depolamak, güvenli hale getirmek, göndermek ve güncellemekle sorumludur; bu, bazı basit kötü amaçlı URL yerleştirme işlemlerini önlemeye yardımcı olabilir

ÖZETLE

• Sihir yoktur, yetkilendirme durumu sunucuda veya istemcide bir yerde saklanmalıdır
• Cookie veya diğer özel başlıklarla durum bilgisi olan / durum bilgisi olmayan uygulamalar uygulayabilirsiniz
• İnsanlar bu şeyler hakkında konuştuğunda varsayılan zihniyet çoğunlukla: vatansız = simge + özel başlık, durum bilgisi olan = kimlik doğrulaması + çerez; bunlar sadece olası seçenekler DEĞİLDİR
• Artıları ve eksileri var, ancak şifreli jetonlar için bile hassas bilgileri saklamamalısınız

bağlantı

Burada bir karışıklık olduğuna inanıyorum. Çerez tabanlı kimlik doğrulaması ile artık HTML5 Web Depolama ile mümkün olan arasındaki önemli fark , tarayıcıların, onları ayarlayan alandan kaynak istediklerinde çerez verilerini göndermek için oluşturulduklarıdır. Çerezleri kapatmadan bunu engelleyemezsiniz. Tarayıcılar , sayfadaki kod göndermedikçe Web Depolama'dan veri göndermez . Ve sayfalar yalnızca sakladıkları verilere erişebilir, diğer sayfalar tarafından depolanan verilere erişemez.

Bu nedenle, bir kullanıcı çerez verilerinin Google veya Facebook tarafından kullanılma biçiminden endişe ediyor çerezleri kapatabilir. Ancak, Web Depolama'yı kapatmak için daha az nedenleri vardır (reklamverenler de bunu kullanmanın bir yolunu bulana kadar).

Yani, bu çerez tabanlı ve jeton tabanlı arasındaki farktır, ikincisi Web Depolama'yı kullanır.

Belirteç tabanlı kimlik doğrulama durumsuzdur, sunucunun oturumda kullanıcı bilgilerini depolaması gerekmez. Bu, kullanıcının oturum açtığı yerden endişe etmeden uygulamayı ölçeklendirme olanağı sağlar. Bu, jeton tabanlı bir sorun olmasa da, çerez tabanlı web Server Framework benzeşimi vardır. Dolayısıyla, aynı jeton, giriş yaptığımız alan adından başka bir uid / pwd kimlik doğrulamasını önleyen bir alan adından güvenli bir kaynak getirmek için kullanılabilir.

Burada çok iyi bir makale:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Şu durumlarda Token kullan ...

Federasyon isteniyor. Örneğin, belirteç düzenleyicisi olarak bir sağlayıcı (Token Dispensörü) kullanmak ve daha sonra belirteç doğrulayıcısı olarak api sunucunuzu kullanmak istersiniz. Bir uygulama Token Dispensor'da kimlik doğrulaması yapabilir, bir jeton alabilir ve ardından bu jetonu doğrulanması için api sunucunuza sunabilir. (Google Oturum Açma veya Paypal veya Salesforce.com vb. İle aynı şekilde çalışır)

Eşzamansızlık gerekli. Örneğin, istemcinin bir istekte göndermesini ve daha sonra ayrı bir sistem tarafından "daha sonra" uygulanacak şekilde bu isteği bir yerde saklamasını istersiniz. Bu ayrı sistem istemciyle senkronize bir bağlantıya sahip olmayacak ve merkezi bir token dispanseriyle doğrudan bağlantısı olmayabilir. bir JWT, iş öğesinin daha sonraki bir zamanda gerçekleştirilip gerçekleştirilemeyeceğini belirlemek için eşzamansız işleme sistemi tarafından okunabilir. Bu bir bakıma yukarıdaki Federasyon fikri ile ilgilidir. Yine de burada dikkatli olun: JWT'nin süresi doluyor. İş öğesini tutan kuyruk JWT'nin ömrü boyunca işlenmezse, taleplere artık güvenilmemelidir.

Cient İmzalı istek gerekiyor. Burada, istek özel anahtarını kullanarak istemci tarafından imzalanır ve sunucu istemcinin zaten kayıtlı genel anahtarını kullanarak doğrular.

Birincil farklılıklardan biri, çerezlerin Aynı Köken Politikasına tabi olmaları, ancak jetonların olmamasıdır. Bu, her türlü aşağı akış efektini oluşturur.

Çerezler yalnızca belirli bir ana bilgisayara ve belirli bir ana bilgisayardan gönderildiği için, kullanıcının kimlik doğrulaması yükünü taşıması gerekir ve kullanıcının doğrulanabilir olması için bu ana bilgisayarla güvenlik verileriyle bir hesap oluşturması gerekir.

Öte yandan jetonlar çıkarılır ve aynı menşe politikasına tabi değildir. İhraççı tam anlamıyla herkes olabilir ve hangi ihraççıların güveneceğine karar vermek ev sahibine bağlıdır. Google ve Facebook gibi bir yayıncı genellikle güvenilirdir, böylece bir ana bilgisayar kullanıcının kimlik doğrulama yükünü (tüm kullanıcı güvenlik verilerini depolamak dahil) başka bir tarafa kaydırabilir ve kullanıcı kişisel verilerini belirli bir yayıncı altında birleştirebilir ve hatırlamak zorunda kalmaz. etkileşim kurdukları her ana bilgisayar için farklı şifreler.

Bu, kullanıcı deneyimindeki genel sürtünmeyi azaltan tek oturum açma senaryolarına izin verir. Teoride, uzman kimlik sağlayıcıları, her ma ve pa web sitesinin kendi yarı pişmiş pişmiş kimlik doğrulama sistemlerini döndürmek yerine kimlik doğrulama hizmetleri sunmak için ortaya çıktıkça web daha da güvenli hale gelir. Ve bu sağlayıcılar sıfıra doğru çok temel kaynaklar için bile güvenli web kaynakları sağlama maliyeti ortaya çıkmaktadır.

Bu nedenle, genel olarak jetonlar, kimlik doğrulama sağlama ile ilişkili sürtünmeyi ve maliyetleri azaltır ve güvenli bir ağın çeşitli yönlerinin yükünü, güvenlik sistemlerini daha iyi uygulayabilen ve koruyabilen merkezi taraflara kaydırır.