Kimlik doğrulama hakkında okudum ve tip sınıflandırması konusunda kafam karıştı.

Çerez tabanlı kimlik doğrulamasından başlayalım, Doğru anlarsam, kilit nokta, kullanıcı kimlik doğrulaması için gerekli tüm verilerin çerezlerde depolanmasıdır. Ve bu benim ilk kargaşam: kurabiyelerde saklayabiliriz

• oturum kimliği ve böylece Oturum tabanlı bir kimlik doğrulama olur?
• iddialar ve Talep tabanlı kimlik doğrulaması olarak mı adlandırılmalıdır?
• Bazı insanların JWT token'ı çerezlerde bile sakladığını buldum, ancak bu kendi kimlik doğrulaması akışının özel bir uygulaması gibi görünüyor ...

Şimdi Hasar bazlı kimlik doğrulamasına geçelim. Ana unsur taleptir ve taleplerin toplanması konteyner olarak kullanılabilir

• çerezler (yukarıda tartışıldığı gibi)
• belirteci (örnek olarak JWT).

Diğer taraftan, belirteçten bahsederken, her türlü bilgiyi içerebilir ... Örneğin Oturum Kimliği ...

Peki neyi kaçırdım? Kimlik doğrulama türleri hakkında konuşurken insanlar neden bir şey Cookie-Session-basedveya Token-Claims-basedkimlik doğrulama tanımıyorlar ?

Farklı kavramların isimlerinin kafa karıştırıcı olduğuna katılıyorum. Bir web bağlamında doğrulama hakkında konuşurken, göz önünde bulundurulması gereken birkaç husus vardır.

Müşteri kimlik doğrulaması yaparken hangi bilgileri gönderir?

• Bir oturum kimliği . Bu, sunucunun etkin oturumları içeren bir oturum deposuna sahip olduğu anlamına gelir. Oturumlar sunucu tarafında durumsaldır .
• Birtakım iddialar . Talepler, müşterinin gerçekleştirebileceği işlemler hakkında bilgi içerir. Sunucu kimliği doğrulanan her istemciyi izlemez, ancak taleplere güvenir. Talepler genellikle sunucu tarafında durumsuzdur .

Müşteri kimlik doğrulama bilgilerini nasıl gönderir?

• Çerezler . Tarayıcılar, çerez ayarlandıktan sonra her istekle otomatik olarak çerez gönderir. Çerezler, XSRF'ye açıktır.
• Diğer başlıklar . Genel olarak, Yetkilendirme başlığı bunun için kullanılır. Bu başlıklar tarayıcı tarafından otomatik olarak gönderilmez, ancak istemci tarafından ayarlanması gerekir. Bu, XSS'ye karşı savunmasızdır.
• URL iste . Kimlik doğrulama bilgisi URL’ye dahil edilmiştir. Bu yaygın olarak kullanılmaz.

Kimlik doğrulama bilgilerinin formatı nedir?

• Düz, imzasız metin . Bu oturum kimlikleri için kullanılabilir. Bir oturum kimliği genellikle müşteri tarafından tahmin edilemez, bu nedenle sunucu istemcinin sahte olmadığı konusunda güvenebilir.
• Json Web Simgesi . JWT'ler kriptografik olarak imzalanmıştır ve son kullanma tarihini içerir. İstemci genellikle belirtecin kodunu çözebilir, ancak sunucu fark etmeden değiştiremez.
• Başka herhangi bir imzalı format . JWT'lerle aynı. Önemli olan, müşterinin verileri değiştirmesini önleyen şifreleme imzasıdır.

Bonus: Müşteri bilgileri yerel olarak nasıl depolar?

• Çerezler . Elbette bu bilgi iletmek için çerezleri kullanırken söz konusudur. Ancak Çerezler, sadece bir müşteri tarafı depolama mekanizması olarak da kullanılabilir. Bu, çerezin kullanışlı olması için komut dosyalarından okunabilir olmasını gerektirir. Örneğin, bir müşteri çerezi JavaScript ile okuyabilir ve bilgileri bir Yetkilendirme Başlığı ile gönderebilir.
• Yerel Depolama . Çerezler kullanılamıyorsa, bu genellikle mümkün olan tek yöntemdir. JavaScript ile yönetim gerektirir.

İnsanlar söylediklerinde ne demek istiyorlar ...

• "Çerez tabanlı kimlik doğrulama" . Bunun genellikle "Oturum kimliği, çerezle gönderme, düz metin olarak mümkün" anlamına geldiğini biliyorum.
• "Token tabanlı kimlik doğrulama" . Genellikle bu, "Json Web Simgesi olarak kodlanan kimlik doğrulama başlığını kullanarak gönderen talepler" anlamına gelir.
• "Hak temelli kimlik doğrulaması" . Bir oturum kimliği dışında herhangi bir şey olabilir.

Basit ifadeyle,

1. Çerez Tabanlı Kimlik Doğrulama

   • Web istemcisi (örneğin: web tarayıcı) başarılı bir kimlik doğrulama işleminden sonra web sunucusu tarafından gönderilen çerezleri saklar.
   • Çerez, çerezi belirlemek için kullanıcı, müşteri, authN zaman damgası ve unique-id ile diğer faydalı veriler hakkında bilgi içerir.
   • Tipik olarak, çerez etki alanı özniteliği ayarlanmış (ör::) web sunucusu tarafından şifrelenir google.comve web istemcisine gönderilir.
   • Web müşterisi etki alanı kaynağına erişmek istediğinde (örneğin mail.google.com:), etki alanına dayalı tüm çerezleri (örneğin:) google.comweb sunucusuna gönderir ; kurabiye.

2. Oturum Tabanlı Kimlik Doğrulama

   • Web istemcisi çereziyle birlikte, bir web sunucusu kullanıcı authN verilerini arka uçlarında saklarsa, Oturum tabanlı kimlik doğrulama adı verilir.
   • Bu, web istemcisinin erişmemesi gereken sisteme erişim kazanması durumunda herhangi bir ihlal durumunda daha sonra arka uçtan itibaren web istemcisinin oturumu yönetici tarafından iptal edilebilir.

3. Belirteç Tabanlı Kimlik Doğrulama

   • Genel olarak bu, çerez istemcisinin istemci tarafında depolanmasının mümkün olmadığı web istemcisi olmayan senaryolarda kullanılır.
   • Bu nedenle, web sunucusu başarılı kimlik doğrulamasından sonra istemciye imzalı simgeyi (kullanıcı, müşteri, authN zaman damgası ve benzersiz kimliğe sahip diğer yararlı veriler hakkında bilgi içerir) gönderir.
   • Bir müşteri bir kaynağa erişmek istediğinde, bu jetonu göndermesi gerekir ve web sunucusu kaynağa erişmesine izin vermeden önce kodu doğrular / doğrular.

4. Talep Tabanlı Kimlik Doğrulama

   • Bu, belirteç tabanlı kimlik doğrulamasıyla aynıdır, yalnızca müşteri ve / veya müşteri ile ilişkili kullanıcı hakkında belirteç üzerine biraz daha veri ekler.
   • Bu veriler, müşterinin kaynak içinde ne yapacağı hakkında konuşan (örneğin: mail.read, mail.delete, calendar.read) yetkilendirme ile ilgilidir.