放置API密钥的位置：自定义HTTP标头与自定义方案的Authorization标头

我正在设计一个通过API密钥使用授权/身份验证的REST API。

我试图找出最合适的位置，然后发现许多人建议使用自定义HTTP标头ProjectName-Api-Key，例如：

ProjectName-Api-Key: abcde

但在Authorization标头上使用自定义方案也是可能的，从思想上来说也是正确的，例如：

Authorization: ApiKey abcde

另一方面，我发现一个考虑，自定义授权方案可能出乎意料，并且不受某些客户端支持，并且无论如何都会导致自定义代码，因此最好使用自定义标头，因为客户对此没有任何期望。

您希望以哪种方式发送API密钥？

如果您使用授权，请保持一致

有人会争辩说以下内容是不必要的（不久前我会与他们达成一致），但是如今，如果我们使用Authorization标头，则应该告知令牌的类型，因为 API密钥如今本身并不是自描述的¹。

为什么我认为这是必要的，为什么我确实认为这很重要？因为如今支持不同的身份验证/授权协议已成为必须。如果我们计划使用Authorization标头用于所有这些协议，则必须使我们的身份验证服务一致。标头中也应包含通信方式，以发送我们发送哪种令牌以及应应用哪种授权协议。

Authorization: Basic xxxx
Authorization: Digest xxxx
Authorization: Bearer xxxx
Authorization: ApiKey-v1 xxxx
Authorization: ApiKey-v2 xxxx

我以前并不关心此事，但是在处理了无法保证更新的应用程序客户端应用程序（主要是手机和传感器）之后，我开始了。我开始对实现安全性的方式更加谨慎，这样我就可以扩展它而不会与客户端打扰，也不会给服务器带来太多麻烦。

顾虑

我实施自己的方案时遇到的问题与所评论的问题相似。

另一方面，我发现一个考虑因素是，自定义授权方案可能出乎意料，并且不受某些客户端的支持，并且仍然会导致自定义代码

说客户，说库，框架，反向代理。

优点

一项重要的优势是缓存。除非您另外声明，否则共享缓存不会缓存标头（这当然很好）。

那么授权还是自定义标题？

以我的经验，实现我自己的Authorization方案比实现自定义授权标头花了我很多（或更多）的工作，只是我使用自定义标头时有更多的设计自由和对缓存的更多控制。原因是相当愚蠢的，大部分时间我有Cache-control设置为 no-cache或no-store，使我可以使对服务器的调用更具确定性（这对于跟踪和测试很重要），而与网络的拓扑结构无关。

^{1：关于API密钥，我发现此答案非常清楚}