關于oauth 2.0和單點登入

oauth 2.0是開放授權協定，核心思想是授權第三方應用通路使用者的受保護資源；例如第三方應用接入微信登入，就是利用了oauth 2.0來實作的。如果沒有接入微信登入，那使用者使用多個應用系統都需要分别新增賬號，使用者體驗不好，而接入微信登入之後，對于使用者而言，其實就是使用一個微信賬号登入多個應用系統。底層的實作原理是：當第三方應用想要使用微信登入時，目的就是擷取到使用者的微信賬号資訊，例如使用者名、頭像、昵稱等，将這些資訊作為自己平台的賬号資訊，自動為使用者注冊平台賬号，使用者每次隻需要通過微信進行登入即可；但是使用者不會直接把微信賬号密碼給第三方應用，這樣做比較危險，容易越權；而是給第三方應用進行授權，利用令牌代替賬号密碼去通路使用者的微信賬号資訊。整個流程就是利用了oauth 2.0這個授權協定來實作的。

oauth 2.0協定中有四個角色，資源擁有者、用戶端、授權伺服器、受保護資源/資源伺服器。

第三方應用接入微信登入的例子中，使用者就是資源擁有者，第三方應用是用戶端，使用者的微信賬号資訊是受保護資源、微信開放平台是授權伺服器。由于第三方應用擷取到令牌之後，也會使用這個令牌去通路自己的後端API，是以第三方應用其實也屬于資源伺服器。

單點登入和oauth 2.0本質上就不是同一個東西。

單點登入指的是：多個應用的系統中，使用者隻需要登入一次就可以通路其他應用子系統，不需要重複登入多次。例如使用者隻要登入了百度的官網，那麼對于百度百科、百度知道、百度貼吧等網站都是處于登入狀态。

單點登入是一種思想，對應有多種實作方案，例如CAS架構就可以用于實作單點登入。

利用oauth 2.0也可以實作單點登入。

例如A系統和B系統利用了oauth 2.0實作單點登入，當使用者登入了A系統之後，就不需要登入B系統了。完整流程為：使用者首次通路A系統，去到認證中心進行登入認證，認證成功後擷取到令牌；然後B系統使用這個令牌去認證中心校驗後擷取到A系統登入的使用者資訊，就可以直接通路B系統。在這個流程中，A系統作為用戶端角色，去到認證中心申請令牌；而A系統登入的使用者資訊就屬于受保護資源；B系統想要擷取到A系統登入的使用者資訊，利用這個使用者資訊來直接通路B系統。這就實作了單點登入。

對于B系統來說，想要擷取到A系統登入的使用者資訊，并不是直接使用A系統的賬号密碼進行登入，而是利用A系統授權後拿到的令牌，這就是oauth 2.0協定。

使用者通路B系統，需要依靠A系統登入授權後擷取到的令牌，是以B系統是資源伺服器角色；另外，A系統也會使用這個令牌去通路自己的後端API，是以A系統其實也屬于資源伺服器。

如果A系統和B系統任意一方都可以去到認證中心進行登入，擷取令牌，給到對方進行通路，那麼A系統和B系統都可以屬于oauth 2.0協定中的用戶端角色；如果A系統和B系統隻有一方能夠去認證中心登入，另一方就等着接收令牌，那麼能去到認證中心登入的子系統才屬于oauth 2.0協定中的用戶端角色，另一方嚴格上來講其實不屬于用戶端角色，因為用戶端角色的任務就是去認證中心登入，并擷取到令牌。那麼它的角色我們可以認定為資源伺服器。

在前後端分離的架構中，利用oauth 2.0實作單點登入可以分兩種情形，有門戶系統和沒有門戶系統。

如果我們的應用具有門戶系統，使用者要通路A系統或B系統都隻能先登入門戶，擷取到令牌後再使用這個令牌通路A系統和B系統，這種情形中，門戶系統其實就是oauth 2.0中的用戶端角色，而A系統和B系統都屬于資源伺服器。

門戶系統還有另一種情況，假設使用者要通路我們的系統之前，需要通過登入A系統，B系統隻能依靠A系統登入後通過按鈕進行跳轉。那其實A系統的前端就屬于用戶端角色，A系統的後端服務和B系統的後端服務都屬于資源伺服器。

如果沒有門戶系統的情形下，A系統和B系統都有自己的前端登入界面，那其實A系統和B系統是割裂開的；例如淘寶和天貓，這是兩個獨立的系統，有各自的登入界面，使用者登入淘寶之後，就不需要再登入天貓了。這種情形，淘寶和天貓的前端頁面屬于用戶端角色，都可以向授權伺服器申請令牌，而淘寶和天貓的後端服務就屬于資源伺服器。

在企業實際應用中，需要進行單點登入的多個子系統都是有緊密關聯的，是以通常會引進門戶系統或者将某個子系統作為門戶，然後利用nginx進行多個子系統間的轉發。