JWT token 是如何认证的？
How is JWT token authenticated?
这让我很困惑：
因此，当用户登录时，他们将获得带有签名的 JWT 令牌。这个签名发生在 header+Payload+secret
现在用户有了令牌，他们可以访问受保护的资源。
JWT 如何知道令牌有效？由于此流程中服务器上没有存储任何内容，因此如何与签名进行比较？如果我使用 JWT 调试器，我可以创建一个同样有效的令牌。那么这部分是如何工作的呢？
最后一点让我很困惑。我到处都看到 "checks signature" 但没有人详细解释它。
JWT 根据服务器拥有的密钥创建客户端令牌。
JWT 的设计方式是在没有服务器拥有的密钥的情况下无法生成这些客户端令牌，因此每个密钥都是安全的，始终是秘密密钥是安全的。
服务器还使用密钥来验证客户端令牌是否有效，并且只有该密钥才能验证它。
这里有很多相当笼统的问题，所以我把它分解了一下...
- JWT 如何知道令牌有效而不是冒名顶替令牌？
当您向服务器提交请求时，JWT 会附加到该请求的 header。此 JWT 先前已由服务器提供（在身份验证时），通常存储在本地存储或 cookie 中，以保持会话。
然后可以使用 "jsonwebstoken" 程序包（服务器端）来确定令牌对特定资源的有效性。 JWT 包将解密令牌并比较其签名。这是通过比较秘密密钥来完成的，它永远不会暴露在客户端 这是一个可能使令牌无效或有效的变量。另一个可能是令牌到期是否超时。例如，如果攻击者窃取了其他人的令牌，他们可能会尝试将该令牌发送到您的服务器并冒充其他人。因此，最好有一个短的到期时间 15m - 1h
- 令牌如何对特定路由有效？
嗯，这就是变数无限的地方。 JWT 允许您在令牌中存储信息。例如，如果您有两个不同的用户组，您将在令牌中存储一个值 - 当它最初被签名时 - 说明用户是否属于特定用户组。例如userIsABuyer：false，或 userIsASeller：true。一个好的做法是编写一些中间件来拦截传入的每个请求并检查令牌是否有效。如果有效，您可以附加一个 header，例如 "authenticated: true"，并且为了进一步保护其他内部资源，您可以附加任意数量的 header。例如，"userIsABuyer: false"
https://www.youtube.com/watch?v=25GS0MLT8JU - 这是一段相当不错的视频，深入探讨了 JWT。
https://blog.hasura.io/best-practices-of-using-jwt-with-graphql/ - 一个很好的资源，还涵盖了在内存中存储令牌时处理前端应用程序中持久会话的问题
JWT（JSON Web 令牌）是一个 self-contained 访问令牌，这意味着它包含应用程序使用它所需的所有信息（即 JWT 声明）和验证它的服务器（即 JWT Headers & JWT 签名）。所有这些都在一个令牌中。
服务器通过询问这两个问题来验证 JWT。
Has the JWT been expired?
Has the JWT Payload been tampered?
第一个： 服务器查看 JWT Payload 中已注册的声明，例如“exp”（过期时间）、“iat”（发布于）声明，以确定 JWT 是否过期（或）不是。
有关完整注册声明的列表，请参阅 RFC 7519 here.
第二个： 服务器查看 JWT Header 注册声明“alg”（算法）以了解在 JWT 生成期间使用了哪种类型的散列。它使用相同的算法（但是，使用服务器自己的秘密）来验证 JWT 负载是否在此过程中被篡改。
希望澄清。
干杯，
内存
这让我很困惑：
因此，当用户登录时，他们将获得带有签名的 JWT 令牌。这个签名发生在 header+Payload+secret
现在用户有了令牌，他们可以访问受保护的资源。
JWT 如何知道令牌有效？由于此流程中服务器上没有存储任何内容，因此如何与签名进行比较？如果我使用 JWT 调试器，我可以创建一个同样有效的令牌。那么这部分是如何工作的呢？
最后一点让我很困惑。我到处都看到 "checks signature" 但没有人详细解释它。
JWT 根据服务器拥有的密钥创建客户端令牌。 JWT 的设计方式是在没有服务器拥有的密钥的情况下无法生成这些客户端令牌，因此每个密钥都是安全的，始终是秘密密钥是安全的。 服务器还使用密钥来验证客户端令牌是否有效，并且只有该密钥才能验证它。
这里有很多相当笼统的问题，所以我把它分解了一下...
- JWT 如何知道令牌有效而不是冒名顶替令牌？
当您向服务器提交请求时，JWT 会附加到该请求的 header。此 JWT 先前已由服务器提供（在身份验证时），通常存储在本地存储或 cookie 中，以保持会话。
然后可以使用 "jsonwebstoken" 程序包（服务器端）来确定令牌对特定资源的有效性。 JWT 包将解密令牌并比较其签名。这是通过比较秘密密钥来完成的，它永远不会暴露在客户端 这是一个可能使令牌无效或有效的变量。另一个可能是令牌到期是否超时。例如，如果攻击者窃取了其他人的令牌，他们可能会尝试将该令牌发送到您的服务器并冒充其他人。因此，最好有一个短的到期时间 15m - 1h
- 令牌如何对特定路由有效？
嗯，这就是变数无限的地方。 JWT 允许您在令牌中存储信息。例如，如果您有两个不同的用户组，您将在令牌中存储一个值 - 当它最初被签名时 - 说明用户是否属于特定用户组。例如userIsABuyer：false，或 userIsASeller：true。一个好的做法是编写一些中间件来拦截传入的每个请求并检查令牌是否有效。如果有效，您可以附加一个 header，例如 "authenticated: true"，并且为了进一步保护其他内部资源，您可以附加任意数量的 header。例如，"userIsABuyer: false"
https://www.youtube.com/watch?v=25GS0MLT8JU - 这是一段相当不错的视频，深入探讨了 JWT。
https://blog.hasura.io/best-practices-of-using-jwt-with-graphql/ - 一个很好的资源，还涵盖了在内存中存储令牌时处理前端应用程序中持久会话的问题
JWT（JSON Web 令牌）是一个 self-contained 访问令牌，这意味着它包含应用程序使用它所需的所有信息（即 JWT 声明）和验证它的服务器（即 JWT Headers & JWT 签名）。所有这些都在一个令牌中。
服务器通过询问这两个问题来验证 JWT。
Has the JWT been expired?
Has the JWT Payload been tampered?
第一个： 服务器查看 JWT Payload 中已注册的声明，例如“exp”（过期时间）、“iat”（发布于）声明，以确定 JWT 是否过期（或）不是。
有关完整注册声明的列表，请参阅 RFC 7519 here.
第二个： 服务器查看 JWT Header 注册声明“alg”（算法）以了解在 JWT 生成期间使用了哪种类型的散列。它使用相同的算法（但是，使用服务器自己的秘密）来验证 JWT 负载是否在此过程中被篡改。
希望澄清。
干杯，
内存