Identity Server 4 原理和實戰（完結）_----選看 OAuth 2.0 簡介(上)

https://www.yuque.com/yuejiangliu/dotnet/cg95ni



















表明資源全部者的憑據


 

受權 Authorization Grant

 

受權是一個表明着資源全部者權限的憑據，它能夠被客戶端應用來獲取 Access Token。

 

OAuth 2.0 裏面定義了 4 種類型的受權，分別是：

1. Auhtorization Code 受權碼
2. Implicit
3. Resource Owner Password Credentials
4. Client Credentials

 

OAuth 2.0 還定義了一個擴展機制以便自定義其它的受權類型。

 

用一句話描述「受權(Authorization Grant)就是獲取 Token 的方法」。

 

• Authorization Code

• • 使用受權服務器做爲客戶端和資源全部者的中介
  • 在受權服務器把資源全部者送回（重定向）到客戶端的時候帶着這個臨時的憑據 Authorization Code。它就表明着資源全部者委託給客戶端應用的權限
  • 在安全方面的一些優勢：

• • • 能夠對客戶端應用進行身份認證
    • Access Token 直接發送到客戶端應用，不通過資源全部者的瀏覽器，因此不會將其暴露給外界，包括資源全部者

• • 適合 ASP.NET Core MVC 這類服務器端的客戶端應用

• • • Access Token 直接發送到 Web Server，不通過用戶瀏覽器，不會暴露 Access Token

• Implicit

• • Authorization Code 的簡化版本
  • 針對瀏覽器內的客戶端應用，例如 Angular SPA
  • 沒有受權碼發回給客戶端應用的步驟，受權服務器直接把 Access Token 發回給了客戶端應用，因此在瀏覽器內能獲取到 Access Token
  • Implicit 受權確實能夠提升瀏覽器內應用的響應性和效率，畢竟它減小了往返的次數。可是方即可能會帶來風險，推薦儘可能使用 Authorization Code

• Resource Owner Password Credentials

• • 直接使用用戶的密碼做爲受權來得到 Access Token
  • 僅當用戶和客戶端間高度信任且其餘受權方式不可用時纔可使用這種受權方式
  • 這種憑據只應用於一次請求並用於交換 Access Token，避免客戶端存儲用戶的憑據（密碼）

• • • 經過交換一個長期有效的 Access Token 或使用 Refresh Token均可以達到這種效果

• Client Credentials

• • 受保護資源並不屬於任意一個用戶（沒有用戶對該資源負責），但客戶端任需訪問受保護資源

• Device Code
• Refresh Token

• • 一般能從受權服務器得到兩個令牌：Access Token 和 Refresh Token
  • 當 Access Token 要過時時，咱們使用 Refresh Token 再獲取一個 Access Token