İstemci uygulamalarından kullanıcı kimlik doğrulaması nasıl yapılır?

Birçok kullanıcıyı destekleyecek bir uygulama geliştiriyorum. Mesele şu ki, istemci / kullanıcının kimliğini nasıl doğrulayacağım.

Kullanıcılarıma kimlik bilgileri vereceğim http://quickblox.com/ gibi bir uygulama oluşturuyorum ve bunları kimlik doğrulaması için kullanıcı adlarını ve şifrelerini koyamayacakları N uygulamaları oluşturmak için kullanacaklar .

Diyelim ki aşağıdaki gibi gider. (Tıpkı QuickBlox gibi)

1. Kullanıcı web sitemde hesap oluşturur.
2. Kullanıcı N API anahtarları oluşturabilir ve kimlik bilgilerini gizleyebilir. (Birden çok uygulama için)
3. Kullanıcı, bu kimlik bilgilerini uygulamalarında (Android, iOS, Javascript vb.) REST API'lerimle konuşmak için kullanacaktır.
(REST API'lerinin okuma ve yazma erişimi vardır.)

Endişem?

Kullanıcılar, kimlik bilgilerini (API anahtarı ve salgılama anahtarı) oluşturdukları uygulamalara koyacaktır, biri bu anahtarları alır ve kullanıcıyı taklit etmeye çalışırsa? (APK'yı çözerek veya doğrudan JavaScript koduna bakarak.

Bir yerde yanlış mıyım?
Bu üç seviyeli kullanıcı mekanizmasını tasarlamak için kafam karıştı.

Son birkaç yıldır REST API'leri tasarlıyorum. Çok endişeleniyorsun. Son zamanlarda bu karttaki başka bir kullanıcı, JavaScript istemci tarafı kodunda URI uç noktalarını depolamaktan endişe duyduğu bir soru sordu .

JavaScript geliştiricisi için geçerli olan aynı kurallar geçerlidir. Dışarıdaki kişilerin API'nızı entegre etmesine izin verirseniz, API'nız normal bir web sitesiyle aynı görünürlüğe sahiptir ve aynı şekilde davranmanız gerekir.

Orijinal cevaptan alıntı:

Bir web sitesi oluştururken ve kullanıcıların bir şey yapmasını istemediğinizde, bu işlevselliği uygulamıyor veya belirli kullanıcıların siteyi kullanmasını yasaklamıyorsunuz. Herkese açık uç noktalara sahip olması gereken bir REST API ile hemen hemen aynıdır, herkese açık bir web sitesi gibi davranmanız gerekir.

REST API'niz, farklı bir kullanıcıdan gelen verilere erişim gibi geçersiz işlemlere izin vermeyecek kadar sağlam olmalıdır.

Uygulama erişim simgelerinizi yalnızca izin verilmesini istediğiniz işlemlere izin verecek şekilde tasarlamalısınız. İki tür erişim belirteciniz olabilir:

• ana simge : uygulama oluşturucu tarafından kullanılabilir ve API'nızdan daha fazla işlevsellik sağlayabilir,
• uygulama belirteci : gerçekte uygulamalar içinde depolanacak ve API'nize yalnızca sınırlı erişiminiz olacak, yalnızca sizinkini veya uygulama programcısının verilerini bozamayan işlemler için belirteç.

Ama birisi kaynak kodun yapısını bozar, belirteçleri uygulamadan çıkarır, genel uç noktaların ne olduğunu öğrenir ve web hizmetinizi kötüye kullanır?

API'nizi tüketen uygulamaların gelişimini doğrudan yönetmediğiniz sürece, hiçbir şey insanların API'nızı doğrudan uygulamadan aynı şekilde kötüye kullanmasını gerçekten yasaklamaz.

Sorununuz bir işletme kadar teknik değil.

Diyelim ki müşterilerinize (uygulama geliştiricileri) yılda 100 £ sabit ücretle sınırsız erişim için sattığınız API'nız var.

Açıkçası, 100 £ 'dan hizmet satın alabilir ve her biri 50 $' dan 10 kişiye satabilirim. Bunu istemiyorsun! böylece API'nızı arbitrajlamaya açık olmadan satmanıza izin verecek bir kısıtlama düşünmeye çalışırsınız.

• Yalnızca Uygulama sayısını kısıtlarsanız, müşteri diğer uygulamalardan gelen bağlantıları kabul eden ve uygulayan tek bir uygulama oluşturabilir.

• Kullanıcıları sınırlarsanız, müşteri kullanıcıları kendi kimlik doğrulamasının arkasına gizleyebilir ve tek bir kullanıcı gibi görünebilir.

Yapmanız gereken, her API çağrısının maliyetini müşterinize aktarmaktır. yani her API çağrısı için ücretlendirme veya yıllık çağrı kotası ayarlama.

Bu, aynı arbitraj sorununu müşterilerinize aktarır. Kullanıcıların anahtarlarını çalmasını önlemek için önlem almaları için onları zorlar. Bu durumda, API'nizi kullanıcı kimliği doğrulanmış API'larının arkasına gizleme.

Diğer yanıtların hepsi, bir uygulamada bir sırrı tüketici cihazlarında saklama sorununun çözülemediğini gösteriyor gibi görünüyor.

Tabiki öyle.

İki ilke (uygulama ayrıntıları aşağıdadır):

1. Gerçek kimlik doğrulama uç noktalarının anonim olarak halka açık olması gerekir.
2. Sunucunun bir şekilde istemcinin kimliğini doğrulamak ve bir API anahtarı sağlamakla ilgili olması gerekir.

İstemci kimlik bilgileriyle kimlik doğrulama bitiş noktasına bir istekte bulunursa ve sunucu kimlik doğrulaması yaparsa, sunucu dinamik bir geçici belirteç oluşturabilir (geçici anlam zamana dayalı). Bu belirteç, istemci içinde hatırlanmalı ve sonraki isteklerle gönderilmelidir.

Simgeyi periyodik olarak "yenilemek" için bir mekanizmaya ihtiyacınız olacak, yani yeni bir tane alacaksınız. Kimlik bilgilerinden yeniden kimlik doğrulaması yapmaktan kaçınmak için mevcut bir koddan yeni bir belirteç oluşturmanıza izin veren bir REST uç noktası oluşturmanız yeterlidir.

Son kullanıcının kendilerini yeniden doğrulamasından kaçınmaya çalışıyorsanız, bu kimlik doğrulama, yüklendiğinde uygulamada bir kerelik ilk kurulum olabilir.

Bu çözüm, uygulama ikili dosyasına gömülü bir statik belirtecin saklanması ihtiyacını ortadan kaldırır. Sunucu, yalnızca başarılı bir kimlik doğrulamasına yanıt olarak anında oluşturulur. Kötü niyetli bir kullanıcının uygulamanızı incelemesi ve yetkisiz API erişimi elde etmeye çalışması için, tıpkı herkes gibi kimlik doğrulaması yapması gerekir.

Benzersiz uygulama başına anahtarlarınız varsa, bunları yalnızca istemci tarafından başlatılan ilk bağlantı kimlik doğrulaması sırasında kullanabilirsiniz, daha sonra uygulama başına hareketli benzersiz kimlik doğrulama belirtecine geçebilirsiniz.

Sunucunuz zaman zaman her istemci uygulaması için jetonu değiştirir (döndürür) (örneğin, düzenli olarak artı / eksi bazı rastgele bulanık / rastgele gecikmeler). Dönen simge yalnızca sunucu ile kimliği doğrulanan istemci arasında bilinir.

Yeni jetonlar, düzenli yanıtlarda domuzcuk destekli olarak iade edilir. Yanıt her yeni bir simge içerdiğinde, alıcı uygulamanın sonraki isteklerde bu uygulamaya geçmesi gerekir.

Ne zaman bir istemci ile değişim senkronize edilmezse (bir çeşit protokol hatası) sunucunuz yeniden kimlik doğrulama talep eder (bir sonraki müşteri talebine bir hata cevabı aracılığıyla veya istemci talebine geçerli bir yanıtta piggy ile desteklenir) misal).

Yuvarlanan bir belirteç etkin olarak kullanılırken müşteriler tarafından başlatılan ilk kimlik doğrulaması şüphe ile ele alınmalıdır - bu taklit edici bir girişim olabilir. Sadece değişim beklenenden daha uzun bir süre boyunca boşta kalırsa izin veririm, örneğin, bir istemci kesintisi / yeniden başlatma belirteci olmayan yeni bir örnekle yeniden başlatmadan kaynaklanabilir.

Yeniden başlatılan bir istemcinin selefinin kaldığı yerden devam edebilmesi için belirteci istemci tarafında ısıtmak daha da iyi olur - taklit için açıklığı önemli ölçüde daraltır.

Böyle bir plan taklit etmeyi en azından oldukça zorlaştıracaktır - taklit eden istemci, sunucunun belirtilen anahtarla yeni bir istemci kimlik doğrulamasının kabul edilmesinin uygun olduğuna karar vermesi için yeterince uzun istekleri göndermeyi bıraktığında pencereyi tam olarak tahmin etmek zorunda kalacaktır. İzin verilen pencerenin dışındaki bu tür istekler, taklit etme girişimlerinin tespiti olarak ve muhtemelen bazı karşı önlemleri (IP kara listesi, vb.) Başlatmak için kullanılabilir.

Bildiğim kadarıyla, bahsettiğiniz şey bunu yapmanın tek yoludur. Anahtarı saklayan uygulama kesinlikle bir risktir, ancak onu atlatmanın çeşitli yolları vardır. Anahtar deposunu her zaman anahtarı saklamak için kullanabilirsiniz, böylece kodlamadan ziyade bir kerelik giriş yapmaya zorlarsınız.

Ayrıca, bir istemciye bir anahtar bağlamayı düşünmelisiniz, bu nedenle birisi taklit ederse, istemciyi, anahtarı ve kullanıcı aracılarını isteği hemen engellemek için bir güvenlik katmanına sahip olmalısınız. Anahtarların taklit edilmediğinden emin olmak veya yeniden vermek için bir kullanım vakası bulundurun.

Müşterilerinizin uygulamalarına koymaları için yetkilendirme jetonları vermeye bağlıysanız, birisinin uygulamayı tersine çevirip bunları çıkarması teorik olarak her zaman mümkün olacaktır. Bunu önlemek için, istemci uygulamasında bir sır gerektirmeyecek bir mekanizmaya ihtiyacınız olacaktır. Bu zor. Yine de düşünmeniz için bazı seçenekler önerebilirim.

Kimlik bilgilerini verdikten sonra bir sorununuz var, bunların ne kadar güvenli bir şekilde saklanacağı konusunda hiçbir kontrolünüz yok. Ayrıca, kullanıcının kimlik bilgilerini size göndermesini isterseniz, birileri bağlantınızı MITM yapabilir ve uygulamayı tersine mühendislikle uğraşmadan doğrudan jetonları çalabilir.

Yetkilendirme simgenizi çıkarmayı daha zor hale getirmenin bir yolu, onu gizlemek. Bu sadece çıtayı yükseltiyor, ama imkansız kılmıyor ve bunu yapmak için sırrın kontrolünü elinizde tutmanız gerekecek. Gizli bilgileri içeren ve her müşteriye özgü bir kitaplık uygulayabilirsiniz. Kütüphaneyi sunucularınızla iletişim kurmak için kullanabilirsiniz ve hatta kullanıcıya gizli bilgileri söylemek zorunda kalmayabilirsiniz, sadece kütüphaneye gömülebilir. Bu, birisinin kütüphanenizi tersine mühendislik problemini çözmez, ancak sizi şaşırtma düzeyini kontrol altına almanızı sağlar. Bir dezavantajı, bir kişi kütüphanedeki şaşkınlığı kırdıktan sonra, her kütüphaneyi önemli ölçüde farklı kılan kod yazmadıkça, herhangi bir kütüphanenize saldırabilir. Bu kendi problemlerini ortaya koyuyor.

Bu, sorunuzun kapsamından biraz sapabilir, ancak jetonunuzun güvenliği ile ilgilidir, bu yüzden bundan bahsedeceğim. Simgenin tel üzerinden önemsiz hırsızlığını önlemek için, muhtemelen simgeyi doğrudan göndermek istemezsiniz, bunun yerine bir HMAC işlevi kullanarak trafiği imzalayabilirsiniz. İletinin sunucudaki iletisinin HMAC'sini hesaplayıp istemciden gönderilen HMAC ile karşılaştırarak iletinin geçerliliğini denetleyebilirsiniz. Simgeyi HMAC işlevinin anahtarı olarak kullanırsınız, böylece yalnızca jetonu bilen biri trafiği imzalayabilir. Bu, simgenizin güvenliği için daha iyidir çünkü asla doğrudan sunucuya göndermezsiniz, böylece doğrudan yakalanamaz ve çalınamaz. HMACS hakkında daha fazla bilgi için şu soruya bakın: /security/20129/how-and-when-do-i-use-hmac/20301

Hiçbir güvenlik çözümü emprenye edilemez, tehlikeye girme olasılığına ve maliyetine karşı uygulamanızın ne kadar tutacağına karar vermelisiniz.

Kendinizden alıntı:

İstemcinin / kullanıcının kimliğinin nasıl doğrulanacağını anlayamıyorum ... kimlik doğrulaması için kullanıcı adlarını ve şifrelerini koyamadıkları.

Şimdi bu biraz çelişki, değil mi? ;)

Diğerlerinin söylediği gibi yapamazsınız. Bir Uygulama bir API anahtarı kullanıyorsa, anahtar (lar) ı almak ve kullanmak için dediğiniz gibi koda dönüştürebilirsiniz.

Ek doğru kullanıcı kimlik doğrulaması gerektirmekten başka, yalnızca hasarı sınırlayabilirsiniz:

• beyaz liste / kara liste IP'leri
• daraltma
• "olağandışı aktivite" tespiti ve kaynağı
• kolay anahtar yenileme