2016-09-12 8 views
0

asp.net web apiでは、アクションまたはRESTエンドポイントを保護する場合、トークンベースのソリューションのような認証を使用します。しかし、APIのモバイルアプリクライアントがあれば、これは申し込みフォームがあるので、私はこのモバイルアプリだけが自分のAPIにサインアップリクエストを送り、他の偽のクライアント(POST-Manや-alike)にサインアップAPIをリクエストしますか?認証なしのセキュアWeb APIアクション

ベスト

+2

したがって、認証なしでモバイルアプリを認証しますか? :) (私が質問を正しく理解していれば、達成したいことはできません。モバイルアプリケーションであるクライアントをユーザーに提供しています。要求は誰でも偽造して送信できるデータの一部にすぎません)。 この要件のコンテキストは何ですか?なぜあなたのモバイルアプリへのサインアップを制限したいのですか?アプリケーションをどのような脅威から守っていますか?これらに答えることで、実際にうまくいく解決策を考え出すことができます。 –

+0

@lengyelg他のクライアントが私のAPIにリクエストを送ることはできません。相互偽造攻撃を防ぐ、MVCアプリでは、クッキーを使用して、他人がWebアプリケーションの外部にデータを投稿するのを防ぐようなものです。 –

+0

ええ、問題はcsrfの保護がブラウザの機能に依存していることです。また、csrfの保護によって別の種類のブラウザがアプリケーションにアクセスすることが阻止されるわけではなく、ここで達成しようとしているものと本質的に同じです。 Web世界で何を言っているのかは、あなたがブラウザを作ったということです。それはWebアプリケーションですが、ブラウザにアクセスできるようにしたいだけです。 –

答えて

1

これは、正確にトークンベースのシステムでカバーシナリオです。

あなたのモバイルアプリは単に独自の識別データを持つクライアントになり、APIはそのことを行い、認証されたアプリケーションからのリクエストのみを受け入れます。これはまさにあなた自身のOAuth2システムでカバーできるシナリオのようなものです。

は、この記事を見てください:https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/

それは、あなたのモバイルアプリはそのAPIにアクセスできることを保証します。

これはあなたの後ですか?

+0

まだ誰もが同じことをする別のアプリを作成することができます。この問題についての私の理解は、彼が自分のアプリをAPIと話すことができる唯一のものにしたいということでした。それは間違った要件です。そのため、実際のエンドゴールが何であるかを尋ねました。 もちろん、あなたの答えは、おそらくそうするべきだという意味で正しいです。 –

+0

したがって、リクエストを送信して自分のモバイルアプリとして自分自身を偽装することができるクライアントは、トークンをリクエストできます。私は偽のアプリケーション/クライアントにリクエストを送信したくない。私のすべてのAPのために固定のトークンを使用し、サインアップ要求のためにそのトークンだけを受け入れない限り。どう思いますか ? –

+0

あなたのアプリからそのトークンを抽出し、誰かが望むなら別のトークンで使用することができます。ユーザーに与えられているように、あなたはそれを保護することはできません。 –