無論是Web端還是移動端，現在第三方應用賬戶登錄已經成為了標配，任意打開個網站都可以看到，QQ/微信賬號登錄的字樣。使用第三方賬戶的登錄的過程，既要限制用戶身份只讓有效注冊用戶才能登錄，還要根據注冊用戶的不同身份來控制能瀏覽的內容，這就需要認證和授權
相關文章鏈接：
1. 何為認證，何為授權
認證（authenticate）和授權（authorize）是兩個容易被弄混的概念，尤其是只看英文。
認證意味著證實某個用戶是他所聲明的那個人；授權意味決定一個身份確定的用戶能夠訪問那些資源。
由此可見，應用需要先認證用戶身份，然后依據用戶身份再授權，二者需要聯合使用。
對于QQ或者微信這樣的應用，用戶在登錄后會得到該賬戶的身份憑證。如果其他第三方應用信任并接受QQ或者微信的身份憑證，就可以直接使用該憑證通過第三方的認證而登錄。登陸之后用戶能有權限去做什么，這就是第三方應用根據自己政策而進行的授權。我們常遇到有網站在第一次使用QQ或微信賬戶登錄之后需要綁定已用賬戶，就是因為雖然網站能夠通過QQ賬戶的身份認證，但是對于這樣的賬戶沒有對應的授權。
同理，對于一個面向公司內部的服務環境，該公司可能有郵箱系統、網上辦公系統、財務系統等等。如果這些系統都是獨立的，那么公司的員工就需要每一個系統都分配一個賬戶，每個系統都需要單獨登錄。這樣顯然是低效而麻煩的，更好的解決方案應該是用戶在內網中只需要登錄一次，所有的子應用系統都能認證其身份，而免去重復登錄，這樣的方案就被稱為單點登錄（single sign-on， SSO）。
這樣做的最明顯的好處就是提高用戶體驗，用戶只需要維護一對用戶名和口令可以在公司內部暢通無阻。同時，因為是單點登錄，所有的用戶身份的都被統一認證，也就是說用戶的身份憑據（比如口令）只被保存在一處，其他子系統并不直接獲得用戶的口令等敏感信息，而是接收來自可信來源的身份證明。
單點登錄和統一認證中主要的三個協議是OpenID, OAuth, 金和 SAML，被稱為單點登錄的三駕馬車。這些協議已經有了各種語言版本的實現，本人也在其他文字做了詳盡的介紹，這里專門對比下三種協議的異同。
2. OpenID
OpenID是一種認證標準，互聯網上有很多賬戶都是支持OpenID比如谷歌、雅虎、PayPal等等。
用戶要使用OpenID就必須先在OpenID身份服務器（Identity Provider， IDP）獲得OpenID 賬號（比如Google賬戶）。用戶可以使用OpenID賬戶來登錄任何一個接受OpenID認證的服務應用（the relying party，RP，依賴方）。OpenID協議標準就是提供一個框架用來IDP和RP之間通信。
本質而言，用戶的OpenID是一個為用戶個人所擁有的特殊URL(比如 alice2016.openid.com)，所以有些網站甚至會提供選項讓用戶自己去填寫OpenID。
FaceBook曾經也是使用過OpenID的，后來轉而開發FaceBook Connect.
OpenID的最新版本是OpenID Connect。具體協議信息請見這里 OpenID Connect 協議入門指南
3. OAuth2
準確來講，OAuth2是一個授權的標準協議。也許會令人困惑，OAuth2是OpenID-Connect的基礎，但是OpenID-Connect是認證協議（在OpenID-Connect中，ID-Token也被當做是一種資源）。
讓我們回到OAuth2，OAuth2提供了一種代理訪問機制，也就是說一個應用（可以被稱為客戶端）可以代替用戶到資源服務器上獲得屬于用戶的資源或是進行符合用戶權限的操作 ，而用戶不用將自己的用戶名和口令等身份憑據分享給客戶端。OAuth2是通過IDP給第三方應用頒發令牌（Token）來實現以上功能的，第三方應用通過使用令牌向資源服務換取對應的資源。
在Twitter的OAuth指導手冊中說OAuth2是一種認證協議，實際上，這是基于授權的“偽認證”。
OAuth協議的認證過程可以類比為如下流程：Alice要外出一段時間，讓自己的朋友Bob代為照顧她的房子，所以Alice把自己房子的鑰匙交給了Bob，而Bob也就可以任意的進入房子。這里的鑰匙就是一種授權的體現——Alice授權Bob進入房子。在這里例子中，房子的所有者Alice就是用戶，Bob是客戶端，而門鎖就是IDP，房子是資源服務器。
如果假設房子鑰匙的擁有者就是房子的所有者，那么這個授權的過程也是一種偽認證，之所以加一個偽字，是因為
這個假設并不是總是成立的，比如Bob雖然有鑰匙，但是并不是房子的所有者Alice。
更多OAuth的內容，請參見我之前的文章。OAuth2.0 協議入門指南
4. SAML
SAML協議是三者中時間最長的協議，最初版本制定于2001年，并于2005年修改。作為一種安全性斷言標記語言，SAML協議既可以用于認證也用于授權。
所謂的安全性斷言，就是關于認證、授權以及用戶屬性（比如用用戶的有效或者住址等信息）的聲明集合，在SAML中，這些斷言以XML的格式傳輸。
當要驗證一個用戶身份時，服務提供商（Service Provider, SP，即RP，應有依賴方）會向IDP發出SAML認證請求，該請求中會以XML格式說明認證方式的設置，比如希望IDP以何種方式驗證用戶；IDP在認證通過用戶身份之后，會返回SAML請求響應，同樣以XML格式返回斷言表明用戶身份和相關屬性，此外SAML安全性斷言信息必須要使用數字簽名以保證其完整性和不可抵賴性（沒有強制要求對SAML斷言加密）；SP接收到SAML斷言之后，驗證其消息來源是否費受信任的IDP，驗證通過之后解析XML獲得認證信息。
除了斷言，SAML還定義了如下概念：
- 協議（protocols）：如何請求和響應斷言信息；
- 綁定（binding）：SP和IDP之間如何通信和傳遞數據；
- 配置描述（profiles）：用來設置斷言、協議和綁定的中所需要使用的變量。
更為詳細的內容請見：
5. 協議的對比
以下是三種協議的相關對比和總結，便于讀者根據自己實際情形來選擇下一步要繼續去了解哪一種協議。
| 對比點 | OAuth2 | OpenID | SMAL |
|---|---|---|---|
| 票據格式 | JSON or SAML2 | JSON | XML |
| 支持授權 | Yes | No | Yes |
| 支持認證 | “偽認證” | Yes | Yes |
| 創建年份 | 2005 | 2006 | 2001 |
| 最新版本 | OAuth2 | OpenID Connect | SAML 2.0 |
| 傳輸方式 | HTTP | HTTP GET and HTTP POST | HTTP重定向，SAML SOAP綁定，HTTP POST綁定等 |
| 安全弱點 | 不能抵抗網絡釣魚，OAuth沒有使用數據簽名和加密等措施，數據安全完全依賴TLS | 不能抵抗網絡釣魚，一個釣魚的IDP如果惡意記錄下來用戶的OpenID，將會造成很嚴重的隱私安全問題 | XML簽名存在漏洞，可能被偽造 |
| 使用場景 | API 授權 | 商用應用的單點登錄 | 企業級單點登錄，但是對于移動端支持不是很好 |
6. 深入了解
如果想進一步以上協議的具體，歡迎閱讀我的其他文章：
