3

私は、セキュリティ意識の高い大企業向けの REST API フレームワークを設計しています。

私たちのサービスへのすべての呼び出し元は、システムにアクセスするためのクライアント キーを提供する必要があります。これを使用して、その特定のクライアントのアクセスを承認し、レート制限と監視を行います。また、一部の API 呼び出しは顧客データにアクセスし、OAuth 2 トークンを使用してそのデータへのアクセスを制御します。

私の質問は、クライアントキーを渡す方法です。URI で渡すことができないため (URI がログに記録されることがあります)、HTTP 基本認証またはクエリ パラメーターを使用できません。代わりに、HTTP ヘッダーにある必要があります。だから私は2つのアプローチを考えましたが、どちらも欠陥があります:

(1) 独自のヘッダーを発明する: MyCompanyAPIKey: api-key-goes-here. これには欠陥があります。独自のヘッダーを発明する予定であり、それは設計上の選択として適切ではありません。他の人や標準ツールでは機能しません (独自に発明したため)。

(2) Authorization ヘッダーを使用しますAuthorization: Bearer api-key-goes-here。これは、OAuth (ヘッダーを必要とする) を使用する場合に競合するため、欠陥があります。技術的には、OAuth トークンがある場合はクライアント キーは必要ないと思いますが (OAuth トークンは単一のクライアントに固有のものであるため)、通常のツールでそれを処理できるかどうかはわかりません。

私たちはどのように進めるべきだと思いますか。

4

1 に答える 1

2

あなたの要件を考えると、カスタムヘッダーがここに行く方法のように思えます.

APIキーを渡す標準化された方法がないため、設計の選択が不十分であるという懸念はここでは関係ないと思います. API キーは、アプリケーションごとに異なる意味を持ちます。一部の人にとっては、それはユーザー ID です。他の人にとっては、それはパスワードです。他の人にとっては、明示的な認証さえ必要とされない場所での調整の手段に過ぎません。

互換性に関する限り、ほとんどのツールは API の操作に関してある程度の柔軟性を備えているため、おかしなことをしなければ問題ないと思います。何をするにしても、実装することを選択した標準で、それらを完全に実装し（OAuth対「OAuthのような」）、ドキュメントを提供するようにしてください。

于 2013-09-07T17:42:35.550 に答える