大部分網站，都要求使用者登入。
常見的做法，是讓使用者註冊一個賬戶。
這種做法並不讓人滿意。
對於使用者來說，每個網站必須記住一個密碼，非常麻煩；對於開發者來說，必須承擔保護密碼的責任，一旦密碼洩漏，對網站的業務和信譽都是巨大打擊。
所以，很早以前，人們就開始設想"無密碼登入"（password-less login）。這對使用者和網站，都將是極大的減負。
本文先回顧"無密碼登入"的幾種常見做法，然後探討一種最簡單的實現。
一、OpenID
OpenID是最早提出的一種無密碼登入。
它的設想是這樣的：網際網路上每一個網址（URL），都指向一個獨一無二的網頁，這說明網址具有唯一性。因此，可以用網址來標識使用者。
所以，使用OpenID的網站，不要求使用者輸入"使用者名稱"，而要求使用者輸入一個代表其身份的網址。然後，向該網址進行求證，如果得到證實，就允許使用者登入，從而實現"無密碼登入"。
OpenID有兩個很大的缺點：一是需要伺服器端支援，二是使用網址表示身份，違背直覺，普通使用者難以理解。因此，始終無法得到推廣。
二、第三方賬戶
OpenID的實質，是讓第三方網站認證使用者身份。那麼很顯然，這等同於使用者在第三方網站登入。
因此，可以直接告訴使用者，使用第三方帳號登入（前提是對方支援OpenID）。
這樣做的優點是比較直觀，使用者容易接受；缺點是自身的業務，從此多多少少要依賴第三方網站。比如，現在很多網站使用Facebook帳號登入，一旦Facebook出現故障，這些網站都會受到影響。
三、Persona
去年，Mozilla提出了Persona方案，號稱是無密碼登入的終極解決方案。
它與OpenID異曲同工。後者用網址標識使用者，它用Email標識使用者。使用者鍵入Email地址以後，網站向Email伺服器請求認證。
雖然這種方案還處在推廣期，效果有待觀察。但是，我目前不太看好它。一則，它的技術要求和流程，比OpenID更復雜，無法用一句話講清楚；二則，它要求伺服器端支援，很難想象世界上大部分Email伺服器都會部署Persona程式碼。
四、OAuth
OAuth協議其實與"第三方帳戶"是一回事。
"第三方賬戶"是第三方網站提供使用者身份認證，屬於"認證"服務（authentication）；OAuth則是更進一步，第三方網站允許你直接操作它的使用者資料，屬於"授權"服務（authorization）。
因為涉及到使用者資料的改變，所以OAuth認證比Openid認證要求更嚴格。通常，只有針對某個第三方網站的外部服務，才需要用到OAuth；如果只是單純地區分使用者身份，其實沒必要用它。
五、Email一次性登入
上面四種登入方法，是目前主流的"無密碼登入"。下面，我想介紹一種最簡單的實現，它是美國程式設計師Ben Brown在今年7月份提出來的。
他的做法很簡單。使用者登入的時候，只顯示一個Email地址輸入框。
使用者輸入Email地址以後，網站就向該地址發出一封郵件，裡面包含了一個登入連結。使用者點選這個連結，就證明他/她確實是這個郵箱的主人，身份有效，從而實現登入。
登入連結只在一段時間內有效，但是可以透過cookie，讓使用者長時間處在登入狀態。如果cookie失效，則重新向使用者郵箱發出另一個登入連結即可。
由於整個認證過程，都透過電子郵件完成，徹底實現"無密碼登入"，而且操作流程很自然，易於理解。更重要的是，它使用現有的Email協議，不需要伺服器端部署新的程式碼，具有最好的相容性。
主要缺點是，它需要使用者額外檢視一次郵箱，稍顯麻煩；它也不適合那種使用者無法開啟Email的場合，比如在朋友家中上網。因此，使用它的網站，還必須部署備用的登入方式。
總的來說，我覺得這是一個簡單易行的好方法，以後做網站的時候，打算嘗試一下。
想聽聽大家的意見，你覺得這種方法可行嗎？
（完）