? ? ? ?sso，單點登錄，single sign on 縮寫。sso多用于多個應用之間的切換，例如百度論壇、百度知道、百度云、百度文庫等，在其中一個系統中登錄，（登錄有效期內）切換到另一個系統的時候，不必再次輸入用戶名密碼。
? ? ? ?oauth2.0，開放授權，不兼容oauth1.0.允許第三方應用代表用戶獲得訪問權限。可以作為web應用、桌面應用和手機等設備提供專門的認證流程。例如，用qq賬號登錄豆瓣、美團、大眾點評；用支付寶賬號登錄淘寶、天貓等。
? ? ? ?sso和oauth2.0在應用場景上的區別在于，使用sso的各個系統（子模塊）之間是互相信任的，通常是一個廠家的產品，或者是一個產品的不同模塊系統。使用oauth2.0的各個應用之間是互相不信任的，通常是不同廠家之間的賬號共享。
? ? ? 常規的身份認證流程：1.登錄頁，我們提交username和pwd；2.server進行身份識別認證，認證通過后將用戶信息寫入session，同時瀏覽器將身份信息寫入cookie；3.訪問其他頁面的時候，瀏覽器請求會帶上cookie，服務端根據cookie找到對應session，相當于完成身份認證。這就是早期通過盜取cookie，模擬用戶通過身份驗證的原理。
? ? ? ?在了解sso和oauth2.0之前，我們必須知道的幾個常識：
? ? ? ?1.cookie不能跨域。
? ? ? ?2.session是存在于各自應用中的，不能共享。
? ? ? ?sso分為同域下的單點登錄和不同域名下的單點登錄。先說同域名下的單點登錄，嚴格來說這不是sso。同域名下情況又分為兩種，但是思路是一致的，共享cookie，共享session。
? ? ? ?第一類：www.a.com/site1和www.a.com/site2，瀏覽器在存儲cookie的時候會將域名記錄為www.a.com，如果不做特殊處理，sessionid是一致的。
? ? ? ?第二類：app1.a.com和app2.a.com，主域名一致，不同子域名。這種情況下可以在寫cookie時，將域名指定為頂級域名，即a.com。但是注意兩個應用的sessionid可是不一致的，兩個應用會各自記錄自己的sessionid，在登錄的時候并不影響，但是退出的時候就會有問題了。
? ? ? ?模擬操作如下：登錄app1.a.com，用戶輸入用戶名密碼，身份認證成功，app1的session1創建，瀏覽器添加cookie【域名為a.com】，登錄app2.a.com，瀏覽器攜帶域名為a.com的cookie，此時系統檢查到app2的session2不存在，然后驗證cookie攜帶的身份信息，身份認證通過，session2創建。到此用戶輸入一次用戶名密碼可以登錄兩個系統。但是退出的時候如果從app1退出，只會清除session1和cookie，session2還在，意味著app2還是登錄狀態。這就需要將各個系統的session共享，不同語言有不同的框架根據實際情況來選擇解決方案。
? ? ? ?下面來說真正的sso。在說sso之前，我們先說cas的流程，集中式認證服務是一種針對萬維網的單點登錄協議，這個協議定義了單點登錄的標準流程，時序圖如下。

　　簡單翻譯如下：
　　1.用戶訪問app1，瀏覽器向app1發出請求。【未登錄狀態】
　　2.app1收到請求后，發現瀏覽器處于未登錄狀態，返回一個302，跳轉訪問cas，并附帶returnurl【即aap1自身地址】。
　　3.瀏覽器收到302后，訪問cas。
　　4.cas返回給瀏覽器一個登錄頁。
　　5.瀏覽器展示登錄頁，用戶攜帶returnurl提交用戶名密碼到cas。
　　6.cas進行身份認證，認證成功創建sso的session和認證ticket（ST），返回302，并將ticket一并返回給瀏覽器
　　7.瀏覽器記錄cookie，帶著ticket（ST）訪問returnurl【app1地址】。（cookie是cas的）
　　8.app1收到請求后，向cas確認ticket（ST）是否有效。
　　9.cas驗證ticket通過后，返回200給app1。
　　10.app1記錄登錄狀態并響應瀏覽器請求（步驟7），返回302到自身（不帶ST）。（添加app1的cookie）
　　11.瀏覽器收到302，訪問app1地址，此時cookie和session齊全，身份認證完成，向瀏覽器返回請求的資源。之后（cookie、session有效期內）訪問app1，不必再身份驗證，直接返回請求資源。【app1登錄完成】
　　此時app1登錄已經完成，當切換到app2的時候，流程如下：
　　12.用戶訪問app2，瀏覽器向app2發出請求。【app2未登錄】
　　13.app2收到請求，發現瀏覽器處于未登錄狀態，返回一個302，跳轉訪問cas，并附帶returnurl【即aap2自身地址】。
　　14.瀏覽器收到302，訪問cas。（由于步驟7已經記錄的cas的cookie，瀏覽器會在請求時將cookie攜帶）
　　15.cas驗證身份，由于有cookie存在，直接返回票據ticket（ST2），并讓瀏覽器重定向。
　　16.瀏覽器帶著ticket（ST2）訪問returnurl。
　　17.app2收到請求后，向cas確認ticket（ST2）是否有效。
　　18.cas驗證ticket通過后，返回200給app2。
　　19.app2記錄登錄狀態并響應瀏覽器請求（步驟16），返回302到自身（不帶ST）。（添加app2的cookie）
　　20.瀏覽器收到302，訪問app2地址，此時cookie和session齊全，身份認證完成，向瀏覽器返回請求的資源。之后（cookie、session有效期內）訪問app2，不必再身份驗證，直接返回請求資源。【app2登錄完成】
　　此時app2登錄完成，app間單點登錄就實現了。其實我一直在思考6-9和13-17這個過程中的ticket（ST）的作用，起初有疑惑：為什么cas通過身份驗證后，不直接將身份信息給app，而是通過302將用戶信息和ticket給瀏覽器，讓瀏覽器再次訪問app，app通過cas驗證ticket（ST）來確保身份有效？這樣兜了一大圈造成很多次系統間的跳轉訪問，降低了效率。后來假設了一種情況：cas將身份信息直接給app（此時應不會再生成ticket，app也無需向cas驗證ticket的有效性），那瀏覽器在沒有通過cas驗證的情況下，直接偽造身份信息，app是否也認為登錄了呢？這種邏輯下，app是一定會允許偽造的身份訪問請求資源的。
　　sso已經簡單介紹完了，下面再看看oauth2.0。oauth2.0的理解我們不妨來模擬這樣一個場景：
　　小單同學經朋友介紹第一次使用美團，注冊美團賬號的時候，頁面上有賬號登錄和快捷登錄兩種方式。快捷登錄方式可以暫不注冊，直接使用qq賬號、微信賬號和微博賬號進行登錄。由于較懶，小單同學選擇了快捷登錄，界面跳轉到一個授權登錄頁面，授權隱私內容包括用戶昵稱、用戶頭像等等，選擇同意授權，在彈出的qq快捷登錄頁面上同意授權之后，界面跳轉到美團的首頁。
　　oauth2.0定義了四個角色：客戶端client，資源所有者resource owner ，資源服務器resource server，授權服務器Authorization server。結合上面的場景，不難看出美團是客戶端，我們用戶是資源的所有者，微信的用戶信息放在了資源服務器上，對賬戶授權的工作放在了授權服務器上。直覺上資源服務器和授權服務器應該是一起的，但是實際項目中，這兩個服務器獨立部署更便于保護用戶的數據信息。

　　oauth2.0的運行流程看起來比sso的簡單點，解釋如下：

　　A，客戶端要求用戶給與授權。我們打開美圖，選擇快速登錄。
　　B，用戶同意授權給客戶端。我們選擇了用qq賬號快速登錄，同意授權給美團我們的用戶信息。
　　C，客戶端拿到用戶給的授權，先授權服務器申請令牌。美圖向qq的授權服務器發起申請。
　　D，認證服務器對客戶端進行認證，確認無誤發放令牌。通常手機端會切換到qq端，驗證登錄狀態，提示是否授權，我們確認登錄之后，服務器發放令牌。
　　E，客戶端使用令牌，申請資源。美團向qq申請用戶信息。
　　F，資源服務器確認令牌無誤，同意開放資源。我們用qq的賬號登錄了美團，美團上顯示我們的qq昵稱、頭像等信息。
　　oauth2.0定義了四種授權類型：授權碼模式authorization code、簡化模式 implict、密碼模式resource owner password credentials 和 客戶端模式 client credentials。授權碼模式為功能最為完整，流程最為嚴密的授權，其他模式為授權碼模式的變體或簡化，下面簡要介紹授權碼模式。
　　授權碼模式基于重定向跳轉，所以客戶端必須能與user-agent（一般為用戶瀏覽器）交互，通過user-agent路由來發送實際的授權碼。（理解前半句就好，后半句大家機翻理解了就理解，不理解問題也不大）

?

　　繼續套用上面的應用場景，各角色對應為client（美團），user-agent（瀏覽器），resource owner（用戶，我們自己），authorization server（qq授權服務器），resource server（qq資源服務器）。我們在實際操作的時候會發現我們沒有操作瀏覽器，其實是app本身（美團）內部已經集成了瀏覽器的功能（作用比功能更恰當一些），所以我們沒有發現client調用user-agent，但其實這個流程是沒有少的。
　　1.client構造了一個用于申請authorization code的請求。通常會有response_type（表明正在申請授權流流程）,client_id（客戶端的身份id）,redirect_url（收到請求的跳轉地址）,scope（權限范圍，或者訪問級別）,state（隨機字符串，防止csrf攻擊）這樣幾個參數。
　　2.當resource owner 訪問步驟一構造的請求，授權服務就跳轉到了這里，由用戶選擇是否授權。
　　3.當用戶選擇授權登錄，授權服務器就會提供授權碼，跳轉到redirect_url地址。授權碼的有效時間不等，取決于授權服務器設置。
　　4.客戶端拿到授權碼，向授權服務器申請token。
　　5.授權服務器根據步驟4中提交的授權碼及身份信息等，決定是否給客戶端發放token。
　　token結構中包含access_token（本次使用的門票），expires_in(本次門票的有效期)，refresh_token（下次使用的門票）這三個重要部分和其他內容。當本次門票過期失效的時候，我們用用refresh_token來申請訪問，授權服務器會再次生成新的token，而不必再進行一次步驟1-4。這樣就實現了完整的第三方登錄認證。
　　相比之下implict簡化模式，更適用于webapp和移動應用。簡化模式不通過第三方應用程序（瀏覽器），直接向認證服務器申請令牌token，跳過了授權碼的步驟。
　　而resource owner password credentials密碼模式則要求用戶在登錄客戶端的時候輸入用戶名密碼，客戶端不能保存用戶名密碼，而是向授權服務器進行認證。這種模式通常用于客戶端是操作系統的一部分，或者（client、resource server）是一個公司出品。
　　嚴格來說 client credentials客戶端模式是由客戶端以自己的名義向授權服務器進行認證，并不是以用戶的名義，因此不屬于oauth框架要解決的范疇。
　　oauth2.0詳細請參考：https://tools.ietf.org/html/rfc6749

轉載于:https://www.cnblogs.com/cnDqf/p/11096443.html

總結

以上是生活随笔為你收集整理的sso和oauth2.0的简单了解学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。