SSO和Auth2.0

1. 簡介

• SSO, single sign on, 單點登錄。sso多用於多個應用之間的切換，例如百度論壇、百度知道、百度雲、百度文庫等，在其中一個系統中登錄，（登錄有效期內）切換到另一個系統的時候，不必再次輸入用戶名密碼。
• oauth2.0，開放授權，不兼容oauth1.0.允許第三方應用代表用戶獲得訪問權限。可以作為web應用、桌面應用和手機等設備提供專門的認證流程。例如，用qq賬號登錄豆瓣、美團、大眾點評；用支付寶賬號登錄淘寶、天貓等。
• sso和oauth2.0在應用場景上的區別在於，SSO是為了解決一個用戶在鑒權服務器登陸過一次以后，可以在任何應用（通常是一個廠家的各個系統）中暢通無阻。OAuth2.0解決的是通過令牌（token）而不是密碼獲取某個系統的操作權限（不同廠家之間的賬號共享）。

2. 常規的身份認證流程

1. 登錄頁，我們提交username和pwd；

2. server進行身份識別認證，認證通過后將用戶信息寫入session，同時瀏覽器將身份信息寫入cookie；

3. 訪問其他頁面的時候，瀏覽器請求會帶上cookie，服務端根據cookie找到對應session，相當於完成身份認證。

局限：

• cookie不能跨域。
• session是存在於各自應用中的，不能共享。例如：
  • app1.a.com和app2.a.com，主域名一致，不同子域名。這種情況下可以在寫cookie時，將域名指定為頂級域名，即a.com。但是注意兩個應用的sessionid可是不一致的，兩個應用會各自記錄自己的sessionid，在登錄的時候並不影響，但是退出的時候就會有問題了。如果從app1退出，只會清除session1和cookie，session2還在，意味着app2還是登錄狀態。這就需要將各個系統的session共享。

3. SSO身份認證流程

1. 用戶訪問app1，瀏覽器向app1發出請求。【未登錄狀態】

2. app1收到請求后，發現瀏覽器處於未登錄狀態，返回一個302，跳轉訪問cas，並附帶returnurl【即app1自身地址】。

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登錄完成】

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登錄完成】

4. Auth2.0身份認證流程

oauth2.0定義了四個角色：客戶端client，資源所有者resource owner ，資源服務器resource server，授權服務器Authorization server。例如，用qq賬號登錄美團，美團是客戶端，我們用戶是資源的所有者，qq的用戶信息放在了資源服務器上，對賬戶授權的工作放在了授權服務器上。

1. 客戶端要求用戶給與授權。我們打開美團，選擇快速登錄。
2. 用戶同意授權給客戶端。我們選擇了用qq賬號快速登錄，同意授權給美團我們的用戶信息。
3. 客戶端拿到用戶給的授權，先授權服務器申請令牌。美團向qq的授權服務器發起申請。
4. 認證服務器對客戶端進行認證，確認無誤發放令牌。通常手機端會切換到qq端，驗證登錄狀態，提示是否授權，我們確認登錄之后，服務器發放令牌。
5. 客戶端使用令牌，申請資源。美團向qq申請用戶信息。
6. 資源服務器確認令牌無誤，同意開放資源。我們用qq的賬號登錄了美團，美團上顯示我們的qq昵稱、頭像等信息。

oauth2.0定義了四種授權類型：授權碼模式authorization code、簡化模式 implict、密碼模式resource owner password credentials 和 客戶端模式 client credentials。授權碼模式為功能最為完整，流程最為嚴密的授權，其他模式為授權碼模式的變體或簡化。

• Authorization code grant

  • part 1: The client will redirect the user to the authorization server with the following parameters in the query string:

    • response_type
    • client_id
    • redirect_uri
    • scope: "business" in our app.
    • state: a CSRF token. This parameter is optional but highly recommended. You should store the value of the CSRF token in the user’s session to be validated when they return.

  If authorized, client will get code and state.

  • part 2: The client will now send a POST request to the authorization server with the following parameters:
    • grant_type with the value of authorization_code
    • client_id
    • client_secret
    • redirect_uri
    • code

  If authorized, client will get

  • token_type this will usually be the word “Bearer” (to indicate a bearer token)
  • expires_in
  • access_token
  • refresh_token: can be used to acquire a new access token when the original expires

注意：client_id和client_secret是通過申請的，假如你要請求qq的oauth2.0服務，你得提前申請。如果是你自己的ouath服務，則需要在服務端對請求的client_id和client_secret驗證通過。client_id用於初始重定向，client_secret用於應用程序交換令牌的最后一步。

• Implicit grant:It is intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret because all of the application code and storage is easily accessible. The client will redirect the user to the authorization server with the following parameters in the query string:

  • response_type with the value token
  • client_id
  • redirect_uri
  • scope
  • state

  If authorized, client will get

  • token_type this will usually be the word “Bearer” (to indicate a bearer token)
  • expires_in
  • access_token
  • state

• Resource owner credentials grant：for trusted first party clients (client、resource server是一個公司出品). The client then sends a POST request with following body parameters to the authorization server:

  • grant_type with the value password
  • client_id
  • client_secret
  • scope
  • username
  • password

  If authorized, client will get

  • token_type
  • expires_in
  • access_token
  • refresh_token

• Client credentials grant: this grant is suitable for machine-to-machine authentication where a specific user’s permission to access data is not required. The client sends a POST request with following body parameters to the authorization server:

  • grant_type with the value client_credentials
  • client_id
  • client_secret
  • scope

• Refresh token grant

  • grant_type with the value refresh_token
  • refresh_token
  • client_id
  • client_secret
  • scope

  return same as the 2nd time of Authorisation Code Grant