原文作者：Jeff Atwood

隨著Stack Overflow開發工作的逐步深入，我們不可迴避地碰到了這個問題：我們需要讓使用者登入，即使網路上使用者名稱/密碼已經氾濫成災，我們也只能隨波逐流。我已經有50對使用者名稱/密碼了。我根本記不住它們。但是，為StackOverflow.com再增加一對又何妨呢？

在我的朋友Jon Galloway的力勸之下，我打算看一看OpenID。OpenID的目標就是要解決這個“登入爆炸”的問題：

有了OpenID，你就不必在不同的網站上分別建立使用者名稱了——它能讓你的上網體驗變得更加簡易。

你需要選擇一個最符合你要求的OpenID供應商，最重要的是，你要信任它。並且，不管你選擇哪個供應商，你都可以一直保留你的OpenID。最最美妙的是，OpenID技術並不是私有的，而且它完全免費。

秉著“少說、多做”的精神，接下來，我將解釋OpenID的工作原理。

讓我們假設你第一次訪問某個新的網站。在隨意瀏覽之後，你最終想做一些匿名訪客沒有許可權做的事情。於是，你會被帶到一個“建立新賬號”之類的頁面。我相信，每個人都碰到過這種情況。但是，如果這個網站支援OpenID，你就可以跳過建立新賬號所需的那些繁瑣步驟。在這種情況下，你只須輸入你的OpenID：

為了簡單起見，假設你已經有了一個OpenID賬號。坦率地說，這種假設並不過分。事實上，所有美國線上和雅虎的使用者都已經有了一個OpenID賬號（即使他們自己還沒意識到這一點）。

從技術上來說，OpenID其實就是URL。下面是幾個例子：

• http://claimid.com/yourname
• http://yourname.signon.com
• https://me.yahoo.com/yourname

這裡有一個可用性問題：與記住Email地址比起來，你必須記住相對完整的OpenID URL，而且各個OpenID供應商定義的格式還各不相同。面對這個問題，儘管也有巧妙的方法（我會在後面提到），但眼下的ID選擇控制元件也不賴，它提供了相當友好的介面來協助使用者完成OpenID URL的構建。

如果你輸入的URL是正確的，你會被重定向到OpenID供應商的網站，然後你在那兒輸入你唯一的一對使用者名稱/密碼。

你會看到提示，要求將你當前訪問的這個網站加入到供應商的“可信網站”列表裡，並與你的賬號繫結。一旦你做了這一步，下次再訪問這個網站的時候你就可以省去所有這些步驟了。

最後，你總算完成了首次登入！

如果整個過程看起來挺費周折的——注意，我還沒算上建立最初的ClaimID賬號的時間呢——沒錯，我不想騙你，你需做的事情確實更多了。但是，值得注意的是：

• 在OpenID供應商網站上建立賬號的成本最終可以分攤到幾十個能接受OpenID的網站上，因為你將使用同一對使用者名稱/密碼在這些網站上登入。
• 對於一個特定的網站，在第一次使用OpenID登入時稍顯麻煩，但後續的登入只需一次點選就可完成（假設你在第一次登入時已將這個網站加入了“可信網站”列表）。

OpenID並不完美，但跟必須為50個不同的網站記住50個不同的使用者名稱和密碼比起來，它已經是一個很大的進步了。你難道不這麼認為嗎？我認為它可以與“無阻力溝通”方面的冠軍（匿名評論框）一比高下。匿名評論框通常要求填寫3塊內容：使用者名稱、URL和Email。而OpenID只要求一個。如果你選擇的供應商巧妙地支援了“屬性交換”，你的URL和Email會被代理、自動從供應商的配置中轉回到你所訪問的網站。

這就引出了OpenID的另一個問題。你使用OpenID的體驗如何，很大程度上取決於你所選擇的供應商。比如，雅虎就很聰明，即使你只輸入了“yahoo.com”作為OpenID URL，它照樣能工作。（假設你已經為你的雅虎賬號設定了OpenID的支援。）供應商還可以提供一些獨特的功能，使自己有別於其他供應商。例如，SignOn.com允許使用Windows上的資訊卡，這樣的話，你甚至不用輸入任何密碼就可以登入一個網站。當然，你需要做一些準備工作，也就是要預先把你的供應商賬號與資訊卡關聯起來。我試過了，正如廣告上所說的那樣，這種方法行得通。

在試驗過OpenID之後，我的感覺還是相當正面的。不過，擺在OpenID面前的也不盡是美酒與鮮花。Stefan Brands經過詳盡的論證，他在“The Problem(s) with OpenID”一文中指出了OpenID的一些潛在的大問題：

• 釣魚。一個惡意網站可能訪問你提供的OpenID URL，監視登入表單，然後竊取你的使用者名稱和密碼。然而，如果你選擇的是一個優質的OpenID供應商，他們會使用SSL和高階證書，於是你有理由相信你不會被愚弄。雅虎還為OpenID登入提供了圖片水印，以此作為反釣魚的一種手段。
• 隱私。你選擇的OpenID供應商知道你通過它的賬號訪問的所有網站。這是理所當然的。但願你選擇的供應商是信得過的。
• 風險高度集中。如果你的OpenID賬號被人盜用了，你用它登入過的所有網站全都會遭殃。跟Email賬號被盜用比起來——很多（大部分？）網站允許你使用Email來重置密碼——我不確定OpenID賬號被盜用的危險是不是更大。
• 信任缺失。OpenID供應商不做任何身份認證。它有點像那些你可以在網上輕易獲取的“標識卡”，跟你的駕駛證比起來（它可是由權威的當地政府部門頒發的），OpenID在標示身份方面毫無用處。假如有人建立了一個假的OpenID賬號來冒充史蒂夫•喬布斯，或者OpenID供應商本身就是個冒牌貨，結果會怎麼樣呢？
• 額外的複雜。現在，登入過程會牽涉兩個完全不同的實體：一個是你試圖訪問的網站，另一個是OpenID供應商的網站。你必須理解兩者之間的這種關係，才能排解你在登入過程中碰到的任何問題。另外，OpenID供應商的服務必須保持穩定運轉，否則你根本無法完成登入。
• 接受度不一。對於美國線上、雅虎、Six Apart和Technorati這些公司來說，他們很容易就成為了OpenID的供應商，但如果很少人去用OpenID，這又有什麼意義呢？正如Dare Obasanjo在“A Proposal for Social Network Interoperability via OpenID”（通過OpenID實現社交網路互動性的一個提議）一文中指出的那樣，接受競爭對手的賬號缺乏經濟方面的動機，而推動使用者在自己的網站上建立賬號卻有大量的“油水”。從目前來看，OpenID主要是由一些小型應用和網站來推動的，因為它們的業務沒有幾百萬美元這麼大的誘惑。

正如我前面所說的，我覺得這些詬病中的大部分都可以通過選擇一個值得信賴的優質OpenID供應商來避免。特別是，你選擇的供應商須使用SSL。既然這是一個開放的生態系統，我希望更多有良好信譽、可靠的OpenID供應商能夠挺身而出。考慮一下它的優點吧：作為應用程式的開發者，你不再需要顧及如何儲存密碼了！這是一個巨大的好處，因為你要儘可能避免儲存使用者的密碼。你一定要聽我這句話！

我還發現了Jan Miksovsky在2007年8月發表的一篇文章，題為“OpenID:Great idea, bewildering consumer experience”（OpenID的想法不錯，但使用者體驗讓人很困惑）。他在文中痛快淋漓地批判了OpenID的使用者體驗：

這究竟是為啥？就為了讓我不必選擇一對使用者名稱和密碼嗎？儘管那很無聊，但也不算太難吧！記住一個隨意的使用者名稱確實挺麻煩的，但只要允許Email地址用作ID幾乎就可以解決所有的問題。隨著越來越多的網站允許Email地址作為ID來登入，使用者對OpenID的需求就沒那麼迫切了。

為了共享ID的一點邊際效益，一個理智的運營商會願意折磨他們的使用者嗎？至少在眼下，那是無法想象的。我看到很多人宣稱，只要像谷歌這樣的大佬支援一下OpenID，問題便會迎刃而解。遺憾的是，不管公司規模是大是小，他們都承受不起使用者的流失。

大多數服務運營商會盡量把選擇權留給使用者——既支援私有ID，又支援OpenID——但對使用者來說，這卻是一個討厭的經濟命題：要麼在令人費解的流程裡一次性折騰30分鐘，要麼在每一個網站上都花兩分鐘快速過一遍熟悉的流程（他們以前已經做過無數次了）——人們都很忙，一般總是會選擇自己熟悉的方法。我敢打賭，大部分人會繼續使用私有ID——賭什麼都行！這將進一步延遲採納OpenID可能帶來的網路效應。

在Jan Miksovsky丟擲的觀點中，最引人注目的也許是這個：讓使用者把自己與一個隨意的URL（而不是Email地址）關聯在一起，這是有點古怪的！在今天的試驗中，我也確實看到了一些網站不修邊幅的情況。但我想說的是，自從Jan當初研究了OpenID以來，OpenID的使用者體驗已經有了提升。這讓人很受鼓舞！

我知道，OpenID遠不是一個理想的解決方案。但是在眼下，“每個網站都有單獨的登入賬號”的問題已經非常嚴重，以致於我願意接受一些折中方案，以免情況繼續惡化下去。我絕不可能把我的銀行賬號與OpenID繫結。但是，還有很多其他的網站，我不需要它們達到銀行那樣的安全級別，而我使用它們的頻率遠遠高於我的銀行賬號。要記住所有這些網站上的登入賬號——一旦密碼忘記了，我的Email收件箱就成了事實上的集合點和安全通道——所有這些痛苦累加起來，是巨大的、實實在在的！

如果你是一位軟體開發者、你在做一個需要使用者登入的應用程式，請考慮採用OpenID，而不是讓使用者建立新的使用者名稱/密碼來繼續玷汙這個世界。我也鼓勵你以使用者的身份去試驗一下OpenID：建立一個OpenID賬號，然後用它去登入某個支援OpenID的網站（比如StackOverflow.com）。如果你不喜歡這種體驗，或者如果你在我前面列出的批判中同意其中的一點（或者更多），請想一想：我們怎麼一起來解決呢？對於“登入爆炸”問題，我們急切地需要一個解決方案。但是在眼下，我看到的唯一有希望的只有OpenID（儘管它飽受非議）。

如果我們不能讓OpenID至少應用到一些低價值的一般性網站上，我們對解決“登入爆炸”問題還能抱有什麼希望呢？