私は公開 REST API に取り組んでいます。登録されたクライアントには、API を使用するための API キーがサーバーから (ブラウザからではなく) 与えられます。単一のクライアントが複数のキーを持つこともでき、サーバー上の固有のアプリに使用される可能性があります。だから私は人々がAPIキーを検証する場所に興味があります...
Delegating Handler (通常は認証用) を使用して、鍵の検索を行います。
認証フィルターを使用して、キーが認証されているかどうかを確認します。
許可されていない場合は、400 - 不正なリクエストまたは 403 - 禁止 (キーが一時停止されている場合) を返したいです。
私の最初の考えは、キーはアクセスを許可するためのものであり、サービスを使用しているアプリを識別しないということです。しかし、Delegating Handler でキー検索を行うと、Authorization Filter が起動する Controller ではなく、(HTTP メッセージ Handler で) より迅速にショート サーキットできます。
API キーは、検証する資格情報であり、基本的には認証です。メッセージ ハンドラーは、プリンシパルの認証と設定に適していると思います。ハンドラーによって以前に確立された ID がその呼び出しを許可されている場合、パイプラインで後で実行される承認フィルターは承認できます。Thinktecture ID モデルのメッセージ ハンドラーに、共有キーを使用するhawk 認証を実装しました。ASP.NET Web API で ttidm と hawk を使用する方法の詳細については、こちらを参照してください。
メッセージ ハンドラーに関して注意すべき点がいくつかあります。メッセージ ハンドラーは、Web API パイプラインの早い段階で実行されますが、ASP.NET パイプラインでは比較的遅く実行されます (Web ホスティングを想定)。Web API ハンドラーで確立した ID は Web API のみに適用され、IIS/ASP.NET はそれについて何も知りません。ウェブホストのみを行うことがわかっている場合はHttpModule、より良い場所になります.
Web API 2 には、AuthenticationFilter があります。これについての詳細はわかりませんが、Dominick Baier が NDC 2013 でこれについて言及していると聞きました。OWIN を使用する予定がある場合、もう 1 つの候補は OWIN ミドルウェアです。