3

サーバー側でasp.netwebAPIを使用するアプリを構築していますが、検証に関する問題が発生しました。

ブラウザのjavascriptやWindowsPhoneなどのように、マルチプラットフォーム用のwebAPIを提供したいので、HTTP-BASICを使用して検証を暗黙的に行うことにしました。」（私の貧弱な英語を許してください）、問題は、過去時。

私は常にSESSIONでユーザー情報を取得しますが、RESTfulスタイルのwebAPIはセッションステートレスであることがわかっているため、ユーザー情報を保存する方法は次のとおりです。

そして、私はいくつかのアイデアを得る、私はあなたが私が正しい選択をするのを手伝ってくれることを願っています、たくさん

1.ユーザーのパスワードやその他の重要な情報を除いて、情報をブラウザのCookieに入れます。http-requestを実行するたびに、Cookieを取得します。サーバー側では、ユーザーの情報を照会し、他の手順を実行できます（シーケンスはmoblieプラットフォームでは機能せず、ブラウザーでのみCookieを使用します）

2.user HTTP-BASIC検証、およびサーバーがhttpRequestを取得するたびに、HTTP-Headersでユーザー名とパスワードを取得し、サーバー側もユーザーの情報を照会できます。

4

1 に答える 1

2

私が見たほとんどのRESTAPIは、次の2つの方法のいずれかで認証を処理します。

  1. HTTPヘッダー、基本認証、または資格情報を渡すためのいくつかのカスタムヘッダー。これがオプション2になります。これは、HTTPSを介して実行している場合にのみ非常に効果的です。これは、クレデンシャルがヘッダーにクリアテキストで表示されるためです。
  2. トークンのペアを使用します。1つは識別子（ユーザー名のようなもの）として、もう1つはクライアントとサーバー間の共有シークレット（パスワードのようなもの）です。次に、識別子、リクエストパラメータの一部、およびシークレットのハッシュが作成されます。次に、このハッシュと識別子がリクエストとともに送信されます。サーバーはシークレットを知っているので、同じメソッドを使用してハッシュを計算し、それらが一致することを確認します（Amazon Web Servicesは、OAuthを使用するすべてのものとともにこのメソッドを使用します）。

基本認証とは異なり、改ざんやリプレイ攻撃に耐性があるため、ここでは2番目の方法に移行しているWebAPIが増えているようです。もちろん、もっと複雑です。

OAuthのRFC5849セクション3.4は、乾式読み取り中に、ハッシュの作成に使用されるプロセスを通過します。必要に応じて、実装の開始点として適しています。C＃の基本的な実装は、OAuth Google Codeサイトで提供されており、最初から選択することをお勧めします。

于 2012-06-10T07:13:16.380 に答える