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

OpenID

OpenID是一個開放的Authentication解決方案，關(guān) 于OpenID，我在06年的文章里已經(jīng)談過，不過那時談的是最早版本的OpenID，也不知道是哪個版本，現(xiàn)在用的主要是OpenID Authentication 2.0及其周邊的一些擴(kuò)展功能。OpenID Auth 2.0基本原理與以前的版本沒有本質(zhì)的變化，只是在安全性和一些細(xì)節(jié)功能上有所增強(qiáng)。

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

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

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

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

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

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

簡單注冊擴(kuò)展約定了Profile的8個字段，實現(xiàn)起來較為簡單。屬性交換則更強(qiáng)大一些，可以雙方約定任意數(shù)量和內(nèi)容的字段，實現(xiàn)起來略復(fù)雜一些。

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

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

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

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

以上就是關(guān)于OpenID的基本介紹，具體的實現(xiàn)可以到官網(wǎng)下載各種語言實現(xiàn)的源碼研究。

OAuth

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

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

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

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

OAuth 1.0是一個被設(shè)計得非常安全的協(xié)議：除了Provider與Consumer之前的驗證過程是相當(dāng)安全的以外，它甚至要求對每一次的數(shù)據(jù)請求（API調(diào)用）都要進(jìn)行請求內(nèi)容的數(shù)字簽名，以確保萬無一失。

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

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

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

實現(xiàn)

關(guān)于以上相關(guān)技術(shù)的實現(xiàn)，有空再來做吧。暫時計劃包含：Google OpenID, Twitter OAuth 1.0, Foursquare OAuth 2.0

Authentication和Authrization（下）