Uygulamalarınız için kendi kimlik doğrulamanızı oluşturmanız gerekiyor mu?

Arka Plan#

Birçok geliştiricinin "Uygulamam için kendi kimlik doğrulamamı oluşturmalı mıyım?" gibi sorular sorduğunu gördüm. Cevap basit bir "Evet" veya "Hayır" olamamasına rağmen, uygulamanın nasıl ayrıştırılacağını ve artılarını ve eksilerini göstermek için bir makale yazmak istiyorum.

ÖZET Gerçekten tam kontrol istemedikçe veya hala yazılım geliştirme üzerine öğrenmeye devam etmedikçe, ihtiyaçlarınıza uygun bir mevcut çözümü bulmak gereklidir.

Giriş#

Bir geliştirici olarak, kariyerim boyunca birçok uygulama oluşturdum. Programlama dilinden bağımsız olarak, her zaman oluşturmam gereken ortak bir temel vardır: kullanıcı kimlik doğrulaması.

20 yıl öncesine döndüğümüzde, her şey çok basit olduğu için önemsiz bir bölüm oldu:

• Kullanıcı adı ve parola ile bir kayıt ve oturum açma sistemi uygulayın.
• Bir kullanıcının oturumunu sürdürmek için bir mekanizma oluşturun.
• Güvenlik hakkında? MD5 cevaptır.

O kadar. O zaman "gerçek işe" odaklanabilirdim. MD5 hakkında hiç duymadınız mı? Yazılım geliştirmenin "iyi zamanları"nı kaçırdınız. Bugünlerde, geliştiriciler oturum açma/üye olmayı oluştururken daha fazla zorlukla karşı karşıya.

Korkutucu geliyor, ama bir örnekle anlatmama izin verin.

Örnek: Çevrimiçi bir kitapçı#

Bir API hizmeti ve bir web önyüz uygulamasıyla bir çevrimiçi kitapçı oluşturmaya çalıştığınızı varsayalım.

Öncelikle, "kimlik doğrulama"nın kapsamı tanımlanmalıdır. Kimlik doğrulama, kimlik doğrulama ve yetkilendirme olarak açıklanabilir ve bunların tamamen farklı tanımları ve kullanım durumları vardır:

Bu konseptleri ayrıntılı olarak tartışmak için bir makale yazdım CIAM 101: Kimlik Doğrulama, Kimlik, Tekli Oturum Açma.

Kimlik doğrulama yöntemlerini seçin#

"Kimlik doğrulama" ile başlayalım, bu örneğimizde kullanıcı oturum açma. Kullanıcı adı ve parola yöntemi dışında, daha iyi bir kullanıcı dönüşümü ve güvenliği için bazı popüler yöntemleri benimsiyorlar:

• Şifresiz, yani dinamik doğrulama kodu (e-posta veya sms aracılığıyla)
• Sosyal oturum açma (Google, Facebook vb.)

Yöntem seçimi, iş kararına bağlıdır, ancak teknolojideki çabayı görebiliriz:

• Şifresiz için, doğrulama kodlarını e-posta veya sms aracılığıyla gönderen bir satıcı bulmanız ve hizmetinize entegre etmeniz gerekir (yeni API'lar gerekebilir).
• Sosyal oturum için, kullanmayı istediğiniz sosyal kimlik sağlayıcı(lar)ının entegrasyon yönergelerine uymalısınız. Ayrıca, kitapçınızın kullanıcı kimlikleri ile kimlik sağlayıcının kimliği arasında bir eşleme oluşturmalısınız.
  • Örneğin, bir kullanıcı bir Gmail hesabı [email protected] ile oturum açtığında, bu e-posta adresini kitapçıdaki foo kullanıcısına bağlayabilirsiniz. Bu süreç, tek bir kimlik sistemi oluşturmanıza yardımcı olur ve kullanıcının gelecekte sosyal kimliğini değiştirmesine veya bağlantısını kesmesine olanak tanır.

Oturum açma deneyimini tasarlayın ve uygulayın#

Kimlik doğrulama yöntemlerine karar verdikten sonra, son kullanıcılarınız için zarif ve sorunsuz bir oturum açma deneyimi hedefinizdir. İşletme açısından buradaki dönüşüm temeldir ancak önemlidir, çünkü bu, kalıcı müşteri verilerini bırakmanın doğal bir yoludur.

Airbnb'de çalışırken, birden çok platform için oturum açma deneyimini en üst düzeye çıkarmaya adanmış bir ekip vardı. Hangi kombinasyonun en yüksek dönüşüm oranına sahip olduğunu belirlemek için sayısız A/B testi yaptılar.

Bir iş başladığında böyle yapmak pratik değildir. Ancak her parçayı doğru yapmak için elimizden gelenin en iyisini yapmamız gerekiyor. Kitapçınızı hangi platformlarda çalıştırmak isterdiniz? Mobil, web veya her ikisi ile başlayabilirsiniz. Tam tasarım, seçtiğiniz kimlik doğrulama yöntemlerine bağlı olacaktır:

• Kullanıcı adı ve parola: En kolayı, sadece birkaç giriş kutusu ve düğme.
• Şifresiz: Telefon / e-posta girin, ardından bir dinamik kodu gönderin ve doğrulayın.
• Sosyal oturum açma: Seçilen sosyal kimlik sağlayıcının belgelerini okuyun, görsel kılavuzu izleyin, yönlendirme mantığını işleyin ve nihayet sosyal kimliği kitapçı kimliğiyle bağlayın.

Daha iyisini yapmak için düşünülmesi gereken daha fazla şey:

• Belirli bir yöntem için oturum açma ve kayıt süreçlerini birleştirmeniz gerekiyor mu?

• Müşterilerin kendi parolalarını bağımsız olarak sıfırlamalarına izin vermek için "parolamı unuttum" iş akışına ihtiyacınız var mı?

Yerli geliştirme seçerseniz, ek bir platform için iş yükü neredeyse iki katına çıkar.

Güvenlik ve belirteç değişimi#

Güvenlik gizli bir buzdağı olabilir. OpenID Connect veya OAuth 2.0 ile tanıdıksanız harika olur, çünkü yaygın olarak kullanılırlar ve savaş test edilmişlerdir. OpenID Connect nispeten yenidir, ancak "kullanıcı kimlik doğrulaması" için tasarlanmıştır, bu da bir çevrimiçi kitapçı için mükemmel bir uygundur.

Standartların ayrıntılarına girmeden, hala bazı şeyleri düşünmek gerekiyor:

• Parolalar için hangi şifreleme yöntemi kullanılmalı?

• Standart kimlik doğrulama ve yetkilendirme süreci nedir?

• Belirteç değişimi nasıl çalışır (Erişim Belirteci, Yenileme Belirteci, Kimlik Belirteci vb.)?

• Belirteçlerde imza anahtarları nasıl kullanılır ve kaynakları korumak için imza nasıl doğrulanır?

• İstemci ve sunucu saldırıları nasıl önlenir?

Sonunda, kullanıcılarınıza iyi bir oturum açma deneyimi sunabilir ve onlara sunabilirsiniz.

Yetkilendirme modeli#

Bir kitapçı olarak, müşteriler ve satıcılar için kaynakları ayırmanız gerekiyor. Örneğin, müşteriler tüm kitapları gözden geçirebilirken, satıcılar kendi satışta olan kitaplarını yönetebilirler. İş büyüdükçe, Rol Tabanlı Erişim Kontrolü (RBAC) veya Özellik Tabanlı Erişim Kontrolü (ABAC) gibi daha esnek bir model uygulamak gerekebilir.

Ben de bir makale yazdım CIAM 102: Yetkilendirme ve Rol Tabanlı Erişim Kontrolü temel yetkilendirme kavramlarını ve RBAC modelini göstermek için.

Kararı verin#

Kimlik doğrulamanın "hepsi veya hiçbiri" olmadığını görebilirsiniz, çünkü çok sayıda teknik bileşen içerir ve siz veya ekibiniz bu alanlarda farklı teknik uzmanlığa sahip olabilir. Durumu daha iyi anlamak için küçük parçalara ayırmak önemlidir.

Kararı vermek için kendime aşağıdaki soruları sorarım:

• Projenin aciliyeti ne kadar?

• Kimlik doğrulama konusunda işe ne kadar çaba harcamayı bekliyorum?

• Kullanıcı deneyiminin, güvenliğin ve bakımın önceliği nedir?

• Hangi bölüm(ler)in tam kontolününe ihtiyacım var? Bunlarla ne kadar aşina olmalıyım?

• Eğer bazı çerçeveler / çözümlerle gidersem, özelleştirme veya genişletme için yeterince iyiler mi?

• İş büyüdükçe, yeni bir kimlik doğrulama modeli tanıtmam gerekecek mi?

• Uygun bir satıcı bulursam, kullanmak yeterince güvenli mi? Satıcıyla ilgili herhangi bir şey olursa, çekilme planına ihtiyacım olacak mı?

Soruları aklımda tutarak, iki gerçeği keşfettim:

• Güvenilir bir kimlik doğrulama sistemi oluşturmak oldukça karmaşıktır.

• Mevcut satıcılar, gerekli tüm kriterleri karşılayamaz.

Bu yüzden, kimlik doğrulama için ö dedicatedik bir proje (Logto) başlatmaya karar verdim ve ilk günden itibaren açık kaynaklı topluluğu kabul ettim.

Bu makalenin yardımcı olmasını umarım.