私はパートナー企業が消費し、多数のクライアントに展開されるHTTP上で公開されるAPIに取り組んでいます。HTTP APIを保護する - ユーザーパスワードのプロンプトが表示されず、非公開鍵が公開されないようにする
場合によっては、クライアントはブラウザベースです。これは私の主な焦点ですが、クライアントがWindowsアプリケーションの場合と同じパターンを適用する可能性があります。私は、それがWindowsベースのアプリケーションとブラウザベースのアプリケーションの場合、クライアント上に秘密鍵を確保するための範囲が広いと感じています。そのため、通信は、パートナーアプリケーションによってレンダリングされたブラウザページから、私たちのAPIをホストするサーバーに行われます。
要するに、エンドユーザーに資格情報を要求することができず、各要求と共に渡される保存されたパスワード/キー/トークンに依存する必要があります。私の懸念は、パートナー企業がこのトークンをクライアント側のコードに焼き込むのを阻止することです。シナリオの概要を以下に示します。
- パートナーは私たちとアカウントを確立し（手動プロセス）、製品でAPIを消費するために必要な開発作業を行い、クライアントにロールアウトします。
- クライアントは製品を実行し、私たちとのアカウントを確立するウィザードを実行します。この時点でユーザー名とパスワードを要求することができますが、APIへの今後のすべての要求で実際のエンドユーザーに資格情報の入力を求められることはありません。
- その後、さまざまなユーザーコンテキストで多数のワークステーションでAPIを呼び出す無数のビジネスプロセスを実行します。私たちは個々のユーザー情報には関心がありません。私は現在、このAPIを確保するために働いていると、次が出ているステップ1をスキップして手順2と3
に集中するつもりだ、この質問の目的のために
デザイン：どこでも
- HTTPS（すべての要求は、SSL/TLSを使用）
- すべてのPOSTリクエストは、クライアントが作成したときにCSRFは、ステップ2では
- トークン利用アカウントにクライアント認証コードを提供します。パートナーは、この認証コードをサーバーに格納するようにアプリケーションをコーディングする必要があります。
- 今後APIを呼び出す前に、javascriptライブラリのInit関数を呼び出し、「GetAuthToken」のようなコールバックを提供します。
- 私たちのAPIを呼び出すたびに、Authトークンが（サーバー上に）あるかどうかを確認し、そうでなければエラーを返してコールバックを呼び出します。
- コールバックを実装するパートナーは、HTTPSを使用してトークンを取得するサーバーを呼び出す必要があります。この要求は通常の認証の対象となるため、ユーザーがシステムで認証されると認証トークンを取得できます。
- 認証トークンを受け取り、サーバーを呼び出して検証し、トークンを含むHTTPOnly Cookieを設定します。
- クッキーの有効期限が切れると、GetAuthTokenコールバックを再度呼び出します。
- クロスドメインの問題は、我々は、彼らがへのアクセス権を持っていると仮定し、ユーザは、その後、パートナーと認証された場合我々は、ここ連合安全保障の形を持っている取消認証トークン
を作ることができるのpostMessage
私はそれを複雑にしていますか？他の簡単なアプローチはありますか？いずれかのサイトがXSSに公開されているか、マルウェアによって侵害されている場合、少なくともベットはオフになっていますが、少なくとも秘密鍵をjavascriptまたはマークアップにレンダリングしないと、ユーザーはビューソースを右クリックして誰にでも秘密鍵を伝えることができません。
編集：この質問が見つかりました。一番上の回答は、WIFについて言及していますが、私はパートナに強制的に実装させたくない（Windowsを実行していないかもしれない）と述べています。まだ私のアプローチについてのフィードバックけれども...
クライアントのコンテキストに関する詳細を追加できますか？それはサーバーサーバーかブラウザからサーバーですか？ブラウザのように聞こえるが確かめたい。 – hoserdude
@hoserdude - ありがとう、私はクライアントのコンテキストに関するいくつかの説明を追加しました。それは私が主に心配しているサーバーへのブラウザです。 – tidmutt