ASP.NET 身份承載令牌與 JWT 的優缺點

Question

我已經使用 ASP.NET Identity 一段時間了，並且一直在研究 JWT（JSON Web 令牌），因為它們看起來非常有趣且易於使用。

JWT.IO有一個很好的例子/工具來調試令牌。

但是，我不完全確定 JWT 在后端是如何工作的，您還會使用 Identity 嗎？

另外令牌（Bearer vs JWT）如何比較？ 哪個更安全？

Answer 1

JWT 就像一張景點的門票。 它包含服務器需要嵌入其中的所有安全信息。 一旦服務器將它分發出去，客戶端只需要在它請求某些東西時呈現它，如果它有效，服務器就會相應地響應。

內容是完全可見的，但它們是由服務器使用密鑰簽名的，因此它可以判斷它們是否被篡改。

由於所有內容都在 JWT 中，並且客戶端可以將其呈現給他們想要的任何人，因此您可以將其用於單點登錄，只要不同的服務器共享相同的密鑰，以便它們可以驗證簽名。

與票證一樣，JWT 也有到期日。 只要它沒有過期，它就是有效的。 這意味着您不能在此之前撤銷它們。 出於這個原因，JWT 通常有很短的到期時間（30 分鍾左右），並且客戶端還會收到一個刷新令牌，以便在 JWT 到期時快速更新。

JWT

• 未存儲在服務器上
• 非常適合單點登錄
• 不能提前撤銷

不記名令牌就像客人名單。 服務器將客戶端放在來賓列表中，然后在它需要某些東西時提供一個密碼來識別它。 當客戶端提供代碼時，服務器在列表中查找它並檢查它是否可以執行它要求的任何操作。

服務器必須擁有可用的列表，因此如果您想跨服務器共享訪問權限，它們要么都需要能夠訪問列表（數據庫），要么與擁有該列表的某個權限（身份驗證服務器）交談。

另一方面，由於他們有客人名單，他們可以隨時將您從名單中刪除。

不記名令牌

• 存儲在服務器上
• 可以隨時撤銷
• 需要中央授權或共享數據庫來跨服務器共享令牌

如果你想沿着這條路走下去，Bit of Tech 有一些關於使用 Web Api 實現 JWT 的優秀教程。

http://bitoftech.net/2015/02/16/implement-oauth-json-web-tokens-authentication-in-asp-net-web-api-and-identity-2/

Answer 2

不幸的是，之前的答案可能會產生誤導：不記名令牌是 OAuth 2.0 中使用的主要訪問令牌類型。 Bearer Token 是一個不透明的字符串，對使用它的客戶端沒有任何意義。 一些服務器會發出由十六進制字符組成的短字符串的令牌，而其他服務器可能會使用結構化的令牌，例如JSON Web Tokens 。 ( https://oauth.net/2/bearer-tokens/ )

Answer 3

接受的答案是不正確的。

該問題討論了不記名令牌和 JWT 令牌作為兩種替代方案，而實際上它們各自描述了令牌中的不同方面，當今許多現代大型系統都使用 JWT 不記名令牌。

不記名令牌，顧名思義，是任何有權訪問它們的人（“持有者”）都可以用來訪問某個受限資源的令牌。

與不記名債券相比。 （未登記在特定所有者名下，而是屬於當前持有者的證券，可能被物理竊取甚至物理銷毀）

缺點

• 一個主要的缺點是它可能被任何有權訪問它的人在重放攻擊中重用。

防止這種情況的一種方法是創建只能訪問最低要求資源的令牌。 並設置一個相對接近的到期時間（這通常使用“exp”聲明來實現，如IANA JWT 規范中所定義）

優點

• 它們允許無狀態身份驗證器（您不必確保來自同一客戶端的每個調用都到達同一服務器實例），這對服務的體系結構具有巨大影響並防止身份驗證過程中的擴展限制。 （例如分配一致的服務器實例來處理每個客戶端）

JWT 令牌（代表 JSON Web 令牌）僅描述令牌的編碼格式。 （即一個 Json，使用 URL 安全編碼，如Base64URL ）

他們只字不提如何使用或由誰使用。 例如，服務器可能決定僅在采用一些額外的身份證明機制后才接受它們。 （這意味着這些代幣的持有者不一定會從他們那里獲得任何新的特權）

此外，與接受的答案聲明不同，JWT 令牌可能對客戶端不透明（使用某種加密），以防止客戶端暴露所聯系服務器的內部工作。 RFC 7516 中討論了這個想法。

優點

• JSON 是人類可讀的。

• Base64URL 編碼使調試更容易，甚至可以在 URL 中使用。

• JSON 解析很簡單、很常見，幾乎所有的編程語言都支持。 （使單獨編寫並基於不同堆棧的系統之間的互操作性變得更加容易）

缺點

• 文本編碼會產生比最低要求相對更長的標記。