Burada sorulan birçok soru var ve sorular Node ve passport.js bağlamında sorulsa bile, gerçek sorular iş akışı ile ilgili olarak belirli bir teknoloji ile nasıl yapılacağından daha fazla.
Ek güvenlik için biraz değiştirilmiş @Keith örnek kurulumunu kullanalım:
- Adresindeki web sunucusu
https://example.comtek bir sayfa Javascript istemci uygulaması sunuyor
- Adresindeki RESTful web hizmeti,
https://example.com/apizengin istemci uygulamasına sunucu desteği sağlar
- Sunucu Düğüm ve passport.js'de uygulandı.
- Sunucu "kullanıcılar" tablosu ile bir veritabanı (herhangi bir tür) vardır.
- Kullanıcı adı / şifre ve Facebook Connect kimlik doğrulama seçenekleri olarak sunulur
- Zengin istemci, REST isteklerini
https://example.com/api
- Adresindeki web hizmetini kullanan,
https://example.com/apiancak adresindeki web sunucusunu bilmeyen başka istemciler (örneğin telefon uygulamaları) olabilir https://example.com.
Güvenli HTTP kullandığımı unutmayın. Bence parolalar ve yetkilendirme simgeleri gibi hassas bilgiler istemci ve sunucu arasında geçtiği için, açık olan tüm hizmetler için bir zorunluluktur.
Kullanıcı adı / şifre doğrulaması
İlk önce eski kimlik doğrulamanın nasıl çalıştığına bakalım.
- Kullanıcı şunlara bağlanır:
https://example.com
- Sunucu, ilk sayfayı oluşturan zengin bir Javascript uygulaması sunar. Somehwere sayfada bir giriş formu var.
- Bu tek sayfa uygulamasının bölümlerinin çoğunda kullanıcının oturum açmaması nedeniyle veriler bulunmuyor. Tüm bu bölümlerde "oturum açma" etkinliğinde bir olay dinleyicisi var. Tüm bunlar istemci tarafı şeyler, sunucu bu olayları bilmiyor.
- Kullanıcı oturum açma adı ve parolasını girer ve kullanıcı adı ve parolasını istemci tarafı değişkenlerine kaydetmek için bir Javascript işleyicisini tetikleyen gönder düğmesine basar. Sonra bu işleyici "giriş" olayını tetikler. Yine, bu tüm istemci tarafı eylem, kimlik bilgileri henüz sunucuya gönderilmedi .
- "Login" etkinliğinin dinleyicileri çağrılır. Artık bunların her birinin
https://example.com/api, sayfada oluşturulacak kullanıcıya özgü verileri elde etmek için RESTful API'sına bir veya daha fazla istek göndermesi gerekiyor . Web hizmetine gönderdikleri her istek, muhtemelen HTTP Temel kimlik doğrulaması biçiminde kullanıcı adını ve parolayı içerecektir , çünkü RESTful olan hizmetin bir istemden diğerine istemci durumunu korumasına izin verilmez. Web hizmeti güvenli HTTP'de olduğundan, aktarım sırasında parola güvenli bir şekilde şifrelenir.
- Adresindeki web hizmeti
https://example.com/api, her biri kimlik doğrulama bilgilerine sahip bir grup bireysel istek alır. Her istekte bulunan kullanıcı adı ve parola kullanıcı veritabanına göre kontrol edilir ve doğru bulunursa istenen işlev yürütülür ve veriler istemciye JSON biçiminde döndürülür. Kullanıcı adı ve parola eşleşmezse, istemciye 401 HTTP hata kodu biçiminde bir hata gönderilir.
- İstemcileri her istekte kullanıcı adı ve parola göndermeye zorlamak yerine, RESTful hizmetinizde kullanıcı adını ve parolayı alan ve benzersiz ve biraz sona eren bir tür şifreleme karma olan bir jetonla yanıt veren bir "get_access_token" işlevine sahip olabilirsiniz. tarih. Bu jetonlar her kullanıcıyla birlikte veritabanında saklanır. Sonra istemci sonraki isteklerde erişim belirteci gönderir. Erişim belirteci daha sonra kullanıcı adı ve parola yerine veritabanıyla doğrulanır.
- Telefon uygulamaları gibi tarayıcı olmayan istemci uygulamaları, yukarıdakiyle aynı şeyi yapar, kullanıcıdan web hizmetine her istekle kimlik bilgilerini girmesini (veya onlardan oluşturulan bir erişim belirtecini) göndermesini ister.
Bu örnekten önemli nokta, RESTful web hizmetlerinin her istekte kimlik doğrulaması gerektirmesidir .
Bu senaryoda ek bir güvenlik katmanı, kullanıcı kimlik doğrulamasına ek olarak istemci uygulaması yetkisi de ekler. Örneğin, web istemcisine sahipseniz, iOS ve Android uygulamalarının tümü web hizmetini kullanıyorsa, sunucunun, kimliği doğrulanmış kullanıcının kim olduğuna bakılmaksızın, belirli bir isteğin üç istemcisinden hangisinin olduğunu bilmesini isteyebilirsiniz. Bu, web hizmetinizin belirli işlevleri belirli istemcilerle kısıtlamasını sağlayabilir. Bunun için API anahtarlarını ve sırlarını kullanabilirsiniz, bu konuda bazı fikirler için bu cevaba bakın .
Facebook kimlik doğrulaması
Facebook üzerinden giriş yapmanın Facebook'un kendisi için üçüncü bir tarafı olduğu için yukarıdaki iş akışı Facebook bağlantısı için çalışmaz. Giriş prosedürü, kullanıcının kimlik bilgilerinin kontrolümüz dışında girildiği Facebook web sitesine yönlendirilmesini gerektirir.
Öyleyse işlerin nasıl değiştiğini görelim:
- Kullanıcı şunlara bağlanır:
https://example.com
- Sunucu, ilk sayfayı oluşturan zengin bir Javascript uygulaması sunar. Sayfada "Facebook ile Giriş Yap" butonunu içeren bir giriş formu bulunmaktadır.
- Kullanıcı yalnızca (örneğin) adresine yönlendiren bir bağlantı olan "Facebook ile Giriş Yap" düğmesini tıklar
https://example.com/auth/facebook.
https://example.com/auth/facebookRota passport.js tarafından işlenir (bakınız belgeler )- Kullanıcının gördüğü tek şey sayfanın değiştiği ve şimdi web uygulamamıza giriş yapması ve yetkilendirilmesi gereken Facebook tarafından barındırılan bir sayfada olması. Bu tamamen bizim kontrolümüz dışında.
- Facebook şimdi örneğin aşağıdaki passport.js kurulumu yapılandırılmış olduğu geri arama URL'ye geri yönlendirir böylece Facebook'a kullanıcı günlükleri ve bizim uygulamaya izin verir belgelerin olduğunu
https://example.com/auth/facebook/callback
https://example.com/auth/facebook/callbackGüzergahın passport.js işleyicisi , Facebook erişim belirteci alan geri arama işlevini ve kullanıcının e-posta adresi de dahil olmak üzere Facebook'tan bazı kullanıcı bilgilerini alır.- E-posta ile kullanıcıyı veritabanımızda bulabilir ve Facebook erişim kodunu onunla birlikte depolayabiliriz.
- Facebook geri çağrısında yaptığınız son şey, zengin istemci uygulamasına geri yönlendirmektir, ancak bu sefer kullanıcı adını ve erişim kodunu istemciye geçebilmemiz için istemciye iletmemiz gerekir. Bu birkaç yolla yapılabilir. Örneğin, Javascript değişkenleri sayfaya bir sunucu tarafı şablon motoru aracılığıyla eklenebilir veya bu bilgiyle bir çerez döndürülebilir. (başlangıçta önerdiğim gibi, bu verileri URL'ye geçirmeyle ilgili güvenlik sorunlarını işaret ettiği için @RyanKimber'e teşekkürler).
- Şimdi tek sayfa uygulamasını bir kez daha başlatıyoruz, ancak istemcinin kullanıcı adı ve erişim belirteci var.
- İstemci uygulaması hemen "login" olayını tetikleyebilir ve uygulamanın farklı bölümlerinin web servisinden ihtiyaç duydukları bilgileri talep etmesine izin verebilir.
- Gönderilen tüm istekler
https://example.com/api, kimlik doğrulama için Facebook erişim belirtecini veya uygulamanın REST API'sindeki bir "get_access_token" işlevi aracılığıyla oluşturulan Facebook erişim belirtecini içerir.
- Tarayıcı olmayan uygulamalar burada biraz daha zor, çünkü OAuth giriş yapmak için bir web tarayıcısı gerektiriyor. Bir telefondan veya masaüstü uygulamasından giriş yapmak için Facebook'a yönlendirmeyi yapmak için bir tarayıcı başlatmanız gerekecek ve daha da kötüsü, tarayıcının Facebook erişim kodunu bazı mekanizmalarla uygulamaya geri geçirmesi için bir yol gerekir.
Umarım bu soruların çoğuna cevap verir. Elbette Facebook'u Twitter, Google veya başka bir OAuth tabanlı kimlik doğrulama hizmetiyle değiştirebilirsiniz.
Birisinin bununla başa çıkmanın daha basit bir yolu olup olmadığını bilmek isterim.
passport-facebook. Bunu çalıştırdıktan sonra, bir sonraki adım Passport'un nasıl çalıştığını ve kimlik bilgilerini nasıl sakladığını anlamaya başlamaktır. Restify'e bağlamak ( bahsettiğiniz sürümün güncellenmiş bir sürümü için buraya bakın ) son adımlardan biri olacaktır (veya Express'te REST arayüzünü uygulayabilirsiniz).