web-dev-qa-db-ja.com

APIキーを配置する場所：カスタムHTTPヘッダーVSカスタムスキームを使用したAuthorizationヘッダー

REST APIを使用して、APIキーを介した認証/認証を行います。

私はそれのための最良の場所を見つけ出そうとしたところ、多くの人々がProjectName-Api-KeyなどのカスタムHTTPヘッダーの使用を提案していることがわかりました。例：

ProjectName-Api-Key: abcde

しかし、カスタムスキームでAuthorizationヘッダーを使用することも可能であり、イデオロギー的に正しいです。例：

Authorization: ApiKey abcde

一方、カスタム認証スキームは予期せず、一部のクライアントでサポートされない可能性があり、いずれにしてもカスタムコードにつながる可能性があることを考慮しました。クライアントはそれについて何も期待していないため、カスタムヘッダーを使用することをお勧めします。

どの方法でAPIキーを送信しますか？

restapiauthenticationauthorizationheaders
25
RomanG

一貫している

これは不必要だと言う人もいるかもしれませんが（、それほど前までは同意しませんでしたが）、最近では、Authorizationを使用すると、非常に多くの認証プロトコルが使用されます APIキー を渡すためのヘッダー APIキー はそれ自体が自己記述的ではないため、 type にも通知する価値があります 1。

なぜ価値があると思いますか？今日では、さまざまな認証または承認プロトコルをサポートすることが必須になっているためです。これらすべてのプロトコルにAuthorizationヘッダーを使用する予定の場合は、認証サービスに一貫性を持たせる必要があります。送信するトークンの種類と適用する認証プロトコルを通信する方法もヘッダーに含める必要があります。

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

以前は気にしていませんでしたが、モバイルクライアントやセンサーを使用した後、どの更新が保証されないかを考え始めました。下位互換性を維持できるように、セキュリティの実装方法に一貫性を持たせるようになりました。トークンのタイプが通知されると、特定のクライアントのセット（古いもの）からのリクエストを無効にし、新しいスキームを追加して古いクライアントを新しいものと区別し、重大な変更を引き起こすことなく、1つまたは別のスキームの認証検証を変更できます。通知された承認スキームに基づいて、API Gatewayに特定のルールを適用することもできます。たとえば、古いスキームを、メインのスキームとは別にデプロイされているWeb APIの特定のバージョンにリダイレクトできます。

懸念

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

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

clientsと言って、ライブラリ、フレームワーク、 reverse proxies と言います。カスタムヘッダーは拒否または無視できます。さらに悪い場合には、衝突することもあります。

メリット

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

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

私の経験では、実装にはほとんど同じ作業と時間を費やしましたが、カスタムヘッダーを実装した場合は、設計の余地が少しあるというわずかな違いがあります。ただし、設計の余地が増えると、物事を複雑にする可能性も高まります。

技術的には2つの間にほとんどまたはまったく違いがない可能性がありますが、一貫性は、それが私に提供するもの、明確さと理解のために私が評価するすべてのソリューションの特性であることがわかりました。私の場合、新しいスキームの追加は、2つの新しい抽象化（同じ具象クラスによって実装）を追加するために削減されました：TokenHandlerおよびTokenValidator。ハンドラーは、要求ヘッダーAuthorizationがサポートされるスキームに通知するかどうかのみを確認します。 Validatorは、トークンを検証するために必要なものです。フィルターのチェーンや大きな泥の塊からではなく、単一のリクエストフィルターから完全に機能します。

1：私はこれを見つけます answer APIキーに関して非常に明確である

16
Laiv