0

DNOA を使用する .Net MVC4 WebApi アプリと Spring Security を使用する Java アプリの間で、単純な 2 脚の OAuth1a 会話を実装しています。Delegating MessageHandler を実装して受信リクエストを検証する際に、DNOA はリクエストにトークンを含めることを主張しているようです。Spring 実装はトークンを必要としません。私の感じでは、.Net の実装は何らかの点で正しくありません。

これがハンドラーです。これは、トークンを使用して送信すると機能します。

TokenManager tokenManager = new TokenManager();
var requestW = new HttpRequestWrapper(HttpContext.Current.Request);
var sp = new ServiceProvider(Constants.SelfDescription, tokenManager, new NonceStore());
try
{
     var auth = sp.ReadProtectedResourceAuthorization(requestW);
     if (auth != null)
     {
            //verfy etc etc
     }
 catch(Exception)
 { //return UnAuthorized response }
 return base.SendAsync(request, cancellationToken);
}

このコードでは、UnauthorizedRequest を受け取ったことを示す ReadProtectedResourceAuthorization 呼び出しで例外が発生します。では、この流れはどのように見えるべきでしょうか? 私が見るほとんどすべては、このタイプのフローにはトークンは必要ないと言っていますが、DNOA はそれを主張しているようです。どんな洞察も高く評価されます。

4

1 に答える 1

1

あなたがやろうとしているのは、実際には 0-legged OAuth のようです(とにかく、私の用語では、あなたがやろうとしている OAuth の元の 3 つの足はありません)。少なくとも、あなたの説明から、あなたのアクセス トークンとアクセス トークン シークレットは空であり、コンシューマー キーとシークレットしかないことが分かります。

私の記憶が正しければ、DNOA は空のアクセス トークンをサポートしていません (OAuth 1 仕様では許可されていないため)。

あなたが試すことができる可能な代替手段：

  1. 空でない (ただし、必要に応じてハードコーディングされている) アクセス トークンとアクセス トークン シークレットを使用します。
  2. 代わりに、コンシューマ キーとコンシューマ シークレットをユーザー名とパスワードとして使用して、HTTPS 経由の基本認証を使用します。
  3. 別の OAuth 1 サービス プロバイダー ライブラリを使用します。
于 2012-09-29T21:57:56.290 に答える