jwt的思考

什么是jwt

jwt的问题

jwt的是实践

https://www.pingidentity.com/en/company/blog/posts/2019/jwt-security-nobody-talks-about.html

OpenID+JWTs

我们之前提到过JWT在OpenID Connect中的使用。提供者向客户机发出身份令牌。该身份令牌包含有关用户与提供者的身份验证的信息。身份令牌是JWT令牌，使用提供者的私钥签名。

OpenID Connect花了很大力气来改进身份令牌的安全属性。例如，协议要求使用“exp”、“iss”和“aud”声明。此外，该令牌包含一个nonce来防止重放攻击。由于这些要求，滥用被盗的身份令牌变得非常困难，甚至不可能。

JWTs作为OAuth 2.0的access token

OAuth 2.0访问令牌是JWT的另一个很好的用例。这样的访问令牌允许客户机应用程序访问受保护的资源，比如API。OAuth 2.0访问令牌有两种形式:引用令牌和自包含令牌。

• 引用令牌指向由授权服务器保存的服务器端元数据。引用令牌的功能类似于标识符，很像传统的会话标识符。
• 自包含的令牌以JWT的形式出现。它包含作为有效负载的所有元数据。为了保护数据，发布方使用私钥签署令牌。

传统的OAuth 2.0令牌是承载令牌。如果一个人受到伤害，它可以被任何拥有它的人无限制地使用。被破坏的引用令牌可由授权服务器撤消。对于自包含的令牌，撤销要复杂得多。

因此，强烈建议尽可能缩短访问令牌的生命周期。分钟或小时的令牌生存期非常常见。不建议使用天或月的寿命。如果可能，短期访问令牌应该与refresh令牌结合使用，以提高安全性。

此外，规范中新增的内容通过引入拥有证明机制来处理承载令牌属性。

作为会话对象的JWTs

OpenID Connect和OAuth 2.0等协议积极尝试解决JWTs的弱点。不幸的是，我们还观察到许多将JWTs合并到其体系结构中的应用程序，而没有考虑到这些预防措施。

一个具体的示例是一个使用JWTs在客户机上存储授权状态的应用程序。这支持使用无状态后端，这使部署变得非常容易。

然而，这样的客户端令牌是承载令牌。没有适当的短生命期或撤销机制使这种情况非常脆弱。

token的类型:

https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/

session与jwt共同使用:

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Stateless JWT: A JWT token that contains the session data, encoded directly into the token.
Stateful JWT: A JWT token that contains just a reference or ID for the session. The session data is stored server-side.
Session token/cookie: A standard (optionally signed) session ID, like web frameworks have been using for a long time. The session data is stored server-side.

https://cheatsheets.pragmaticwebsecurity.com/cheatsheets/jwt.pdf