OAuth2'yi kullanmak için mevcut eski web uygulamasını taşıma


10

Şu anda 1 milyona yakın kullanıcısı olan 15 yıllık bir eski monolitik web uygulamam var, evde yetiştirilen bir yetkilendirme ve kimlik doğrulama sistemi kullanıyorum: JAAS, kullanıcı adları ve pwds temel şifre karma, bazı 2FA kişisel doğrulama soruları (farklı ile karma algoritmalar, vb.).

Önümüzdeki 12-18 ay boyunca, öncelikle kullanıcı arayüzüne odaklanan, ancak altta yatan parçaları da yavaşça yükselten (Spring, Spring Security, vb. Bu proje dahilinde, modül bazında kullanıcı arayüzü güncellemesini ele almaya karar verdik; tamamlandıktan sonra her modülü kullanılabilir hale getirmek; monoliti bireysel webapps'lere ayırmak için mükemmel bir fırsat (hepsi aynı UX tasarımını koruyor).

Bunu planlamaya çalışırken takılıp kaldığım kimlik doğrulama ve yetkilendirme düzeyindedir. Bir kullanıcı bir web uygulamasından diğerine yönlendirildiğinde, sorunsuz bir geçiş olduğu için tüm modüller üzerinde yayılacak bir çapraz kesme çözümüne ihtiyacım var - farklı webapps'lerde olduklarını bile bilmeyecekler. OAuth2 mükemmel bir çözüm gibi geliyor.

Bunu nasıl entegre edeceğimizi anlamaya çalışıyorum. Kendi özel OAuth2 sunucumu oluşturmam gerekiyor mu? Bu bana korkunç bir fikir gibi geliyor. Ama nasıl yaparım:

  1. tüm kullanıcı hesaplarımı ve yetkilendirme sürecimi üçüncü taraf bir OAuth2 sunucusuna taşı
  2. görünümü ve hissi uygulamamın geri kalanına uyacak şekilde özelleştir (bunun ne kadar kolay / muhtemel olacağını bilmiyorum)
  3. 3. taraf bir sunucu üzerinden bağlanırken tipik "XYZ hesabınıza erişmek için izin istiyor ..." açılır penceresini engeller misiniz? (ör. Google OpenID, Facebook vb.).

Amacım, kullanıcı için mevcut durumdan yeni duruma sorunsuz bir geçiş sağlamak, ancak webapp dışında kimlik doğrulaması ve yetkilendirme yapan ayrı webapps oluşturma olanağı sağlamaktır.


Bir TOA'nın yeterli olup olmadığını merak ediyorum. OAuth bana burada ihtiyaç duyduğunuz türde bir sistem gibi görünmüyor. CAS'a
Laiv

Yanıtlar:


2

Açıklama : Auth0'da mühendisim .

Bu önemli bir noktaya bağlıdır ... karar vermeniz gerekir:

  1. kendi kimlik sağlayıcınızı ve yetkilendirme sunucunuzu oluşturmak ve sürdürmek için doğrudan önemli miktarda zaman harcamak (ve dolaylı olarak para harcamak)
  2. veya doğrudan para harcamayı ve Auth0 gibi bir üçüncü taraf kimlik doğrulama sağlayıcısını kullanmayı tercih edersiniz.

Her iki seçenek de fonksiyonel gereksinimleriniz açısından mükemmel bir şekilde uygulanabilir. Özel geliştirmeyle, desteklemeye karar verdiğiniz işlevsellik üzerinde tam denetime sahip olursunuz, böylece Auth0'ın listelediğiniz gereksinimlere nasıl yanıt verebileceğine dair cevabın bir kısmını ele alacağım .

Bununla birlikte, kararınız ne olursa olsun, kimlik doğrulaması için OAuth2 yerine OpenID Connect'e odaklanmalısınız. Eğer ikisinde de ayrı web uygulamalarına bölmekle kalmayıp, karışımda API'leri de kullanmayı planlıyorsanız, ikincisi daha uygulanabilir olacaktır.


Mevcut kullanıcıları Auth0 tabanlı bir sisteme nasıl taşıyabilirim?

Veritabanınızı kullanmaya devam etmeye karar verebilir ve kullanmanız gerekebilecek kimlik doğrulama ile ilgili protokollere tüm uyumluluğu sağlamak için Auth0'a güvenebilir veya kullanıcılarınızı Auth0 tarafından yönetilen veritabanlarına taşıyabilir ve şifreleri nasıl sakladığınız ve doğruladığınız konusunda endişelenmeyi bırakabilirsiniz.

Veritabanınızı kullanmaya devam etmeyi tercih ediyorsanız, bkz. Özel Veritabanı Kullanarak Kullanıcı Adını ve Parolayı Kullanarak Kimlik Doğrulama

Uygulamalar genellikle kimlik doğrulama için kullanıcı veritabanlarına dayanır. Auth0, bu depolara kolayca bağlanmanıza ve bunları kullanıcı kimlik bilgilerini korurken ve birçok ek özellik sunarken kimlik sağlayıcısı olarak kullanmanızı sağlar.

(Belgeler örnek olarak MySQL'e atıfta bulunur, diğer veritabanı motorları desteklenir)

Öte yandan, Kullanıcıları Auth0'a Geçirme bölümünde açıklanan taşıma işleminden yararlanarak kullanıcı kimlik bilgilerini Auth0 veritabanlarına sorunsuz bir şekilde taşıyabilirsiniz.

Auth0, kullanıcıların özel bir veritabanı bağlantısından otomatik olarak Auth0'a geçişini destekler. Bu özellik, her biri oturum açtıkça kullanıcılarınızı Auth0 veritabanına birer birer ekler ve kullanıcılarınızdan şifrelerini aynı anda sıfırlamalarını istemekten kaçınır.

Ayrıca, hepsinin bir kerede şifre karma algoritmamızı kullanmaya başlamasını tercih ederseniz, Auth0'da tüm kullanıcılarınızı Yönetim API'sı aracılığıyla oluşturabilirsiniz. Bunun, kullanıcılardan şifrelerini sıfırlamalarını istemenin yan etkisi vardır.

Özel iki adımlı kimlik doğrulamayı (doğrulama soruları) kullanmaya nasıl devam edersiniz?

Auth0 tarafından sağlanan kimlik doğrulama boru hattı kurallar kullanılarak tamamen özelleştirilebilir . Bu, protokolle ilgili herhangi bir şey uygulamak zorunda olmasanız bile, uygulamanızda kimlik doğrulamanın nasıl gerçekleştiğine ilişkin küçük ayrıntılara ince ayar yapabileceğiniz anlamına gelir.

Bu, mevcut doğrulama sorularınızı, kullanıcının Auth0 tarafından doğrulanmış bir başlangıç ​​şifresi sağladığı ve daha sonra onlardan özel bir kuraldan daha fazla bilgi isteyebileceğiniz iki adımlı bir kimlik doğrulama işlemi yapmanın bir yolu olarak kullanmaya devam etme olasılığını içerir. (kurallar sadece Javascript olduğundan olasılıklar sınırsızdır)

Bununla birlikte, doğrulama sorularını bırakmaya ve bunun yerine kimlik doğrulama işleminin güvenliğini artırmanın bir yolu olarak Auth0 Guardian'a gitmeye karar verebilirsiniz .

Kimlik doğrulama arayüzünün görünümü ve hissi nasıl özelleştirilir?

Auth0 ile varsayılan giriş sayfalarından veya Kilit gibi kimlik doğrulama widget'larından yararlanarak hiçbir zaman temiz bir kimlik doğrulama arayüzüne sahip olabilirsiniz . Tüm bunlar bir dereceye kadar kişiselleştirmeyi destekler ve her zaman kendi kullanıcı arayüzünüzü kendiniz yapmaya karar verebilir ve bunun yerine kullanıcı arayüzünde herhangi bir kısıtlama getirmeyen daha düşük seviyeli Auth0 kütüphanelerinden ( Auth0.js ) yararlanabilirsiniz.

Özelleştirme hakkında daha fazla bilgi için:

Açık onay sayfaları nasıl önlenir?

Auth0'ı hem kimlik doğrulama amacıyla bir kimlik sağlayıcı hem de API'larınız için bir OAuth2 yetkilendirme sunucusu (şu anda yalnızca ABD bölgesinde kullanılabilir) olarak kullanabilirsiniz.

Bir kimlik sağlayıcısı olarak onay sayfaları hakkında endişelenmenize gerek yoktur, kullanıcı kimlik doğrulamaları Auth0 tarafından yönetilen kimlik bilgileriyle kimlik doğrulaması yapar ve ardından uygulamanıza yeniden yönlendirilir - hepsi bu kadar.

Rıza etkinleştirildiğinde OAuth2'de hizmet senaryosunda yol haritası, belirli uygulamalar için rıza sayfalarının atlanmasına izin verir.


Son olarak, oraya ulaştığınız çok ilginç ve zorlu bir proje gibi görünüyor, son kararınızdan bağımsız olarak iyi şanslar.

Eski bir uygulamanın kimlik doğrulama sistemini yeniden uygulamak zorunda kaldığımda, önceki bir işte benzer bir şeyden geçtim. Kendi kimlik sağlayıcımızı ve yetkilendirme sunucumuzu hayata geçirdik ve dürüst olmak gerekirse, gerçekten önemli bir şeyi unutmuş olabileceğimize inanıyorum.

Bence bu kendi güvenliğinizi yuvarlamakla ilgili en büyük sorun, son teslim tarihlerinin kısayollar oluşturduğu ve güvenliğin kısayol yapmak için gerçekten iyi bir alan olmadığı durumlar olacak.

Başka sorularınız varsa yardımcı olabileceğimi düşünüyorsanız bana bildirin.


Tüm detaylar için teşekkürler. Auth0'a baktığımı hatırlıyorum, ama söyleyebileceğim kadarıyla Auth0 sadece bulut; bu doğru mu? Güvenlik ve gizlilik nedeniyle, yalnızca kendi veri merkezimde / kişisel bulutumda barındırabileceğim çözümlere bakmakla sınırlıyım. Auth0 bu tür bir seçenek sunuyor mu?
Eric

Evet, Auth0 dağıtım / barındırma açısından çok esnektir. Herkese açık olmayan bulut çözümü şu anda Auth0 Uygulaması olarak biliniyor ve bunu Auth0'ın bulutunun, bulutunuzun veya kendi veri merkezinizin özel bir alanına dağıtabilirsiniz . Kontrol Cihazı Daha fazla bilgi için dokümanlar. Daha ayrıntılı bilgiye ihtiyacınız varsa bana bildirin, size doğrudan yardım etmeye çalışabilir veya sizi doğru kişilere yönlendirebilirim.
João Angelo
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.