ASP.NET Web API フレームワークで構築された API を使用するモバイル アプリケーションに取り組んでいます。API を保護するメカニズムとして、ACS をカスタム STS と共に使用することにしました。独自の ID ストアに対してユーザーを認証する必要があるため、カスタム STS を使用しています。
情報の流れは次のとおりです。
- モバイル アプリは、ユーザー資格情報を使用してカスタム STS を呼び出します。
- ユーザーは、独自の ID ストアに対して認証されます。
- ユーザが認証されると、認証コードが ACS から取得され、SWT アクセス トークンの取得に使用されます。
- トークンはモバイル アプリに返されます。
- モバイル アプリは認証ヘッダーにアクセス トークンを埋め込み、API へのリクエストを発行します
- API の HTTP モジュールがアクセス トークンを検証し、トークンが有効な場合はデータが返されます。
oAuth 2.0 を使用しているため、すべて SSL 経由で行われます。
oAUth 2.0 の問題は、ACS によって発行された SWT トークンが生のトークンであり、いかなる方法でも暗号化されていないため、中間者攻撃の危険にさらされていることです。ただし、256 ビットの対称鍵を使用して署名されています。
http ベースのアプローチを使用しており、トークンが http 要求の認証ヘッダーにうまく適合するため、swt トークンを使用しています。
Microsoft は、次の投稿でいくつかの ACS セキュリティ ガイドラインを提供しています: http://msdn.microsoft.com/en-us/library/windowsazure/gg185962.aspx
現在、発行者とオーディエンスを確認するため、これらのうち 2 つを実装しています。つまり、トークンが信頼できる発行者 (ACS) によって発行され、トークンが正しいオーディエンス (API) に対して発行されたことを確認します。
私たちのシナリオは次の記事に基づいています: http://msdn.microsoft.com/en-us/library/hh446531.aspx そのような WIF は受信トークンの処理に使用されません。WIF は請求処理でのみ使用されます。
上記のシナリオを考えると、残りのベースの API を保護する必要がある実装を改善するために他にできることはありますか?
あらゆるコメント/批判/提案を歓迎します。
ありがとうございました。