說明：本來想多分幾篇來寫的，但似乎談太具體的話，不適合放在這樣一個標題下，所以這里先簡單介紹一下，之后再視情況挑一些內容重點扯一扯

OpenID

OpenID是一個開放的Authentication解決方案，關 于OpenID，我在06年的文章里已經談過，不過那時談的是最早版本的OpenID，也不知道是哪個版本，現在用的主要是OpenID Authentication 2.0及其周邊的一些擴展功能。OpenID Auth 2.0基本原理與以前的版本沒有本質的變化，只是在安全性和一些細節功能上有所增強。

基本的OpenID Authentication登錄流程如下圖：

1、首先用戶在依賴方（即第三方網站）輸入其OpenID URL進行登錄（也可以直接使用提供方ID登錄，這種方式則沒有第2、3步）；
2、（可選）依賴方從用戶OpenID URL的頁面中執行自動發現；
3、取得OpenID提供方的End Point URL；
4、（可選）依賴方與提供方建立關聯；
5、取得關聯的約定加密信息；
6、重定向用戶瀏覽器到提供方；
7、用戶登錄到提供方并授權第三方的認證請求；
8、返回認證結果（是否通過用戶身份驗證）；
9、重定向用戶瀏覽器到依賴方，并提交認證結果；
10、依賴方向提供方驗證用戶提交的認證結果；
11、通過用戶認證。

之 后，依賴方可以保存第9步的用戶提交信息，在每次需要驗證用戶身份的時候，重復第10和11步向提供方驗證用戶身份。通常這項工作由session實現。 因為這兩步需要多次進行，為了安全需要每次都必須進行簽名驗證，所以通常還是建議使用第4和5步的建立加密關聯，以方便后續的驗證操作。

過 程中的第2和3步就是OpenID分布式的關鍵，也是我在舊文中認為的OpenID的缺點（或者說是特性）之一。這一步可以讓用戶不受具體的提供方所限， 使認證成為分布式，但同時也使用用戶的認證可靠性受這個OpenID URL對應的網站所限。所以現在很多OpenID認證應用都直接跳過這一步，使用固定（或有限可選的幾個）提供方進行登錄，使之從分布式身份驗證成為第三 方集中式身份驗證。其實我個人認為這樣更好一些。而且這樣還可以減少一對網絡round trip，有助于改善登錄速度。

在這一基礎Authentication之上還有一些額外的約定，基 本的OpenID Authentication在驗證通過以后，除了返回驗證通過信息以外，還可以同時返回用戶的Profile。當然，一般的Provider可以由用戶 選擇驗證返回的Profile內容，比如myopenid.com可以選擇返回一個完整Profile或是一個空白Profile（但仍然返回驗證通過信 息）。那么關于個Profile就需要有一定的協議來約定。

在OpenID 2.0中主要是兩個：簡單注冊擴展(Simple Registration Extension)和屬性交換(Attribute Exchange)。

簡單注冊擴展約定了Profile的8個字段，實現起來較為簡單。屬性交換則更強大一些，可以雙方約定任意數量和內容的字段，實現起來略復雜一些。

這也是Google提供給第三方的OpenID登錄方式就是采用了屬性交換約定。

屬性交換的功能就是在依賴方提交驗證請求 的 同時告訴Provider它需要哪些用戶Profile信息字段（稱為屬性），然后用戶在通過驗證時，Provider將依賴方請求的屬性告訴用戶，由用 戶決定是否允許（只能允許或拒絕，如果拒絕則驗證不通過，不提供空白響應的選項）。

屬性交換除了可以用于讀取所選屬性，還可以用于存儲屬性，當然這需要Provider方支持。

Google提供給第三方的OpenID登錄 流程如下圖：

以上就是關于OpenID的基本介紹，具體的實現可以到官網下載各種語言實現的源碼研究。

OAuth

OAuth是一個開放的Authorization方案，可以說是基于OpenID發展起來的。因為OpenID不能提供Authorization功能：

比如某網站A提供了允許用戶用TA的OpenID登錄，但是如果某網站B需要用到網站A中該用戶的數據，就無法通過OpenID來實現將網站A中的用戶數據安全地授權給網站B——雖然可以讓用戶把自己的OpenID信息提供給網站B，讓它以用戶的身份登錄網站A去取得，但這樣的話如果網站B是一個惡意網站，它就可以以用戶的身份登錄任何其它支持該用戶以OpenID訪問的網站，帶來嚴重的安全隱患。

于是人們需要一個開放的Authorization協議，于是OAuth誕生了。

目前OAuth有兩個幾乎完全不同的版本：OAuth 1.0和OAuth 2.0。

OAuth 1.0是一個被設計得非常安全的協議：除了Provider與Consumer之前的驗證過程是相當安全的以外，它甚至要求對每一次的數據請求（API調用）都要進行請求內容的數字簽名，以確保萬無一失。

而OAuth 2.0則相當于對OAuth 1.0作了很大的簡化：Provider與Consumer之間只是簡單地交換一下密鑰Key進行驗證，之后Consumer只需要憑借驗證后取得的一個Token就可以進行數據請求（API調用），沒有太多的簽名校驗工作。

從技術上說，兩個版本都可以實現Authorization功能，二者的差異在于：1.0更安全，但代價也更大（驗證過程復雜，請求過程復雜）；2.0更方便，但是安全性不如1.0（比如請求可能在傳輸過程中被修改）。

個人傾向于建議使用OAuth 2.0+HTTPS的方案，這樣可以降低編程的復雜度，減少出錯的概率，同時通過HTTPS保障安全性。

實現

關于以上相關技術的實現，有空再來做吧。暫時計劃包含：Google OpenID, Twitter OAuth 1.0, Foursquare OAuth 2.0

Authentication和Authrization（下）