OpenID

<image>

OpenID是一個去中心化的網上身份認證系統。對於支持OpenID的網站，使用者不需要記住像使用者名稱和密碼這樣的傳統驗證標記。取而代之的是，他們只需要預先在一個作為OpenID身份提供者（identity provider, IdP）的網站上註冊。OpenID是去中心化的，任何網站都可以使用OpenID來作為使用者登錄的一種方式，任何網站也都可以作為OpenID身份提供者。OpenID既解決了問題而又不需要依賴於中心性的網站來確認數字身份。

## 歷史

OpenID最初由LiveJournal的布萊德·菲茲派翠克開發，後來加入了Light-Weight Identity，Yadis，Sxip DIX protocol和XRI/i-names。未來的OpenID規範正在由OpenID.net開發，130多個技術公司、服務公司和開源開發者都參與其中。

為了推動OpenID的應用，2006年8月，成員公司贊助設立了OpenID獎勵計劃，對前10位滿足要求的軟體項目各獎勵5000美元。

2007年12月5日，OpenID驗證規範9.0和屬性交換規範9.0發布。

## 內容

OpenID相關基本術語：

最終使用者（End User）

想要向某個網站表明身份的人。

標識（Identifier）

最終使用者用以標識其身份的URL或XRI。

身份提供者（Identity Provider, IdP）

提供OpenID URL或XRI註冊和驗證服務的服務提供者。

依賴方（Relying Party, RP）

想要對最終使用者的標識進行驗證的網站。

### 登錄

一個想要為其訪問者提供OpenID登錄網站，比如example.com，需要在頁面的某個地方放置一個登錄表單。與提示使用者輸入使用者名稱和密碼的傳統登錄表單不同的是，這種表單只有一個輸入框：OpenID標識。網站可以選擇在這個輸入框旁顯示一個小的OpenID圖標。這個表單與OpenID客戶端庫的實現相連接。

假設使用者Alice在身份提供者openid-provider.org處註冊了一個OpenID標識：alice.openid-provider.org。如果Alice想使用這個標識來登錄example.com，她只需要到example.com去將alice.openid-provider.org填入OpenID登錄表單。

如果標識是一個URL，依賴方example.com做的第一件事情是將這個URL轉換為典型格式：http://alice.openid-provider.org/。在OpenID 1.0中，依賴方接著請求該URL對應的網頁，然後通過一個HTML連結tag發現提供者伺服器，比如http://openid-provider.org/openid-auth.php。同時也確定是否應該使用授權身份（delegated identity）。從OpenID 2.0開始，依賴方請求的是XRDS文檔（也稱為Yadis文檔），使用內容類型application/xrds+xml。這種類型在URL中可能存在，而在XRI中總是存在。

依賴方可以通過兩種模式來與身份提供者通信：

- `checkid_immediate`：兩個伺服器間的所有通信都在後台進行，不提示使用者。
- `checkid_setup`：使用者使用訪問依賴方站點的同一個瀏覽器窗口與身份提供者伺服器交互。

第二種模式更加常用。而且，如果操作不能夠自動進行的話，checkid_immediate模式會轉換為checkid_setup模式。

首先，依賴方與身份提供者建立一個「共享秘密」——一個聯繫句柄，然後依賴方存儲它。如果使用checkid_setup模式，依賴方將使用者的網頁瀏覽器重定向到提供者。在這個例子裡，Alice的瀏覽器被重定向到openid-provider.org，這樣Alice能夠向提供者驗證自己。

驗證的方法可能不同，但典型地，OpenID提供者要求提供密碼（然後可能使用cookies存儲使用者會話，就像很多基於密碼驗證的網站的做法一樣）。如果Alice當前沒有登錄到openid-provider.org，她可能被提示輸入密碼，然後被問到是否信任依賴方頁面——如http://example.com/openid-return.php，這個頁面被example.com指定為使用者驗證完成後返回的頁面——獲取她的身份資訊。如果她給出肯定回答，OpenID驗證被認為是成功的，瀏覽器被重定向到被信任的返回頁面。如果Alice給出否定回答，瀏覽器仍然會被重定向，然而，依賴方被告知它的請求被拒絕，所以example.com也依此拒絕Alice的登錄。

但是，登錄的過程還沒有結束，因為在這個階段，example.com不能夠確定收到的資訊是否來自於openid-provider.org。如果他們之前建立了「共享秘密」，依賴方就可以用它來驗證收到的資訊。這樣一個依賴方被稱為是stateful的，因為它存儲了會話間的「共享秘密」。作為對比，stateless的驗證方必須再作一次背景請求（check_authentication）來確保數據的確來自openid-provider.org。

Alice的標識被驗證之後，她被看作以alice.openid-provider.org登錄到example.com。接著，這個站點可以保存這次會話，或者，如果這是她的第一次登錄，提示她輸入一些專門針對example.com的資訊，以完成註冊。

### 運作

OpenID Connect協議遵循以下步驟：

- 終端使用者透過瀏覽器導航到網站或Web應用程式。
- 終端使用者單擊登入並輸入使用者名稱和密碼。
- RP（客戶端）向OpenID提供商（OP）傳送請求。
- OP對使用者進行身份驗證並獲得授權。
- OP 會使用身份令牌和通常的訪問令牌進行響應。
- RP 可以使用訪問令牌向使用者裝置傳送請求。
- UserInfo Endpoint返回有關終端使用者的資料。

OpenID不提供它自己的驗證方式，但是如果身份提供者使用強驗證，OpenID可被用於安全事務，比如銀行和電子商務。

## 推廣

OpenID正在被越來越多的大網站採用。Yahoo!已經支持OpenID。所有有Yahoo帳戶的使用者可以通過OpenID directed identity方式登錄支持OpenID信賴方網站。

Google 曾經支援OpenID 2.0，不過自 2015 年 4 月 20 日起，Google 帳戶將不再使用 OpenID，轉而使用OpenID Connect。

Orange、AOL與Yahoo!都已經支援OpenID。AOL提供每個AOL或AIM的使用者一組OpenID Identity，目前還在測試階段，為`openid.aol.com/username`。

目前使用OpenID代替一般帳號密碼的網站包括了 著名的開源社區SourceForge、LiveJournal、Zooomr、Wikitravel、ma.gnolia.com、claimid.com以及Jyte。

在openid.net上有一份公開的 伺服器列表，可以讓一般人申請OpenID Identity。

## 安全

### 隱蔽重定向漏洞(Covert Redirect)

2014年5月，新加坡南洋理工大學一位名叫王晶（Wang Jing）的物理和數學科學學院博士生，發現了OAuth和OpenID開源登錄工具的"隱蔽重定向漏洞"。

其實漏洞不是出現在OpenID這個協議本身，這個協議本身是沒有問題的，之所以存在問題是因為各個廠商沒有嚴格參照官方文檔，只是實現了簡版。問題的原因在於OpenID的提供方提供OpenID授權過程中沒有對回調的URL進行校驗，從而導致可以被賦值為非原定的回調URL。