我使用ASP.NET Identity已经有一段时间了，并且一直在研究JWT(JSON Web令牌)，因为它们看起来非常有趣且易于使用。
JWT.IO有一个很好的调试令牌的示例/工具。
然而，我不完全确定JWT在后端是如何工作的，你还会使用Identity吗？
代币(Bearer vs JWT)的比较情况如何？哪个更安全？
JWT就像一张景点门票。它包含了服务器需要嵌入的所有安全信息。一旦服务器分发了它，客户端只需要在请求时出示它，如果它有效，服务器就会相应地做出响应。
这些内容是完全可见的，但服务器会使用密钥对其进行签名，以便判断它们是否被篡改。
由于所有内容都在JWT中，客户端可以将其呈现给他们想要的任何人，因此只要不同的服务器共享相同的秘密，以便他们可以验证签名，就可以将其用于单点登录。
JWT和机票一样，也有有效期。只要它没有过期，它就是有效的。这意味着在此之前你不能撤销它们。由于这个原因，JWT的到期时间通常很短(30分钟左右)，并且客户端也会收到一个刷新令牌，以便在JWT到期时快速续订。
JWTs
- 未存储在服务器上
- 非常适合SSO
- 不能过早撤销
承载令牌就像一个访客列表。服务器将客户端放在访客列表中，然后提供一个通行码来识别它何时需要什么。当客户端提供代码时，服务器会在列表中查找它，并检查它是否可以执行它要求的任何操作。
服务器必须有可用的列表，所以如果你想在服务器之间共享访问权限，他们要么都能访问列表(数据库)，要么与拥有列表的某个权威机构(身份验证服务器)对话。
另一方面，由于他们有客人名单，他们可以随时把你从名单上删除。
持有者代币
- 存储在服务器上
- 可随时撤销
- 需要中央授权机构或共享数据库在服务器之间共享令牌
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/
不幸的是，前面的答案可能会产生误导：承载令牌是OAuth 2.0使用的主要访问令牌类型。Bearer令牌是一个不透明的字符串，对使用它的客户端没有任何意义。一些服务器会发布由十六进制字符组成的短字符串令牌，而其他服务器则可能使用结构化令牌，如JSON Web令牌。(https://oauth.net/2/bearer-tokens/)
接受的答案不正确。
该问题讨论了承载令牌和JWT令牌作为两种替代方案，而它们实际上都描述了令牌中的不同方面，并且当今许多现代大型系统都使用JWT承载令牌。
承载令牌顾名思义，是任何有权访问它们的人("承载者")都可以用来访问特定受限资源的令牌。
与无记名债券相比。(没有在特定所有者名下登记的证券，而是属于目前持有这些证券的人，并且可能被实际盗窃甚至销毁)
缺点
- 一个主要的缺点是，任何访问它的人都可能在重播攻击中重复使用它
防止这种情况的一种方法是创建只访问最低限度所需资源的令牌。并设置一个相对接近到期时间(这通常使用IANA JWT规范中定义的"exp"声明来实现)
优点
- 它们允许无状态验证器(您不必确保来自同一客户端的每个调用都到达同一服务器实例)，这对服务的体系结构产生了巨大影响，并防止了身份验证过程的扩展限制。(例如，分配一个一致的服务器实例来处理每个客户端)
JWT令牌(代表JSON Web令牌)仅描述令牌编码的格式。(即Json，使用URL安全编码，如Base64URL)
它们没有说明如何使用或由谁使用。例如，服务器可能在采用一些额外的身份证明机制后才决定接受它们。(这意味着这些代币的持有者不一定会从中获得任何新的特权)
此外，与公认的答案声明不同，JWT令牌可能对客户端不透明(使用某种加密)，以防止客户端暴露所联系服务器的内部工作。这个想法在RFC 7516中进行了讨论。
优点
-
JSON是人类可读的。
-
Base64URL编码使其更易于调试，甚至可以在URL中使用。
-
JSON解析简单、常见，几乎所有编程语言都支持它。(使单独编写并基于不同堆栈的系统之间的互操作性显著简化)
缺点
- 文本编码会产生比最低要求更长的令牌