Kimlik doğrulama için 3. taraf (örneğin Google, Facebook, Twitter) kullanmak için RESTful bir web hizmeti nasıl kurmalıyım?


25

İşim için, sahip olduğumuz birkaç web sitesini yönlendirmek için kullandığımız güzel bir RESTful web servisimiz var. Temel olarak web hizmeti, destek biletleri oluşturmanıza ve bunlarla çalışmanıza izin verir ve web sitesi ön uçtan sorumludur. Herhangi bir web servis talebi, kullanıcıyı ve her arama için şifresini doğrulamak için kullandığımız bir auth başlığı kullanır.

Bu yıl giriş seçeneklerimizi genişletmek istiyoruz, böylece web sitesindeki kullanıcılar Google, Twitter ve Facebook üzerinden giriş yapabilir (muhtemelen diğerleri). Bununla birlikte, bunun nasıl yapılacağına karar vermekte zorlanıyorum, böylece web hizmeti, kullanıcıların kendilerinin kim olduklarını garanti etmek için 3. taraf kimlik doğrulama sağlayıcılarını kullanabilir. Bunun nasıl yapılacağı konusunda en iyi uygulamalar var mı?

Şu anda, web sitesinin kullanıcıların kendilerinin kimliklerini doğrulamasını sağlamayı düşünüyoruz ve ardından mevcut oturumlarını web hizmeti arka ucuyla kaydeden yeni bir setSessionId çağrısı kullanıyoruz. Web servisine yapılan her ilave istek, o oturum kimliği boyunca geçer ve onu doğrular. Bunlar iyi gözüküyor, ama kafamın arkasında bunu düşünemediğime dair bir his var ve tüm forumumu okudum ve açık sözlü özellikleri okuyup okumak beni daha fazla karıştırıyor. Bununla nasıl başa çıkılacağına dair ipucu?


önerdiğin şeyde gerçekten yanlış bir şey yok. openid entegrasyon örnek koduna bakmayı gerçek oauth ve openid özelliklerine göre daha kolay buluyorum ...
uzay

Hangi dili / platformu kullanıyorsunuz? Size büyük ölçüde yardımcı olacak çerçeveler olduğu için tekerleği yeniden icat etmeniz gerekmez. :)
RobM

@Rob Web hizmeti Salesforce.com'da barındırılmaktadır, ancak bu yazı itibariyle Node.js. olan bir proxy üzerinden erişilmektedir. Genel sorunun tüm platformlara uygulanacağını düşündüğünü söyledi. Ve evet, tekerleği yeniden icat etmek yerine bir çerçeve kullanmayı umuyorum, hangi tekerleğin kullanılacağından emin değilim.
Ralph Callaway

@Ralph Yep, genel soru platformdan bağımsızdır, ancak platform genel olarak çerçeve seçeneklerinizi biraz daraltacağından pratik sonuçları vardır. Yani, node.js kullanarak salesforce tarafından barındırılan bir web hizmeti ve veri deposuna özel bir ön uç uygulamanız mı var? Kullanıcı / kimlik bilgilerini arka uçta mı, yoksa sadece ön uçtaki işlemlerde kimlik doğrulaması ve yetkilendirmeye mi ihtiyacınız var?
RobM

@RobM evet, kullanıcı bilgilerini arka uçta, yani e-posta, ad, soyad ve ayrıca kimliği doğrulandıktan sonra web servis tüketicilerinden gelecek aramaları doğrulamak için ne gerekiyorsa depolamak isteyeceğiz.
Ralph Callaway

Yanıtlar:


14

İki hedef var gibi gözüküyor:

  1. Son kullanıcıların mevcut sosyal hesaplarıyla kimlik doğrulaması yapması kolay
  2. Web servisinizi kullanan geliştiriciler için kolay

İnsanları sitenizde kaynak kullanmaya yetkilendirmek, OAuth2'yi istemci kitaplıklarının popülerliği ve kullanılabilirliği nedeniyle tercih edilen bir mekanizma yapar.

1. Son kullanıcıların mevcut sosyal hesaplarıyla kimlik doğrulaması yapması kolay

Son kullanıcı, API'nizi kullanan ve giriş yapmayı seçen bir siteyi ziyaret eder. OAuth giriş sayfanıza gönderilir. Giriş sayfanız, sitenizde yönetilen hesaplar için normal bir kullanıcı adı ve şifre istemi ve Facebook gibi bir site üzerinden giriş yapmak için tıklayabilecekleri bir sosyal kimlik doğrulama düğmesi gösterir. Kullanıcı Facebook'u seçtiğinde, seçimi onaylamak için Facebook'a yönlendirirsin (facebook auth akışını başlat). Son kullanıcı Facebook'ta giriş yaptığında, sitenize geri yönlendirilir.

Kullanıcı sitenize tekrar Facebook'tan yönlendirildiğinde, bu kullanıcının bilgilerini veritabanınızdaki bir kullanıcı kaydına kaydeder ve ardından bu kullanıcı için yeni bir oturum oluşturur. Son kullanıcıyı hemen oauth access_token ile orijinal aşağı akış sitesine yönlendirerek orijinal oauth akışını tamamlarsınız.

2. Web servisinizi kullanan geliştiriciler için kolay

Yetkilendirme sağlayıcısıysanız, geliştiricilere bağımlılık yapması için basit bir arabirim oluşturmalısınız, her seferinde oauth'u kusursuz bir şekilde uygulayamayan yeni bir yukarı akış kimlik doğrulaması sağlayıcısı eklediğinizde bunlarda değişiklik olmaz. Bu nedenle, bir OAuth2 sağlayıcı sitesi uygulamanız gerektiğine ve bu sitenin sosyal kimlik doğrulama sitelerinin bir tüketicisi olması gerektiğine inanıyorum.

Güzel dinlenme API'nizi kullanan geliştiriciye, oturum yakalama yayını (örneğin) hakkında bir ipucu vermeyi seçmediğiniz sürece Facebook etkileşiminin farkında olmayacaklar.

TL; DR

OAuth2'yi uygulayarak ve sosyal kimlik doğrulama karmaşıklıklarını gizleyerek API'lerinizi tüketiciler gibi yapın. Aşağı akış siteleriniz için oauth akışı sırasında, facebook ile ek bir oauth akışı tetikleyebilirsiniz.

Resim çünkü resim == kelime * 1000:

görüntü tanımını buraya girin

Buna oauth2-piggy-back diyebilir miyiz?

Adım adım akış

  1. API'nızı kullanan son kullanıcı ziyaret sitesi
  2. Son kullanıcı yetki vermek veya kaydolmak için sitenize gönderilir (oauth2)
  3. Son kullanıcı sosyal kimlik doğrulamasını seçer, facebook giriş düğmesini tıklar
  4. Siteniz bir çerez belirler veya statekullanıcının nereden geldiğini bilmek için facebooktaki listeyi ayarlar
  5. Son kullanıcı Facebook'a yönlendirildi ve facebook sitesinde bağlantıyı kabul etti
  6. Facebook kullanıcısı işlemini tamamlamak için son kullanıcı sitenize yönlendirildi
  7. Veritabanında kullanıcıyı arar veya yaratırsınız
  8. Sunucunuzda yeni bir oturum oluştur
  9. Oturumu token'ınızla kullanıcıyı orijinal sitelerine geri yönlendirirsiniz

5

Genişletilebilir nasıl yapılır

Öncelikle tüm bu api'lerin giriş yapmak için aynı mekanizmayı kullandığını fark etmelisiniz. Bu, genel bir OAuth kütüphanesinden başlayarak kaldıraç kullanmanız gerekir. Kimlik doğrulama için kendi kütüphanelerini kullanmayın, bunlar diğer sağlayıcılar için kullanılamaz. Eğer OAuth2'nin çözümünü kaparsanız, daha fazla sağlayıcı eklemek oldukça kolaydır.

Ne yazık ki bunlardan ikisine ihtiyacınız var, çünkü twitter hala OAuth2 bandagonuna atlamadı.

OAuth kimlik doğrulaması yapan taraf için bir arayüz oluşturmanızı ister. Belirteçler sunucuya sunucuya aktarılacaktır. Tüm iletişimi yönetebilecek bir giriş noktası oluşturun.

Belirteç, hesabınızdan ayrı bir tabloda depolanmalıdır, bunun nedeni, birden çok belirteç ve birden çok bağlantılı profil olabilir. Bazı servisler size iki belirteç verir, bunlardan biri bir yenileme belirtecidir.

Artık ihtiyacınız olan diğer işlevselliği içeren bir arayüz tasarlıyorsunuz. Şahsen bunun için ayrı bir REST servisi kurardım. Bu şekilde, kimlik doğrulamayı kolayca başka yerlere uzatabilirsiniz.
Bazı servisler iletişim kurmak için JSON'u, diğerleri ise XML'i kullanır. Ön kullanıcı için hepsini birleştirmeniz gerekir. Bu oldukça acı verici bir süreçtir, ancak burada bazı ortak zeminler elde etmek mümkündür.

Buradaki diğer bir problem, tüm servislerin aynı işlevselliği sağlaması değildir. Bu, hizmetlerinizin belirttiğiniz gibi tam API'yi sağlayamayacağı anlamına gelebilir. Burada uygulamanın zarafetle düşürülmesine izin veren bir stratejiniz olması gerekir.

Tüm bunlar kolayca yeni 3. parti sağlayıcılar ekleyebilmenizi sağlayacaktır.

Token problemleri

Belirteçler zamanla sınırlıdır, bu nedenle belirtecin hala kullanılabilir olup olmadığını kontrol edebilecek birkaç cron işine ihtiyacınız vardır, aksi takdirde silmeniz gerekir. Bu mekanizma ile bir jetonu da yenileyebilirsiniz.

Bazen, bir kullanıcının belirteci geri çektiği olur. Bunun için hazır olun.

Veri depolama

Bu tasarıma sahipseniz, ihtiyacınız olan verileri düşünmeniz gerekir. Bu kısmen yeni oluşturduğunuz arabirimden gelir. Bunun için bazı tablolar tasarlayın ve verinin gerçekte alınabilir olup olmadığına bakın. Bazı servisler çok fazla veri toplamanıza izin vermez. Ayrıca, ihtiyaç duyduğunuz verinin gizlilik mesajlarının ne kadar katı olduğunu da hesaba katmalısınız. Bu yüzden ihtiyaçlarınızda mütevazı olun, aksi takdirde kullanıcılar bunu kullanmaz.

Ek doğrulama için, profilleri kullanıcılarınıza ayrı, ancak bağlantılı bir tabloda saklayabilirsiniz. Bu size biri hakkında daha fazla bilgi sağlayacaktır.

Ayrıca, yerel yasalarınızı da kontrol edin, bazı veriler için ek önlemlere ihtiyacınız var.

Son şey Kendi hizmetlerinizde hesap oluşturmadığınız hatayı yapmayın. Kullanıcı facebook'tan men edilirse, hizmetinize giriş yapamaz. Bu oluşturmak istemediğiniz bir durumdur. Bu genellikle göz ardı edilir.


1

Kesin olarak çözdüğünüz gibi bir çözüme katılıyorum: müşteriye dönük web sitenize 3. taraf kimlik doğrulamasını uygulamak ve bu üçüncü taraf kimlik doğrulama belirteçlerini web sitesi kullanıcı hesaplarınızla ilişkilendirmek ve son olarak setSessionID çağrınızı tetiklemek oturum aç.

Web sitenizin mimarisine bağlı olarak, EveryAuth veya Passport gibi bir kütüphaneyi kullanarak çok yardımcı olabilirsiniz.


1

İki sentim: Daha önce hiç böyle bir şey yapmadım, FB, Twitter veya Google giriş mekanizmalarının nasıl çalıştığını da bilmiyorum, ancak sorunuzu okuduktan hemen kafamda birkaç sorun ortaya çıktı:

  • Birden çok giriş: Bir gün Facebook hesabımla ve bir sonraki Google hesabımla giriş yaparsam ne olur? Veya aynı anda mı? Bu iki hesabı benzersiz, ayrı hesaplar olarak mı kabul ediyorsunuz yoksa ikisini ilişkilendirme ve biletlerime iki şekilde de erişmeme izin verecek bir yönteminiz olmalı mı?
  • Dış tanımlayıcılara güvenme: Facebook veya Twitter hesap tanımlayıcılarının bakışlarını değiştirmeye karar verdiğinde ne olur? Örneklemek gerekirse, BazLogin {4382-af56} kodunu kullanan benzersiz bir hesabı temsil ediyorsa, ancak bundan sonra 8'in yeterli olmadığı için hesaplarda 12 basamak olacağına karar verirse, {0000-4382'den {1234-4382-af56} -af56}?

Dış hesaplarla yalnızca bir oturum kimliği değil, bir iç hesap ilişkilendirmeyi seçerek bu iki sorunu çözebiliriz. O zaman, harici bir giriş , bir iç hesap oluşturmaya açılan bir kapı olabilir . Birden fazla giriş yöntemiyle kimlik doğrulaması yapmam halinde, bana zaten oturum açtığımı söyleyebilirsiniz. Harici bir kimlik doğrulama sağlayıcısı, güvendiğimiz bir şeyi değiştirirse, kullanıcıdan kendi iç hesaplarının adını ve şifresini girmesini ve bir hesap oluşturmasını isteyebilir. gelecekteki girişler için yeni dernek.

Aklınızdaki sorunları çözdüğümden emin değilim, ancak somut kaygılardan hiç bahsetmediniz. Umarım cevabım her iki şekilde de yardımcı olmuştur.

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.