Open ID 的登出:易用性與安全性問題

之前在 Twitter 和 Irvin 討論過,後來又在 xditeptt2 個人板上面也討論過 PIXNET 的 implement 方法,但我一直都沒有講清楚(阿表達能力薄弱呀orz)所以試著在這裡用長篇幅表達看看:

Open ID 對許多使用者來說,是首次能將「登入認證」和「登入狀態」兩者拆開的全新體驗。因為是認證機制,所以要在易用性上確保使用者能認知 Open ID 幫他做了什麼,且他自己要做什麼以免身分遭到冒用

定義一下,「登入認證」就是那組帳號密碼(或是指紋、掌紋、聲音辨識,隨便),「登入狀態」則是使用者是否已經登入的判斷,在網頁上面就是 cookie。

Open ID 的設計讓使用者看起來1可以共用「登入認證」(即,用同一個身份登入不同的網站),甚至看起來2是直接複製「登入狀態」(因為許多 Open ID sp 的作法是如果已經登入 rp 來要認證的話就直接發 token,不顯示確認畫面)。

因為沒有 single sign-off 能力,當使用者登出 sp 的時候,rp 的「登入狀態」不會因此更新。反過來登出 rp 的時候當然不能讓 rp 去登出 sp(想像你去逛一下抓火狐然後按登出結果連 GMail 都登出了…),只是就以上的情況與 UI 暗示,使用者真的知道登出 PIXNET 主站的時候 murmur.tw 不會跟著登出嗎?

如果不知道,這就是個安全性問題。使用者去 PIXNET 發完部落格文章然後去 murmur 碎碎念一下,結果只按了 PIXNET 的登出卻不知道要按 murmur 的登出… 更何況 murmur 的首頁上只用了一個「使用痞客邦 PIXNET 帳號登入」的按鈕就直接用 OpenID 交換認證。

在我和 xdite 反應這件事情之後,PIXNET 在 sp 端輸入帳號密碼的畫面加上了[同時也登入痞客邦 PIXNET]的勾勾。雖說這個勾勾能讓使用者正確意識到 murmur 和 PIXNET 兩者的「登入狀態」是獨立的,但是因為 PIXNET 做的 Open ID sp 在已認證的狀態下會跳過這個畫面,所以大部分的時候是白搭,使用者根本看不到。

重新整理一次:

Open ID:

  • 共用登入認證,sp 端登入後 rp 可以直接拿 token
  • 不共用登入狀態,要分別登出

但使用者看起來:

  • 因為登入不用重新輸入認證,所以登入狀態好像是共用的
  • 那在 sp 登出的時候 rp 好像會一起登出
  • 實際上不會,所以這造成了安全性問題

這樣的暗示問題在 PIXNET 會比其他網站嚴重,因為使用者明知 murmur 或是 belovely 就是 PIXNET 的網站,要意識到同一家公司的不同網站「登入狀態」竟然是獨立的這還滿難的。畢竟我們都被 Google 或是 Yahoo! 跳來跳去的登入畫面養壞胃口了。

倒是我想不透除了背後從資料庫每次查詢認證以外,Google 怎麼從 google.com 把 blogger.com 的認證拿掉的;不同 domain 的 cookie 不是沒辦法存取嗎?會不會搞半天其實這是唯一的解法…

OpenID Login 畫面的易用性

抓火狐的規格書有一項是這樣:不使用傳統的註冊、登入帳號系統,用 OpenID 讓使用者感受攜帶帳號與個人資料的自由,並讓使用者意識到提供這項好處的是「OpenID」這個技術。

這是一推出時的 OpenID 登入畫面:

舊登入畫面

看的出問題在哪嗎?我也看不出來,直到真的看到一個不知什麼是 OpenID 的人用過之後:

  • 這個 UI 雖然很詳盡的介紹 OpenID,但是充斥著專有名詞:「OpenID 網址」、「服務商」
  • 這樣就算了,但是使用者沒有看到任何熟悉的欄位,所以開始自行想像上面要填什麼(填了「自己想的 ID」、「想要的抓火狐網址」)
  • 然後失敗大約三次之後,終於開始認真讀畫面上的文字,去按 OpenID 服務商的下拉選單,找到熟悉的 Google(目前的統計是大約六成的人都用 Google OpenID)
  • 但是呢,看到自動填入的 Google OpenID endpoint 網址,以為最後面的「id」要改成自己的 GMail ID(結果又失敗了)

評價:顯然這個登入畫面是個測驗,需要失敗多次證明你夠愛 Firefox 才能進來一起宣傳

OpenID 有兩種形式,一種是該服務商的所有帳號都用一個固定的 endpoint 網址登入(像 Google、Yahoo),另一種是每個人都有個人網址。以下是 Yahoo 建議的登入畫面 (Google 也這樣建議,但我一時找不到):

OpenID sign-in suggested by Google and Yahoo

發現有詐了吧?顯然他們認為既然不需要使用者輸入個人網址,就根本不需要讓他們知道他們用的是 OpenID;還有,需要輸入 username 的 OpenID 就管它去死吧跟我的按鈕無關。這種按鈕其實也不少人用,最知名的 Google OpenID 利用者 zoho 就是這樣(用競爭者的帳號服務開拓客戶呀嘖嘖)。而其他舊式的 OpenID 登入頁面(像 SourceForge 的)則沒有辦法表達「這個 endpoint 網址不需要再修改網址輸入 username 」這件事情。

最後,經過了攏長的討論(中間還包括奇怪的設計像是準備兩個網址/登入 widget 一個可輸入一個 readonly),最後我們採用了現在這個設計:

Current OpenID dialog

這個設計直接解決了數個問題:

  • 開始的焦點依然是 OpenID 輸入框,不是什麼選擇登入方式的選單。直接打網址的使用者操作是完全相同的(私心認為很重要)。
  • 服務商選單變成 radio buttons,可以直接找到熟悉的標誌。
  • 不使用「服務商」這種詞彙來引導使用者點選(實際上他們也不懂這個詞所以也引導不了)
  • 最後,點選服務商時提供適當的回饋引導他輸入使用者名稱或是直接去點登入(請看下面)

這是使用者點選 Google 會出現的提示,上面會變成灰色且唯讀。

New OpenID Login dialog - Click Google

這是使用者點選需要輸入 username 時會出現的提示,一樣上面是灰色不能改但下面打字時會跟著變化。

New OpenID Login dialog - Click Google

就希望這樣的設計能夠達到原本規格的要求了。不過,OpenID 怎麼這麼不紅呀,大部分的使用者好像都不知道。加油,好嗎?

註:大部分的網站不會有規格說要讓使用者意識到 OpenID 啦,所以最後兩個畫面可以再修改成當使用者點選 Google 時,OpenID 網址方塊直接消失改成 [使用 Google 登入] 的按鈕。點選 WordPress.com 時也可以消失只顯示下面那個使用者名稱的輸入方塊。

再討論的 metaphysical 一點,問題就變成「我們有辦法讓使用者在不了解 OpenID 的情況下推廣 OpenID 嗎?」或是「對使用者推廣 OpenID 的概念和推廣使用 OpenID 有關嗎?」不過這就不是本文的範圍了。