|
|
|
大部分網站，都要求用戶登錄。
常見的做法，是讓用戶注冊一個賬戶。
這種做法并不讓人滿意。
對于用戶來說，每個網站必須記住一個密碼，非常麻煩；對于開發者來說，必須承擔保護密碼的責任，一旦密碼泄漏，對網站的業務和信譽都是巨大打擊。
所以，很早以前，人們就開始設想"無密碼登錄"（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的場合，比如在朋友家中上網。因此，使用它的網站，還必須部署備用的登錄方式。
總的來說，我覺得這是一個簡單易行的好方法，以后做網站的時候，打算嘗試一下。
想聽聽大家的意見，你覺得這種方法可行嗎？
文：阮一峰博客
|
|
發表留言請先登錄！
|