REST APIの認証の設計

私は、RESTサービス用のAPIを作成しています。これは、作成と消費の両方を行います。私は過去数日間、認証をうまく処理する方法を見つけようとして過ごし、最終的に何かを思いついたと思います。

アプリケーションスタックに関する次の事実に基づいて、これを考えています。

1. クライアントとサーバーは.NET4にあります（クライアントプロファイルのクライアント部分）
2. サーバーはWCF RESTを使用して公開します
3. アプリのユーザー名とパスワードをメモリに保持したくない

3から、トークン認証の形式を使用したかったため、サーバーによって資格情報が検証された後、クライアントはアプリの残りの部分で使用するトークンを取得します（これにより、ユーザーのタイムアウト、Webバージョンとデスクトップバージョン間でのシームレスなユーザーの移動など）。通話をリプレイし、改ざん防止する方法を考えた後、次のことを思いつきました。

1. クライアントは認証を試みる前に、ECDiffieHellmanCngクラスを使用してDiffie-Hellmanキーペアを生成します。
2. 鍵ペアの公開部分をユーザー名とパスワードとともに有線で送信します（もちろんHTTPS経由）。
3. サーバーはユーザー名とパスワードの組み合わせを認証し、成功した場合、次のことを行います。
   1. 一意のセッショントークンを作成します
   2. 独自のDHキーペアを生成し、クライアントから提供された公開キーから共有シークレットを計算します
   3. データベース内のセッショントークン、共有シークレット、ユーザー、および「最終アクション」時間（ローリング有効期限ウィンドウに使用）をメモします。
   4. セッショントークン、その公開DHキー、および認証成功メッセージを返します
4. クライアントは、応答からDHキーを取得し、共有シークレットを計算し、トークンとシークレットの両方をメモリに保存します。

この時点から、セッショントークン/シークレットの組み合わせは、他のほとんどのREST APIと同様に機能し、要求のフィンガープリントとタイムスタンプが付けられ、何らかのHMACが生成されます。クライアントがサーバーに対してアクションを実行するたびに、トークン/シークレットペアをチェックし、有効で期限切れでない場合はアクションを許可し、セッションの最後のアクションレコードを更新します。

明らかな欠陥は見当たらず、おそらくこのために過剰に設計されていますが、ある時点でこれを行う方法を学ぶ必要があります。HMACはリプレイ攻撃を防ぎ、DHネゴシエーションはMITM攻撃を防ぐのに役立ちます（HMAC / DHの間で頭の上の実行可能な攻撃を考えることはできません）。

誰でもこれを突くことができる穴はありますか？

独自に開発するのではなく、OpenAM APIを読んで借りることを検討する必要があります。

http://forgerock.com/openam.html

OpenAM Wikiは特に役立ちます

https://wikis.forgerock.org/confluence/display/openam/Home

それらのコンポーネントを使用する必要はありません。しかし、それらのAPIを使用すると、長期的にはあなたの人生がよりシンプルになることがわかります。

@ S.Lottと100％同意します。別の代替手段であるWindows Azureアクセス制御サービス（ACS）を検討することをお勧めします。ACSには費用がかかりますが、非常に安く（10,000トランザクションで0.01ドル）、大量のインフラストラクチャが処理されます。WIFはクライアントで活用されます。

これは、標準ベース/クレームベースのソリューションでもあり、大流行です。WCFとRESTおよびACSを一緒に使用する方法に関するこの記事をご覧ください。

将来のことを考えているなら、これはあなたと共に成長するメカニズムでもあります-あなたはファイアウォールやパートナーなどの外側にモバイルアプリを持っているので。ファイアウォールの外側に依存関係が追加されるため、使用したくない場合でも、アイデアを確認してください。とても滑らか。

幸運を！-ビル