现实情况是，如果其他进程可以访问您的进程内存或虚拟机的功能，那么游戏可能已经结束，因为您已经受到攻击。如果一个进程在这个级别有访问权限，它可能会获得其他信息，例如在获取令牌之前用于身份验证的初始凭据，或者只是修改结果以使令牌验证返回 true，而不管实际验证结果等。不要太关注很多关于极端的可能性。大多数妥协是通过更简单的漏洞利用或配置错误发生的，例如将私钥存储在文件系统上，该文件系统对您的 Web 服务器来说是全球可读和可访问的等。

管理密钥和机密的最佳方式在一定程度上取决于您的平台。一些平台提供关键管理框架，也许使用其中之一是合适的。

不要过分关注这是一个秘密密钥这一事实。实际上，它并不比您需要管理的其他凭据更重要。例如，您如何管理允许访问您的数据库的凭据？如果该解决方案对您的数据库足够好，那么它对于您的密钥可能就足够好了。如果不是，那么我会问它是否真的对您的数据库足够好。现实情况是，如果有人要破坏系统，那么他们这样做很可能是为了访问接口提供的任何数据/服务。在大多数情况下，这个底层服务或数据库也需要凭证和凭证管理，而这些才是王国的真正钥匙。

我认为最好使用一致的方法来管理您的应用程序所需的所有凭据，而不是将用于令牌创建/验证的密钥视为特别特殊。不要仅仅因为它涉及“关键”或“秘密”之类的词而过度思考解决方案。所有凭据都是敏感数据，需要以安全的方式进行管理。大部分错误是由于过度设计的复杂解决方案造成的，这些解决方案变得难以维护且容易出错。考虑使用现有的、已知的和经过测试的设施/框架的解决方案，例如keytool，钥匙链经理等。如果做不到这一点，请使用易于理解和维护的东西。像数据库这样简单的东西可能就足够了。避免将信息存储为常量或全局变量的解决方案，因为这可能变得难以维护，因为更改密钥现在意味着代码更改，现在您必须进行测试、进行更改管理并推广到生产等。

至于如何生成密钥，这将取决于您的环境以及您需要管理的风险类型/级别。根据经验，我总是对任何依赖“随机”的东西非常警惕。生成真正的随机值非常困难，而且通常对提高安全性没有任何帮助。事实上，后来被证明不是随机的随机性假设可以揭示模式，这反过来意味着能够预测未来值的可能性，当你谈论密钥时，这几乎总是一件坏事。在这种情况下，我认为随机性不会从安全角度为您带来太多好处，除非您处于系统管理员不知道密钥至关重要的环境中。同样地，除了给您的用户带来不便之外，定期更改密钥不太可能带来其他好处。每当您更改密钥时，所有当前发行的令牌都将失效。您可能需要考虑制定在员工离职或更改角色时更改密钥的策略，您甚至可以考虑在软件更新时更改密钥的策略等。
但是，每周左右虔诚地更换密钥不太可能在安全方面提供任何帮助。

请注意，上述内容并非适用于所有键。在某些情况下，需要非常小心地管理私钥 - 例如，根 CA 的私钥。并非所有的键都是平等的。您的管理方法需要与您需要防范的要求和风险相匹配。在 JWT 的情况下，您正在处理一个很大程度上封闭的生态系统 - 密钥用于生成/签名和验证令牌。目标是检测篡改，而不是保护机密。风险在于，如果有人获得密钥，他们可以创建伪造的令牌并未经授权访问您的服务。这最终意味着什么取决于服务。某人尝试这样做的程度还取决于基础服务及其感知价值。您为保护密钥所做的努力应该反映了威胁。