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

以前はこれを気にしませんでしたが、更新が保証されていないアプリクライアントアプリ（モバイルとセンサーがほとんど）を使用した後、始めました。クライアントをいじったり、サーバー側にあまり苦痛を与えたりせずにセキュリティを拡張できるように、セキュリティの実装方法にもっと慎重になり始めました。

懸念事項

自分のスキームを実装する際に直面した問題は、コメントされたものと似ています。

一方、カスタム認証スキームは予期せず、一部のクライアントではサポートされず、とにかくカスタムコードにつながる可能性があるという考慮事項を見つけました

セイのクライアントは、ライブラリ、フレームワーク、言うリバースプロキシを。

長所

1つの重要な利点はキャッシュです。共有キャッシュは、特に断りのない限り、ヘッダーをキャッシュしません（もちろんそれは良いことです）。

承認またはカスタムヘッダーですか？

私の経験では、独自のAuthorizationスキームを実装すると、カスタム認証ヘッダーを実装するよりも非常に同じ量（またはそれ以上）の作業が必要になりますが、カスタムヘッダーを使用した場合、設計の自由度が高くなり、キャッシュをより制御できるというわずかな違いがあります。その理由はかなり愚かで、ほとんどの場合、またはにCache-control設定し ているので、ネットワークのトポロジに関係なく、サーバーへの呼び出しをより確定的にすることができます（これは追跡とテストに関して重要です）。no-cacheno-store

^{1：APIキーに関してこの回答が非常に明確であると思います}