認證 （ authenticate ）和 授權 （ authorize ）是兩個容易被弄混的概念，尤其是只看英文。
由此可見，應用需要先認證用戶身份，然後依據用戶身份再授權，二者需要聯合使用。
對於QQ或者微信這樣的應用，用戶在登錄後會得到該賬戶的身份憑證。如果其他第三方應用信任並接受QQ或者微信的身份憑證，就可以直接使用該憑證通過第三方的 認證 而登錄。登陸之後用戶能有權限去做什麽，這就是第三方應用根據自己政策而進行的 授權 。我們常遇到有網站在第壹次使用QQ或微信賬戶登錄之後需要綁定已用賬戶，就是因為雖然網站能夠通過QQ賬戶的身份認證，但是對於這樣的賬戶沒有對應的授權。
同理，對於壹個面向公司內部的服務環境，該公司可能有郵箱系統、網上辦公系統、財務系統等等。如果這些系統都是獨立的，那麽公司的員工就需要每壹個系統都分配壹個賬戶，每個系統都需要單獨登錄。這樣顯然是低效而麻煩的，更好的解決方案應該是用戶在內網中只需要登錄壹次，所有的子應用系統都能認證其身份，而免去重復登錄，這樣的方案就被稱為單點登錄（ single sign-on， SSO ）。
這樣做的最明顯的好處就是提高用戶體驗，用戶只需要維護壹對用戶名和口令可以在公司內部暢通無阻。同時，因為是單點登錄，所有的用戶身份的都被 統壹認證 ，也就是說用戶的身份憑據（比如口令）只被保存在壹處，其他子系統並不直接獲得用戶的口令等敏感信息，而是接收來自可信來源的身份證明。
單點登錄和統壹認證中主要的三個協議是 OpenID , OAuth , 金和 SAML ，被稱為單點登錄的三駕馬車。這些協議已經有了各種語言版本的實現，本人也在其他文字做了詳盡的介紹，這裏專門對比下三種協議的異同。
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 協議入門指南
準確來講，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 協議入門指南
SAML協議是三者中時間最長的協議，最初版本制定於2001年，並於2005年修改。作為壹種安全性斷言標記語言，SAML協議既可以用於認證也用於授權。
所謂的安全性斷言，就是關於認證、授權以及用戶屬性（比如用用戶的有效或者住址等信息）的聲明集合，在SAML中，這些斷言以XML的格式傳輸。
當要驗證壹個用戶身份時，服務提供商（Service Provider, SP，即RP，應有依賴方）會向IDP發出SAML認證請求，該請求中會以XML格式說明認證方式的設置，比如希望IDP以何種方式驗證用戶；IDP在認證通過用戶身份之後，會返回SAML請求響應，同樣以XML格式返回斷言表明用戶身份和相關屬性，此外SAML安全性斷言信息必須要使用數字簽名以保證其完整性和不可抵賴性（沒有強制要求對SAML斷言加密）；SP接收到SAML斷言之後，驗證其消息來源是否費受信任的IDP，驗證通過之後解析XML獲得認證信息。
除了斷言，SAML還定義了如下概念：
更為詳細的內容請見：
以下是三種協議的相關對比和總結，便於讀者根據自己實際情形來選擇下壹步要繼續去了解哪壹種協議。
如果想進壹步以上協議的具體，歡迎閱讀我的其他文章：