選擇適合的Node.js授權認證策略

作者：chszs，轉載需註明。部落格主頁：http://blog.csdn.net/chszs

英文原文：https://stormpath.com/blog/choosing-nodejs-authentication-strategy/

Node.js正在興起！我從2010年就開始使用Node工作，那個時侯我看著它從一個很小的個人專案成長為一個全功能的、能夠讓現代開發者用於構建真實、重要的大型應用的主要工具。一個完整的解決方案生態系統如雨後春筍般湧現，既幫助了Node開發者，也促使生態系統自身快速演進。但隨著它的快速演進，要找到最適合你的解決方案就變得越來越難，因為來自谷歌搜尋或npm的噪聲太多（譯者注：Node.js的第三方庫太過龐大，以至於難以選擇最適合的）。
授權認證和使用者管理尤其是塊困難且變化多端的領域。但是，當你用Node建立實際的應用時，它卻是你所需的第一個元件。本指南的目的是向你展現用Node如何實現使用者管理和授權認證。

Node生態圈有哪些可用選擇?

目前Node生態圈在構建使用者管理有幾種不同的方法。大致上有：
1）Passport.js庫或Everyauth庫
PassportJS：http://passportjs.org/
Everyauth：https://github.com/bnoguchi/everyauth
2）使用自己的資料庫及雜湊演算法
3）採用“使用者管理即服務”的雲服務

Passport.js / Everyauth

PassportJS和Everyauth都是Node的授權認證中介軟體，兩者都利用了Connect中介軟體框架。這意味著如果你使用了Express、Restify或Sails等框架，你可以很容易地將其中任意一個認證中介軟體（或策略）直接整合到你的應用中。Everyauth只適合嵌入策略，然而PassportJS則可以選擇要使用的策略。開發者使用PassportJS通常採取的策略是Facebook和Google，但還包括來自本地的使用者名稱/密碼認證，到大量的OpenID、OAuth第三方認證，甚至PassportJS的Stormpath策略。
注：Stormpath是一個使用者管理API，它減少了開發時間，提供了即開即用的使用者管理基礎設施。Stormpath直觀的API和專家支援使得開發授權認證、管理、安全的使用者和角色變得很容易。

儘管 Everyauth 和 Passport 都建立在同一個中介軟體框架Connect之上，單他們各有自己的優缺點。Passport 更靈活、更模組化，而Everyauth則提供了額外的功能，支援路由和登入/註冊檢視。但是很多Node開發者選擇了Passport，因為它不使用承諾。  
由於 Passport 和 Everyauth 都是建立在 Connect 上的，兩者都能幫助你實現會話管理，包括：  
1）身份已認證的使用者的序列化
2）會話管理 
3）登出使用者  

此外，它們很適用於簡單的、簡易的使用者授權認證，但由於設計上的侷限，並不適用於複雜的使用者管理需求。你仍然需要設計、實現和維護你的使用者管理基礎設施的其它部分。
例如，如果你使用的是passport-local策略（此策略需要把授權認證所需的使用者名稱和密碼存入你自己的資料庫），Passport自身不處理使用者的註冊及賬戶的認證。你需要使用資料庫模組來進行身份鑑定、建立賬戶、跟蹤認證狀態、建立認證令牌、傳送郵件，以及驗證賬戶。這意味著開發者會需要考慮URL的安全性、移除過期的令牌，以及其它的安全約束（如資料庫中密碼的正確雜湊）。

使用自己的資料庫及雜湊演算法

DIY 的方法不依賴於任何中介軟體。選擇自己的技術棧，用資料庫來儲存使用者資訊（可能是 PostgreSQL 或 MongoDB），並使用雜湊演算法生成密碼雜湊（可能是bcrypt或scrypt)。在npm中搜尋bcrypt或scrypt會導致不少模組在質量上的變化，bcrypt或scrypt模組都有自己的依賴集。要特別注意的是，如果你使用Windows開發，我們推薦bcrypt的原生JS實現，見https://github.com/shaneGirish/bcrypt-nodejs。
選定技術棧後，你需要建立使用者管理和授權認證。從歷史上看，這種方式極其常見，但與其它方式相比，它冗長乏味、易於出錯、且需要更多的維護。
你需要增加/解決：
1）賬戶建立
• 建立使用者模式來保持使用者資料
• 建立賬戶及儲存使用bcrypt/scrypt雜湊並加鹽後的密碼
• 傳送帶有賬戶認證令牌的郵件
2）賬戶授權認證
• 驗證使用者身份（比較雜湊值）
3）賬戶管理
• 密碼復位的工作流（產生令牌/讓令牌失效）
• 基於角色的訪問/許可
4）用ID與第三方社交認證服務商的整合
5）系統安全
• 阻止未授權訪問資料庫
• 阻止未授權訪問作業系統
6）資料備份

授權認證和使用者管理的最大的挑戰是維護。以密碼雜湊為例，正確的方法是，你基於成本因素選擇的雜湊演算法，為防止暴力攻擊特意使雜湊演算法減慢（約300～700毫秒）。但是今天認為是正確的，在明天就可能是不安全的。如果你正在建立的應用程式即將上線，那麼你應該每年更換一次雜湊策略。
儘管Node社群反對這種方式，但這種方式也有一些好處。你可以完全控制自己的基礎設施。如果你的工具還沒有足夠好到可以交付給你的客戶、滿足複雜的需求，那麼你就該向身份認證和使用者管理投入人力物力。幸運的是，應用程式和開發者很少有這種需求，所以開源工具以及開放API服務可以幫助我們更快、更好的交付產品。

使用者管理即服務

隨著時間的推移，軟體已經從本地到雲端釋出，再到分散式API服務。與此同時，開發團隊也開始依賴開源軟體和開放API服務，甚至和自己的程式碼一樣重要。因此，把自己的使用者管理模組卸下來，使用REST API和開放SDK來實現新的使用者管理，完成應用程式的開發。Stormpath 支援這種方式。特別是Node社群，已經採取這種面向服務的模式，遠遠領先於其它語言的任何社群。
通常情況下，API驅動的服務圍繞使用者管理方面提供了更常規的功能，而且不僅是授權認證。服務供應商還提供了各種額外的功能，通常包括： 
1）帳戶的電子郵件驗證
2）密碼重置工作流程
3）基於角色的訪問/許可權
4）無模式的使用者配置檔案
5）雙重因素身份認證
6）應用程式間的單點登入
7）社交登入的整合（Facebook、谷歌等）
8）與Node的認證中介軟體如 Passport的整合 

除了這些純粹的功能，它還提供相當可靠的安全性和操作性。為開發者提供了所有基礎設施，擴容到吸收使用者的流量高峰以及處理使用者資料的安全問題。
使用一個API服務通常可以提供更多的便利性和更高的安全性，同時也降低開發和維護的成本。開發人員可以把更多的注意力打集中在自己應用程式的獨特部分。
不過有時使用者也需要權衡的使用API服務。當你引用一個第三方的依賴性服務到你的應用時，這個第三方服務需要具備高可用、高速、便攜性高、能提供傳輸過程中的高可靠性，並具有足夠的靈活性，以滿足你的使用者資料模型。
可用性和效能是至關重要的，因為對於一個關鍵系統，使用者認證和管理服務是不能離線或變慢的。在SDK快取並基於現代雲端計算基礎設施是不錯的開始，但重要的是，該服務即將面臨到最糟糕的情況——例如整個資料中心正在走下坡。因此你想要確保您可以收到任何的通知，則需要建立在使用者管理服務的頂部。
https://stormpath.com/resources/security-and-availability/
https://status.stormpath.com/

資料遷移也很關鍵——你能夠安全的把使用者資料來回遷移。與輕鬆寫一個指令碼把未加密的資料移到JSON上不同，移植密碼的難易程度嚴重依賴於任何已存在的資料的儲存方式。例如bcrypt設計的就很容易移植，因為它遵循模組加密格式MCF（Modular Crypt Format）。對很多系統和語言而言，通過檢視雜湊值本身來構造雜湊是可能的。如果你建立了一個原型，且沒有使用 Stormpath之類的服務，我們推薦以bcrypt之類的MCF雜湊開始——在將來升級時會比較容易。
應用程式和API服務之間的傳輸安全也是很重要的。額外的網路通訊需要安全化。例如Stormpath 僅支援 HTTPS，使用一個自定義的摘要認證演算法來確保，不會被回放和中間人攻擊。關於安全性你可以在這裡瞭解更多。https://stormpath.com/resources/security-and-availability/
授權認證服務使用的資料模型很廣泛。以Salesforce為例，它的資料模型與Stormpath資料模型有很大的不同。它是基於目錄的，因此更通用、更靈活。深入理解這些資料模型是很有價值的，尤其是多承租人應用或者SaaS。此外，API文件變化很大——你應該確保你在努力開始做事之前細緻地瞭解大綱。