大家好啊~昨天我們知道資料表與Model 之間透過ORM 的機制簡單了這兩個之間的使用與安全，並且也結合前天的CRUD來做練習

今天的話，就要來介紹JWT (身分驗證與機制)，他是一種使用Token的方式來驗證使用者的資料，它符合設計 RESTful API 時「Stateless 無狀態」原則：意味著每一次從客戶端向伺服器端發出的請求都是獨立的，使用者經驗證後，在伺服器端不會將用戶驗證狀態透過 Session 儲存起來，因此每次客戶端發出的請求都將帶有伺服器端需要的所有資訊，從客戶端發出給伺服器端的請求將帶有 JWT 字串表明身份

下面是整個JWT 的運作流程

JWT 結構

在其緊湊的形式中，JSON Web Tokens 由以點 ( .) 分隔的三部分組成它們是：Header、Payload、Signature因此，JWT 通常如xxxxx.yyyyy.zzzzz

Header

標頭通常由兩部分組成：令牌的類型，即 JWT，以及正在使用的簽名算法，例如 HMAC SHA256 或 RSA，然後這JSON 被Base64Url編碼以形成 JWT 的第一部分

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

令牌的第二部分是有效負載，其中包含聲明。聲明是關於實體（通常是用戶）和附加數據的陳述。索賠分為三種類型：registered、public、private claims，然後對有效負載進行Base64Url編碼以形成 JSON Web 令牌的第二部分

• registered
  這些是一組預定義的聲明，它們不是強制性的，但建議使用，以提供一組有用的、可互操作的聲明
• public
  這些可以由使用 JWT 的人隨意定義。但是為了避免衝突，它們應該在IANA JSON Web Token Registry中定義，或者定義為包含抗衝突命名空間的 URI
• private claims
  這些是為在同意使用它們的各方之間共享信息而創建的自定義聲明，既不是註冊聲明也不是公共聲明

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

• 補充說明

Signature

要創建簽名部分，您必須獲取編碼的標頭、編碼的有效負載、秘密、標頭中指定的算法，並對其進行簽名

例如，如果您想使用 HMAC SHA256 算法，簽名將通過以下方式創建：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

簽名用於驗證消息在此過程中沒有被更改，並且在使用私鑰簽名的令牌的情況下，它還可以驗證 JWT 的發送者就是它所說的那個人

網頁實作

從網頁可以知道在右邊三個格子哩，就會是我們上面所說的三種類型，右邊的話就是透過我們特定的編碼方式所得出來的Token

今天簡單的介紹了JWT 的格式與內容，明天的話就會來練習要怎麼在ASP.NET COER 內使用到JWT ，那今天就先到這裡我們明天見啦~～~