什麼是Cookie、令牌與JWT？

在這篇博文中，我們將瞭解什麼是網路 Cookie 和令牌以及它們的用途。我們還將介紹最常見的網路 Cookie 和令牌型別。

什麼是 Cookie？
首先，讓我們嘗試瞭解什麼是網路 Cookie 以及我們如何使用它們。本文中的通用術語 Cookie 指的是網路 Cookie。

Cookie 是小型文字檔案這些 Cookie 由您訪問的網站（Web 伺服器）建立並儲存在您的裝置中。我們都遇到過它們。幾乎您訪問的每個網站都會使用 Cookie 橫幅“歡迎”您。Cookie 的用途取決於 Cookie 的型別以及網站希望 Cookie 執行的操作。例如，線上商店可以使用 Cookie 來跟蹤使用者在其網站上的活動、他們訪問的最後一個頁面、您選擇的語言、使用者檢視過的商品以及他放入購物車的商品。當使用者離開網站但稍後返回時，網站可以讀取 Cookie 並繼續使用者離開的地方。但並非所有 Cookie 都具有相同的用途。

我們為何需要 cookie？
因為 HTTP 是一種無狀態協議：HTTP 不會記住客戶端會話資訊，因此客戶端負責儲存該資訊 ，以前是使用 cookie。

對於某些網站，無狀態行為可能沒問題，也許網站在使用者會話期間不應該保留任何元素或使用者操作。

但對於大多數互動式網站，cookie 是必需且必不可少的，而且我們作為網站訪問者，也希望網站以某種方式執行。

非常感謝 cookie 使這一切成為可能。當客戶端從 Web 伺服器請求網站時，Web 伺服器會響應“200 OK”，並使用設定Cookie標頭。Cookie 包含會話 ID，通常還包含其他屬性。Web 伺服器還會跟蹤網站在伺服器端分發給客戶端的會話 ID。

Cookie 主要用於：

1. HTTP 會話管理
2. 個性化
3. 追蹤

Cookies 儲存在您的瀏覽器中。更確切地說，它們儲存在硬碟上的瀏覽器臨時目錄中。儲存 Cookie 的具體位置和方法取決於瀏覽器和作業系統。您通常透過進入設定透過瀏覽器介面管理 Cookie，但網際網路上提供了不同作業系統和瀏覽器的資料夾路徑。

Cookie 屬性
Cookie 具有屬性（有時也稱為標誌），這些屬性非常重要，因為它們定義了 Cookie 的工作方式。以下是 Cookie 可以具有的一些屬性的列表。

• 會話 ID是一個唯一的隨機字串，用於識別和匹配客戶端和 Web 伺服器之間的會話
• 過期定義 cookie 的過期日期
• 領域指定可以使用該 cookie 的一個或多個域
• 小路指定可以使用該 cookie 的資源或路徑
• HttpOnly啟用後將阻止 JavaScript 等客戶端 API 訪問 cookie。這可減輕跨站點指令碼 (XSS) 的威脅。
• 安全的啟用後將要求僅使用 HTTPS 傳送 cookie，而不允許使用 HTTP 等未加密的連線，這使得 cookie 不易受到竊取。
• 會議定義該 cookie 是臨時 cookie，當瀏覽器關閉時會過期
• 同一站點可以有嚴格、寬鬆或無值
  
  • 嚴格 = 瀏覽器僅向與原始域相同的目標域傳送 cookie
  • Lax = 瀏覽器向目標域傳送 cookie，即使它與原始域不同，但僅限於安全請求（如 GET），而不是第三方 cookie。
  • 無 = 允許第三方 Cookie（跨站點 Cookie）

Cookie 型別
以下是您在使用 Cookie 時可能會遇到的一些 Cookie 術語。

Cookie 可以以多種方式粗略地分為幾類：

• 有第一方 Cookie 和第三方 Cookie。
• 有基本 Cookie（嚴格必要）和非基本 Cookie（非必要）。

我們將在此處使用後一種定義來對 Cookie 進行分類。分類其實並不重要，人類只是更容易將東西放在心理框架中。

此外，有些 Cookie 只是其他 Cookie 的變體。例如，您可能聽說過“安全 Cookie”，但實際上它可能只是一個會話或第一方 Cookie，它具有安全的-attribute 已啟用。

即便如此，會話 cookie 和第一方 cookie 也非常相似。即使在我看來術語相當模糊，並且不同的網站交替使用不同的 cookie 術語，我們仍然至少嘗試對它們中的每一個給出某種定義。

必需 Cookie
基本 cookie 對於網站正常執行必不可少，並且通常可以為使用者帶來更便捷的瀏覽體驗。

• 會話 Cookie
• 第一方 Cookie
• 身份驗證 Cookie
• 以使用者為中心的安全 Cookie
• 使用者輸入的 cookies

會話 cookie （又稱非永續性 cookie、記憶體 cookie、臨時 cookie）
會話 Cookie 是臨時 Cookie 檔案，當使用者關閉瀏覽器或其會話變為非活動狀態（如果使用者登出，會話將結束）時，這些 cookie 會被刪除。它們是單會話 cookie。當使用者重新啟動瀏覽器並返回建立 cookie 的網站時，網站將無法識別使用者，因為使用者的瀏覽器中沒有網站可讀取的 cookie。使用者必須重新登入（如果網站需要登入）。登入後，將生成一個新的會話 cookie，它將儲存使用者的瀏覽資訊，並在使用者離開網站並關閉瀏覽器之前一直有效。由​​於會話 cookie 有自己唯一的 ID，因此它還可用於跟蹤網站訪問者數量。如果您正在計劃一次假期旅行，並且每天多次訪問旅行社的網站，則 cookie 的會話 ID 將向網站顯示您只是一位唯一訪問者。

第一方 Cookie （又稱永續性 Cookie、永久 Cookie、儲存 Cookie）
第一方 Cookie 將保留在瀏覽器中直到使用者刪除它們或瀏覽器刪除它們根據永續性 cookie 檔案中包含的持續時間。這種型別的 cookie 可以用其他術語來表示，例如永續性 cookie、永久 cookie 或儲存 cookie，因此它們在單個會話中具有永續性。如果在此期間未訪問該網站，大多數第一方 cookie 將在 1-2 年內過期。當 cookie 過期時，瀏覽器將自動刪除它們。第一方 cookie 最廣為人知的功能是幫助使用者保持其帳戶登入到網站，從而避免每次訪問網站時都需要重新輸入憑據。

身份驗證 Cookie
身份驗證 Cookie是會話 Cookie 的變體。它們登入成功後將識別使用者並在使用者瀏覽授權登入使用者訪問的網站時攜帶該身份驗證資訊。例如，當使用者透過網上銀行身份驗證時，他們有權檢視自己的銀行賬戶餘額。如果他們轉到另一個頁面檢視貸款，身份驗證 cookie 可確保使用者現在不必為該頁面提供新的身份驗證。

以使用者為中心的安全 Cookie
以使用者為中心的安全 Cookie可以跟蹤身份驗證錯誤並檢測可能的身份驗證濫用透過跟蹤在登入頁面上嘗試錯誤登入憑據的次數。

使用者輸入的 cookies
使用者輸入的 cookies是第一方會話 Cookie，跟蹤使用者自己輸入的操作和專案在網站上，例如填寫表格或單擊某些按鈕（例如新增到購物車）。

非必要的 Cookie
非必要的 cookie 對於使用者的瀏覽體驗或網站正常執行而言並非必需。

• 分析和定製 Cookie
• 廣告 Cookie
• 第三方 Cookie
• 超級cookie

分析和定製 Cookie
分析和自定義 cookie 會跟蹤使用者活動，以便網站管理員更好地瞭解其網站的使用情況。網站管理員可以使用分析來增強網站的一個例子是，網站上的某些資訊可能確實“冷門”，這意味著使用者很少開啟該頁面（不感興趣）或無法找到進入該頁面的方法。

廣告 Cookie
廣告 Cookie 僅用於定製使用者在網頁上看到的廣告。它們使用使用者的瀏覽歷史記錄使廣告“更相關”。這就是為什麼我們開始看到與我們之前搜尋過的內容相關的廣告。

第三方 Cookie（又稱跟蹤 Cookie）
第三方 Cookie 是壞人“cookieland” 的組成部分。這些是我們不喜歡的 cookie，也是它們聲譽不佳的原因。第三方 cookie 來自使用者訪問的不同域，因此它們不提供會話 cookie 或第一方 cookie 的任何好處。這些 cookies 只有一個目的：追蹤您。

超級cookie
從技術上講，超級 cookie 不是 cookie，在某些情況下不會儲存在使用者的裝置上。“普通” cookie 最多可以容納 4 KB 的資料，而超級 cookie 可以容納 100 KB。超級 cookie 的功能與跟蹤 cookie 類似，但它們的控制方式與其他 cookie 不同。在某些情況下，會發現超級 cookie 儲存在瀏覽器快取中，某些形式的超級 cookie 會注入僅由 ISP 控制的 UIDH（唯一識別符號標頭）中。由於超級 cookie 的性質，它們更難識別，如果是 UIDH 超級 cookie，您無法清除它們。

什麼是token？
token令牌是用於資訊交換的獨立且緊湊的 JSON 物件。典型的令牌是 JSON Web 令牌 (JWT)，用於客戶端（應用程式）和其他服務（如 Web 伺服器）之間。詳細資訊取決於確切的身份驗證流程。在本文中，我們將使用術語 JWT（發音為“JOT”），因為它更方便且在專業文獻中被廣泛使用。

與短期或長期儲存使用者在網路會話中的活動資訊的 cookie 不同，令牌在軟體之間傳輸資訊。儲存在令牌中的資訊取決於令牌的型別。例如，ID 令牌攜帶有關經過身份驗證的使用者的資訊。訪問令牌通常包含有關安全主體及其被授權的訪問許可權的資訊。這是 token 和 cookies 相交的地方：一些令牌儲存在客戶端的本地儲存或 cookie 中。出於安全原因，最好儲存在 HttpOnly cookie 中。我不是 Web 開發人員，但我瞭解到開發人員社群傾向於使用 cookie，因為本地儲存被認為是不太安全的選擇。還值得一提的是，令牌是協議的一部分，並非所有令牌都是同一協議的一部分。

簡要解釋的協議是OAuth 2.0和OpenID 連線（OIDC）

• 開放授權是 Open Authorization 的縮寫，它是一種標準，旨在處理代表使用者訪問資源的應用程式或網站的授權流程。簡而言之，OAuth 是一種主要用於 Web 平臺的授權協議。OAuth 使用訪問令牌，通常但不限於 JSON Web 令牌。Microsoft Identity Platform 中的 OAuth 協議使用格式化為 JWT 的訪問令牌（承載令牌）。OAuth 2.0 授權流程有多種不同型別。
• OpenID 連線擴充套件了 OAuth 2.0 授權協議，使其也可用作使用 ID 令牌的身份驗證協議。OpenID Connect 登入流程用於獲取 ID 令牌，該令牌被髮送到驗證使用者身份的應用程式。

令牌正在解決的問題
讓我們描述一個不存在令牌的傳統身份驗證和授權場景。

1. 使用者首先登入，然後 Web 伺服器透過從其資料庫中檢查輸入的憑據來對使用者進行身份驗證。
2. 一旦令牌匹配，伺服器就會發出一個唯一的會話識別符號並將其傳送到客戶端。
3. 使用者的客戶端將會話 ID 儲存在裝置上。對於從客戶端到伺服器的每個後續請求，會話 ID 都會在 cookie 或 http 請求標頭中傳送。
4. 伺服器需要再次從其資料庫中查詢會話 ID 以識別使用者並檢查授權級別。

上述場景的問題在於，對於來自客戶端的每個請求，伺服器都需要往返資料庫，這會使應用程式的使用速度變慢。

而使用令牌的場景透過釋出包含使用者資訊和簽名的 JWT 來解決後續的資料庫查詢問題，這些資訊和簽名可以驗證令牌內容的真實性。

• JWT 被髮送到客戶端，客戶端再次儲存它。
• 對於從客戶端到伺服器的每個請求，客戶端都包含 JWT。
• 伺服器只需要驗證令牌的簽名以確保其真實性，當簽名被簽入時，伺服器可以從令牌中提取身份和授權詳細資訊，而無需資料庫查詢。

令牌型別
以下是一些常見的 token 型別：

• ID 令牌
• 訪問令牌
• 重新整理令牌
• Bearer 令牌

ID 令牌
ID 令牌是使用 OpenID Connect (OIDC) 登入流程獲取的，該流程是去中心化身份驗證的開放標準。ID 令牌必須採用 JSON Web Token 格式。它們由授權伺服器 (Microsoft Entra ID) 頒發給客戶端應用程式。ID 令牌包含有關使用者的宣告或安全主體，並可以包含有關 MFA 狀態的宣告。客戶端應用程式可以使用 ID 令牌中的資訊和宣告來驗證使用者是否是他們聲稱的人。預設情況下，ID 令牌在 Microsoft Identity Platform 中有效期為一小時。ID 令牌不用於呼叫受保護的 API。

Microsoft 有兩個版本的 ID 令牌，並且都有不同的端點。版本之間的差異在於它們可以包含的資訊和宣告。

• v1.0https://login.microsoftonline.com/common/oauth2/authorize
• v2.0https://login.microsoftonline.com/common/oauth2/v2.0/authorize

訪問令牌
訪問令牌是由授權伺服器簽名的短期（JWT）令牌，並且使客戶端能夠安全地呼叫受保護的 Web API。訪問令牌不需要格式化為 JSON Web 令牌，但在 Microsoft Identity Platform 中，它們採用 JWT 格式。訪問令牌包含在從客戶端到伺服器的每個 http 請求中。這通常透過使用“Bearer”架構的 http 請求中的 Authorization 標頭來實現。這樣做將避免伺服器在每個請求上對使用者進行身份驗證的需要。客戶端將訪問令牌儲存在 cookie 或本地儲存中。與 ID 令牌一樣，訪問令牌也有兩個版本，它們都有不同的端點。訪問令牌旨在在伺服器端使用。客戶端不需要也不應該用來讀取訪問令牌的內容。

重新整理令牌
重新整理令牌是通常與訪問令牌一起獲取。它是用於獲取新的訪問令牌當先前的訪問令牌過期時，新的重新整理令牌也會過期。在 Microsoft Identity Platform 中，重新整理令牌是加密的，其他人無法讀取。客戶端將訪問令牌儲存在 cookie 或本地儲存中。重新整理令牌的預設有效期為 90 天，單頁應用除外，其預設有效期為 24 小時。

Bearer 令牌
持有者令牌是指任何擁有令牌的人都可以使用的令牌。令牌持有者無需證明自己擁有加密金鑰。可以將其想象成酒店房間的鑰匙卡。如果您放錯了鑰匙卡，而其他人拿到了它，他們就可以使用它進入酒店房間，而無需證明自己是房間的合法所有者。

JSON Web 令牌 (JWT)
JSON Web Tokens 是用於在雙方之間安全地傳送資料的標準化物件。為了確保 JWT 的內容在傳輸過程中不會被更改或篡改，JWT 使用加密金鑰進行簽名。這需要重複：JWT 已簽名，未加密。簽名驗證資料的傳送者，而加密將資料從純文字轉換為密文，未經授權的接收者無法讀取。如果簽名的令牌內容在傳輸過程中發生更改，公鑰（用於簽名令牌的私鑰對）將無法再驗證簽名。強烈建議使用帶有 JWT 的 HTTPS 等協議來保護傳輸過程中令牌內容的機密性。

網際網路工程任務組（IETF）在RFC 7519中描述了 JWT 標準。
JSON Web Token由三部分組成：

• 標頭
• 有效載荷
• 簽名

標頭
通常，標題由兩部分組成，描述代幣型別和簽名演算法。

{
  <font>"alg": "HS256",
  "typ": "JWT"
}

有效載荷
有效載荷是包含所有實際資訊的部分

• "iss" = 發行人宣告。簽發人要求確定簽發 JWT 的委託人
• "sub" = 主體宣告。主體宣告標識 JWT 的主體
• "aud" = 受眾宣告。受眾宣告確定 JWT 的收件人
• "exp" = 過期時間宣告。過期宣告確定 JWT 在過期時間或過期時間之後不得被接受處理的過期時間
• "nbf" = 非之前宣告。NFB 申請用於確定 JWT 不可接受處理的時間。
• "iat" = Issued At Claim（在索賠時簽發）。Issued At claim（在索賠時簽發）標識 JWT 簽發的時間
• "jti" = JWT ID 索賠。JWT ID 索賠提供了 JWT 的唯一識別符號

{
  <font>"session": "ch72gsb320000udocl363eofy",
  "client_id": "YzEzMGdoMHJnOHBiOG1ibDhyNTA=",
  "response_type": "code",
  "scope": "introscpect_tokens, revoke_tokens",
  "iss": "bjhIRjM1cXpaa21zdWtISnp6ejlMbk44bTlNZjk3dXE=",
  "sub": "YzEzMGdoMHJnOHBiOG1ibDhyNTA=",
  "name": "John Doe",
  "aud": "https://login.microsoftonline.com/{tid}/oauth2/v2.0/authorize",
  "jti": "1516239022",
  "exp": "2024-05-17T07:09:48.000+0545"
}
}

簽名
標頭和有效載荷都是Base64Url編碼。要對令牌進行簽名，需要使用編碼的標頭和編碼的有效負載以及機密和簽名演算法來完成簽名。

HMACSHA256(
  base64UrlEncode(header) + <font>"." +
  base64UrlEncode(payload),
  secret)

概括
我們瞭解了什麼是 Cookie，以及瀏覽器和網站如何使用 Cookie 來增強瀏覽體驗。我們列出了 Cookie 的一些變體及其獨特特徵。我們還了解了什麼是令牌、JWT相關知識。