我有一个资源可以为用户生成令牌。我想添加选择令牌生成算法的可能性。
我不能更改请求结构，但可以添加一些带有算法名称的HTTP头信息。我的问题是选择哪个头信息？是否可以使用Accept？
我目前使用一个Accept-Token-Algorithm头信息来发送值如RS256和HS256。
2个回答
5
我的问题是选择哪个头文件？
你还应该考虑在请求中未出现所需标头时返回默认算法，并确保验证接收到的值。请参阅RFC 7518以获取每个用途的有效算法列表：
请查看此页面以了解如何选择JWT算法的详细信息。
Accept是否可行？这个目的没有标准头文件。如果客户端和服务器都同意使用Accept-Token-Algorithm，那似乎是一个合理的选择。更加描述性（也更冗长）的替代方案是Accept-Token-Signature-Algorithm（假设JWT实际上是JWS），以及Accept-Token-Encryption-Algorithm（针对JWE）。请记住，您的API取决于您为其提供的文档的质量，自定义标头对API消费者来说并不明显。因此，请确保您正确记录它。
你还应该考虑在请求中未出现所需标头时返回默认算法，并确保验证接收到的值。请参阅RFC 7518以获取每个用途的有效算法列表：
请查看此页面以了解如何选择JWT算法的详细信息。
- cassiomolin
1
如果您需要向请求添加自定义标头，请参见自定义HTTP标头：命名约定
话虽如此，我认为客户端没有选择签名算法的理由。签名选择应该由发出服务决定，并且应取决于对该服务可接受的安全权衡。
接受此令牌的API应该能够验证此令牌的签名。因此，消耗此令牌的API应该能够接受相同的加密算法，并且在颁发令牌时使用相应的公钥（或共享密钥）。
如果令牌的内容（有效负载）对中间方有用，则可以解码（base64），而无需了解用于签署密钥的加密算法。
如果令牌是为第三方服务（例如OAuth2协议）发行的，则该令牌应对这种参与者不透明。
- dral
1
感谢您的关注和努力，客户选择算法的原因是因为我们无法在某些服务上存储私钥，需要切换到非对称签名算法。两种令牌类型都将有效，并且可以在不进行额外请求的情况下进行验证。 - gabba
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接