Bazı terimleri ve mekanizmaları anlamaya ve bunların birbirleriyle nasıl ilişkili olduklarını veya nasıl örtüştüklerini bulmaya çalışıyorum. Teorik bir web uygulamasının ve mobil uygulamanın kimlik doğrulaması odak noktasıdır. Odak noktası, belirteç tabanlı kimlik doğrulama ile çerez tabanlı kimlik doğrulama arasındaki tam fark ve bunların kesişip kesişmediği / nasıl kesiştiğidir.
http basic/digest ve oauth/aws auth gibi karmaşık sistemler beni ilgilendirmiyor
Ortaya atmak ve doğru olup olmadıklarını görmek istediğim birkaç iddiam var.
İşaretten çok uzak olmadığımı umuyorum ve her türlü yardım için minnettarım!
Oturum Tabanlı Kimlik Doğrulamada** Sunucu tüm ağır işleri sunucu tarafında yapar. Genel olarak bir istemci kimlik bilgileriyle kimlik doğrulaması yapar ve bir session_id
alır (bir çerezde saklanabilir) ve bunu sonraki her giden isteğe ekler. Dolayısıyla bu bir "token" olarak düşünülebilir çünkü bir dizi kimlik bilgisine eşdeğerdir. Bununla birlikte, bu session_id
dizesi hakkında süslü bir şey yoktur. Bu sadece bir tanımlayıcıdır ve geri kalan her şeyi sunucu yapar. Bu durumsaldır. Tanımlayıcıyı bir kullanıcı hesabıyla ilişkilendirir (örneğin bellekte veya bir veritabanında). Bu oturumu belirli işlemlerle veya belirli bir süreyle kısıtlayabilir veya sınırlayabilir ve güvenlik endişeleri varsa geçersiz kılabilir. Daha da önemlisi, tüm bunları anında yapabilir ve değiştirebilir. Ayrıca kullanıcının web sitelerindeki her hareketini kaydedebilir. Olası dezavantajları kötü ölçeklenebilirlik (özellikle birden fazla sunucu çiftliği üzerinde) ve yoğun bellek kullanımıdır.
Token tabanlı Kimlik Doğrulamada** hiçbir oturum sunucu tarafında kalıcı değildir (durumsuz). İlk adımlar aynıdır. Kimlik bilgileri bir belirteçle değiştirilir ve bu belirteç sonraki her isteğe eklenir (bir çerezde de saklanabilir). Ancak bellek kullanımını azaltmak, kolay ölçeklenebilirlik ve tam esneklik (belirteçler başka bir istemci ile değiştirilebilir) amacıyla, istemci tarafından sunucuya yapılan her istekten sonra kontrol edilen gerekli tüm bilgileri içeren bir dize (belirteç) verilir. Belirteçleri kullanmanın/oluşturmanın birkaç yolu vardır:
HMAC-SHA1 gibi bir karma mekanizma kullanarak
token = user_id|expiry_date|HMAC(user_id|expiry_date, k)
burada user_id
ve expiry_date
düz metin olarak gönderilir ve sonuçta hash eklenir (k
sadece sunucu tarafından bilinir).
Simgenin simetrik olarak şifrelenmesi, örneğin AES ile
token = AES(user_id|expiry_date, x)
Burada x
en-/şifre çözme anahtarını temsil eder.
Asimetrik olarak şifreleme, örneğin RSA ile
token = RSA(user_id|expiry_date, özel anahtar)
Üretim sistemleri genellikle bu iki arketipten daha karmaşıktır. Örneğin Amazon, web sitesinde her iki mekanizmayı da kullanır. Ayrıca hibritler, 2'de açıklandığı gibi belirteçler vermek ve ayrıca kullanıcı takibi veya olası iptal için bir kullanıcı oturumunu onunla ilişkilendirmek ve yine de klasik belirteçlerin istemci esnekliğini korumak için kullanılabilir. Ayrıca OAuth 2.0, taşıyıcı belirteçleri almak için kısa ömürlü ve belirli taşıyıcı belirteçleri ve daha uzun ömürlü yenileme belirteçleri kullanır.
Kaynaklar:
HTTP durumsuzdur ve kimliği doğrulanmış bir duruma sahip olmak için, kullanıcı hakkındaki bilgilere başvurmak için kullanılan bir tür belirtece ihtiyacınız vardır. Bu oturum kimliği genellikle çerez değeri olarak gönderilen rastgele bir belirteç şeklindedir. Bir OAuth Erişim Belirteci, bir kullanıcıyı ve o kullanıcının erişebileceği kaynakların `kapsamını' tanımlamak için kullanılır. OAuth tek oturum açma kullanan uygulamalarda, OAuth Erişim belirteci tipik olarak daha geniş bir kullanıcı durumunu takip edebilen bir oturum kimliği ile değiştirilir.
Bir saldırganın bakış açısından, bir oturum kimliğini veya OAuth Erişim Belirtecini ele geçirmek, bir kullanıcı adı ve parola kadar iyidir ve bazen daha da iyidir. Oturum kimlikleri, kullanıcı hesaplarını tehlikeye karşı koruyan güvenlik özelliklerine sahip olmalıdır.
Geliştirici açısından bakıldığında, asla tekerleği yeniden icat etmeyin. Platformunuz tarafından sağlanan oturum yöneticisini kullanın ve OWASP Oturum Yönetimi yönergeleri ile uyumlu olacak şekilde yapılandırıldığından emin olun.
Bu nedenle, oturum tabanlı kimlik doğrulamasında, kaynaklara erişimde güvenliği artırmak için hangisi gereklidir: