網站的無密碼登入

阮一峰發表於2012-10-03

大部分網站,都要求使用者登入。

常見的做法,是讓使用者註冊一個賬戶。

網站的無密碼登入

這種做法並不讓人滿意。

對於使用者來說,每個網站必須記住一個密碼,非常麻煩;對於開發者來說,必須承擔保護密碼的責任,一旦密碼洩漏,對網站的業務和信譽都是巨大打擊

所以,很早以前,人們就開始設想"無密碼登入"(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的場合,比如在朋友家中上網。因此,使用它的網站,還必須部署備用的登入方式。

總的來說,我覺得這是一個簡單易行的好方法,以後做網站的時候,打算嘗試一下。

想聽聽大家的意見,你覺得這種方法可行嗎?

(完)

相關文章