無密碼身份驗證：安全、簡單且部署快速Passwordless authentication: Secure, simple, and fast to deploy

然而，大多數網站仍在使用最早期的 web 身份驗證方式：使用者名與密碼。

passwordless 入門非常簡單。兩個小時以内，你就能學會部署全面且安全的身份驗證解決方案：

在傳送令牌給使用者時，電子郵件通常是最好的選擇（不過，短消息也可以）。你可以任意選擇郵件架構，比如：

首先，請求上文用到的所有子產品，将它們放在用于初始化 express 的同一個檔案中：

最後的一個預備步驟是告知 passwordless 你選擇了哪一種存儲接口，并将之初始化：

函數 <code>passwordless.adddelivery(deliver)</code> 會添加新的傳送機制。每次需要傳送令牌時，就會調用<code>deliver</code>。預設情況下，你選擇的機制應該按照以下格式為使用者提供連結：

<code>deliver</code> 在調用時，需要全部的細節資訊。是以，令牌的傳遞（在本例中，使用的是 emailjs）如下所示，相當簡單：

函數 <code>accepttoken()</code> 會截獲任何外來的令牌，驗證使用者身份，再将他們重定向至正确的頁面。盡管 <code>successredirect</code> 選項不是嚴格要求的，但筆者強烈建議你使用此選項，進而避免合法令牌通過網站向外的 http 連結的 header 來源洩露出去。

你至少需要兩個 urls，進而：

展示用于擷取使用者郵箱位址的頁面

擷取表格細節（通過 post 方法）

此處有何存在某種問題或陰謀？<code>passwordless.requesttoken(getuserid)</code> 的任務有二：第一、確定郵箱位址真實存在。第二、将該位址轉變為獨一無二的使用者 id，通過郵件一并發送，并在之後用于驗證使用者身份。通常，你都有一套存儲使用者細節資訊的模型，你可以按照上例的說明，進行簡單的設定。

在一些情況下（例如，由兩個使用者編輯過的部落格），你可以跳過使用者模型，将他們有效的郵箱位址與其各自的 id 相聯系：

本例隻需要一個簡單的 html 頁面，用以擷取使用者的郵箱位址。預設情況下，passwordless 會查找 <code>user</code> 輸入欄中的内容：

passwordless 提供了能確定隻有驗證使用者才能看到指定頁面的中間件：

預設情況下，passwordless 允許通過請求對象 <code>req.user</code> 擷取使用者 id。想要展示或重用此 id，或從資料庫中得到更多細節資訊，你可以這麼實作：

或者，更一般化地，你可以添加另一個中間件，從模型中抽取出某個使用者的全部記錄，再将其配置設定給網站中的任意路徑：

如前所示，所有的身份驗證系統都有其優缺點。你應該按照自己的需求進行合理的選擇。基于令牌的驗證方式，與絕大多數解決方法（包括經典的使用者名/密碼方法）一樣，都存在一個風險：如果使用者的郵箱賬戶被盜用，并且/或者 smtp 伺服器與使用者的連接配接被入侵，使用者在網站的賬戶就會随之遭到盜用。預設情況下，有兩種辦法可以減弱該風險（但不是完全避免）：短時間有效的令牌以及令牌在使用後自動失效。

對大多數網站而言，基于令牌的身份驗證方法代表着走向安全的進步：使用者無需再想新的密碼（這些密碼往往非常簡單），也不存在使用者重用密碼的風險。對于身為開發者的我們，passwordless 提供了唯一一種（且相當簡單的）身份驗證解決方案，該方案易于了解，是以容易保護。此外，我們也無需再處理使用者的密碼了。

另一個值得讨論的點是可用性。我們應該同時考慮兩種情況：使用者在網站的首次使用以及後續的登入。對首次使用者而言，基于令牌的身份驗證非常直覺：與經典的登入機制一樣，他們還是不得不驗證郵箱位址。但是，在最佳案例中，除此之外就不需要其他細節資訊了。不需要再煞費苦心地想一個符合所有限制條件的密碼，也不需要刻意記住密碼。如果使用者再次登入，其體驗與特定的使用者案例有關。大多數網站的會話有效期都很長，因而不需要再次登入。或者，使用者通路該網站的頻率其實非常低，以緻于他們想不起來自己是否已經擁有賬戶，或者忘記了賬戶密碼。在這種情況下，passwordless 在可用性方面的優勢相當明顯。同樣地，這需要經曆不多的幾個步驟，解釋起來也非常簡單。然而，那些使用者通路頻繁的網站，以及/或那些要求使用者一周内手動登入幾次的網站（比如 amazon），經典的身份驗證（或更保險地：雙重驗證）或許更加适合。因為使用者很可能會真的記住他們的密碼，并且意識到好密碼的重要性。