ASP.NET身份承载令牌与JWT优点和缺点

Question

我已经使用了ASP.NET Identity一段时间了，并且一直在关注JWT（JSON Web Token），因为它们看起来非常有趣且易于使用。

JWT.IO有一个很好的调试令牌的示例/工具。

但是，我不完全确定JWT如何在后端工作，你还会使用身份吗？

令牌（Bearer vs JWT）如何比较？哪个更安全？

Answer 1

JWT就像是一个景点门票。它包含服务器需要嵌入其中的所有安全信息。一旦服务器将其发送出去，客户端只需要在需要时提供它，服务器就会相应地响应它是否有效。

内容完全可见，但它们是由服务器使用密钥签名的，因此它可以判断它们是否已被篡改。

由于所有内容都在JWT中，并且客户端可以将其呈现给他们想要的任何人，只要不同的服务器共享相同的秘密，就可以将其用于单点登录，以便他们可以验证签名。

像机票一样，JWT有一个到期日。只要它没有过期，它就是有效的。这意味着你不能在此之前撤销它们。因此，JWT通常具有较短的到期时间（30分钟左右），并且客户端还会发出刷新令牌，以便在JWT到期时快速续订。

<强> JWTs

• 未存储在服务器上
• 非常适合SSO
• 不能过早撤销

持票人令牌就像客人名单。服务器将客户端放在访客列表上，然后提供密码以在需要时识别它。 当客户端提供代码时，服务器在列表中查找它并检查它是否允许执行它所要求的任何内容。

服务器必须具有可用的列表，因此如果要跨服务器共享访问权限，则他们要么都需要能够访问列表（数据库），要么与拥有它的某个权限进行通信（auth服务器）

另一方面，由于他们有客人名单，他们可以随时将你带走。

承载代币

• 存储在服务器上
• 可以随时撤销
• 需要中央机构或共享数据库才能跨服务器共享令牌

如果你想沿着这条路走下去，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使用的主要访问令牌类型。承载令牌是一个不透明的字符串，不打算对使用它的客户有任何意义。某些服务器将发出一串十六进制字符串的令牌，而其他服务器可能会使用结构化令牌，例如 JSON Web令牌。 （https://oauth.net/2/bearer-tokens/）

Answer 3

接受的答案不正确。

该问题将承载令牌和JWT令牌作为两个替代方案进行了讨论，而实际上它们各自描述了令牌中的不同方面，当今许多现代大规模系统都使用JWT承载令牌。

顾名思义，

承载者令牌是任何有权访问它们的令牌（“承载者”）都可以用来访问某些受限资源。

与bearer bonds比较。 （不是在特定所有者下注册的证券，而是属于当前持有证券的任何人的证券，可能会被人偷走，甚至被人破坏）

缺点

• 一个主要缺点是，replay attack中的任何人都可以重用它。

防止这种情况发生的一种方法是创建仅访问最低要求资源的令牌。并设置相对接近的到期时间（通常使用IANA JWT spec中定义的“ exp”声明来实现）

专业人士

• 它们允许无状态身份验证器（您不必确保来自同一客户端的每个呼叫都到达相同的服务器实例），这对服务的体系结构产生了巨大影响，并阻止了扩展限制认证过程。 （例如，分配静态服务器实例来处理每个客户端）

JWT令牌（代表JSON Web令牌）仅描述编码令牌的格式。 （即Json，使用Base64URL之类的URL安全编码）

他们对使用方式或用途一无所知。例如，服务器可以在采用某些其他身份证明机制后决定仅接受它们。 （这意味着持有这些令牌并不一定会从中获得任何新特权）

此外，与公认的答案要求不同，JWT令牌对于客户端可能是不透明的（使用某种加密方式），以防止客户端暴露所联系服务器的内部工作。 RFC 7516中讨论了这个想法。

专业人士

• JSON是人类可读的。

• Base64URL编码使调试更加容易，甚至在URL中也可以使用。

• Json解析很容易，很普通，并且几乎所有编程语言都支持。 （使分别编写并基于不同堆栈的系统之间的互操作性更加容易）

缺点

• 文本编码产生的令牌比最低要求更长。