上一篇我們介紹了單點登錄（SSO），它能夠實現多個系統的統一認證。今天我們來談一談近幾年來非常流行的，大名鼎鼎的OAuth。它也能完成 統一認證，而且還能做更多的事情。 OAuth 2.0是目前最流行的授權機制，用來授權第三方應用，獲取用戶數據 **單點登錄（SSO）和OAuth在流程上的最大區別就是，通過ST或者code去認證的時候，需不需要預先商量好的密碼（appid和appSecret）**  如上圖所示，用戶通過瀏覽器（Browser）訪問app1，他想用微信的賬號直接登錄，這樣就免去了在app1系統的注冊流程。這樣的流程完全符合 單點登錄（SSO），但我們今天要看看OAuth是怎么做的 應用：第三方登錄、第三方應用api如微信公眾號等 # 具體流程  流程比單點登錄（SSO）復雜了很多，但是它比SSO更強大。接下來我們好好捋一捋這個流程： 1. 用戶訪問app1系統，app1返回登錄頁，讓用戶登錄。 2. 用戶點擊微信登錄，這里的微信就是OAuth Server，跳轉到微信登錄頁，帶上參數appid和回調地址（backUrl）。關于appid我們要詳細 說一下，我們在與OAuth Server做對接的時候，先要在OAuth Server上注冊自己的系統（app1），需要填寫應用的名稱、回調地址等， OAuth Server會生成appid和appSecret，這兩個變量是非常關鍵的。 3. 微信后臺（OAuth Server）根據appid查找到app1的注冊信息，校驗參數backUrl和注冊的回調地址是否一致（這里可以只校驗域名或者一級域名， 具體要看OAuth Server怎么設計），如果校驗不通過則返回錯誤，校驗成功則返回授權頁。 4. 微信彈出授權頁，如果微信沒有登錄則彈出登錄并授權頁。這個過程是微信詢問用戶，是否同意app1系統訪問微信的資源。用戶授權后， 微信后臺（OAuth Server）會生成這個用戶對應的code，并通過app1的backUrl返回app1系統。 5. app1系統拿到code后，再帶上appid和appSecret從后臺訪問微信后臺（OAuth Server），換取用戶的token。 6. app1拿到token后，再去微信后臺（OAuth Server）獲取用戶的信息。 7. app1設置session為登錄狀態，并將用戶信息（昵稱、頭像等）返回給Browser。 到這里，OAuth的授權流程就結束了。**有的同學可能很快就會問到：用戶授權后，為什么不直接返回token，而是要用code換取token？ 這是因為如果直接返回token，token會先到瀏覽器（Browser），然后再到app1系統，到了瀏覽器，這個token就是不安全的了，有可能被 竊取，token被竊取后，微信后臺（OAuth Server）中，這個用戶的信息就不安全了。然而在用code換取token時，是帶上了appid和appSecret 的，微信后臺（OAuth Server）可以判斷appid和appSecret的合法性，確認無誤后，再將token返回給app1。這里是直接返回app1，沒有經過瀏覽器， token是安全的。** ## 靜默登錄 上面的流程是用戶先訪問app1，點擊微信登錄后，跳到微信。如果我們先打開了微信，在微信里邊再打開app1，這個流程就好像我們在 微信里打開了京東，這里微信就是OAuth Server，京東就是app1。在這個流程中，我們可以省略掉詢問用戶是否授權的過程，也就是在微信里 打開京東（app1）的時候，京東（app1）帶著appid和backUrl訪問微信（OAuth Server），微信（OAuth Server）驗證appid和backUrl， 并且微信（OAuth Server）已經是登錄的，這里并沒有詢問用戶是否授權京東訪問自己在微信的資源，直接將code返回給了京東。從而使 京東登錄，并且在京東里顯示的用戶在微信中的昵稱和頭像等信息。 使用靜默登錄一般都是你的系統做的比較牛了，被資源方看中了，要把你的系統嵌入到資源方去。比如：微信中嵌入了京東。 上面的例子中，我們只做了獲取用戶信息，其實還可以開放很多信息，例如：用戶的賬戶余額等。要開放哪些資源就看OAuth Server的了。 這也就是我們常說的open api。要做open api，上面的OAuth流程是必不可少的。 ***** # 與單點登錄（SSO）的對比 單點登錄（SSO）是保障客戶端（app1）的用戶資源的安全 。 ## OAuth則是保障服務端（OAuth）的用戶資源的安全 。 單點登錄（SSO）的客戶端（app1）要獲取的最終信息是，這個用戶到底有沒有權限訪問我（app1）的資源。 ## OAuth獲取的最終信息是，我（OAuth Server）的用戶的資源到底能不能讓你（app1）訪問。 單點登錄（SSO），資源都在客戶端（app1）這邊，不在SSO Server那一方。 用戶在給SSO Server提供了用戶名密碼后，作為客戶端app1并不知道這件事。 隨便給客戶端（app1）個ST，那么客戶端（app1）是不能確定這個ST是否有效，所以要拿著這個ST去SSO Server再問一下，這個ST是否有效， 是有效的我（app1）才能讓這個用戶訪問。 OAuth認證，資源都在OAuth Server那一方，客戶端（app1）想獲取OAuth Server的用戶資源。 所以在最安全的模式下，用戶授權之后， 服務端（OAuth Server）并不能通過重定向將token發給客戶端（app1），因為這個token有可能被黑客截獲，如果黑客截獲了這個token， 那么用戶的資源（OAuth Server）也就暴露在這個黑客之下了。 于是OAuth Server通過重定向發送了一個認證code給客戶端（app1）， 客戶端（app1）在后臺，通過https的方式，用這個code，以及客戶端和服務端預先商量好的密碼（appid和appSecret），才能獲取到token， 這個過程是非常安全的。 如果黑客截獲了code，他沒有那串預先商量好的密碼（appid和appSecret），他也是無法獲取token的。 這樣OAuth就能保證請求資源這件事，是用戶同意的，客戶端（app1）也是被認可的，可以放心的把資源發給這個客戶端（app1）了。 **總結：所以單點登錄（SSO）和OAuth在流程上的最大區別就是，通過ST或者code去認證的時候，需不需要預先商量好的密碼（appid和appSecret）。** # 總結 OAuth和SSO都可以做統一認證登錄，但是OAuth的流程比SSO復雜。SSO只能做用戶的認證登錄，OAuth不僅能做用戶的認證登錄，開可以做 open api開放更多的用戶資源