MVC4 Web APIにOpenIDを統合する方法

Question

MVC4を使用して複数のクライアントタイプで使用するWeb APIを作成しています。私は認証にOpenIDを使用したいと思います。

私はすでにDotNetOpenAuth NuGetパッケージをダウンロードしているが、これまでのすべての例のではなく、APIよりも、クライアントアプリケーションのためのものです。

私の問題は簡単です。クライアントにAPIに認証リクエストを送信させたいAPIはOpenIDプロバイダで認証されます。その後、APIは、Web API呼び出し全体で[Authorize]タグを使用するために必要なものを設定します。

私はFormsAuthentication.SetCookieが呼び出されることができることを、.NETアプリケーションであることを理解し、これも他の言語のために簡単に実装するソリューションですか？

一言で言えば、質問です。複数の言語で呼び出され、消費されるAuthorizeタグの使用を可能にするMVC4 Web APIにOpenIDを統合するにはどうすればよいですか？

Answer 1

認証と認可の役割が混乱する可能性があります。あなたのWeb APIにはの両方が必要なようです。。

認可から始めましょう。すべてのAPI（つまり、ブラウザ以外のクライアントアプリケーションによってアクセスされるウェブURL）は、匿名アクセスを許可するか、許可されなければなりません。承認はOAuthのドメインです。 OAuth（v2、おそらく）は、クライアントがWebAPIへの呼び出しをどのように許可するかを記述します。

おそらく認証プロセスの一部として、ユーザーがあなたのサービスにログインします。ユーザーにログインするこの手順は、認証です。そしてそれは認可と直交しています。 OpenID、ユーザー名/パスワード、X.509証明書などを使用してユーザーを認証するかどうかは、WebAPI呼び出しの承認方法とは関係ありません。言い換えれば、WebAPIのメソッドは、ユーザーがどのように認証されたかに気を付けるべきではありません（読んでください：OpenIDは何も関係しません）。彼らには認可フィルタが適用され、着信要求に対する認可を検証し、アクセスを許可したアカウントのユーザ名、アクセスレベル、認可されたユーザのIDなどのいくつかの情報に変換しますクライアントなど

だから、一度にステップ、全体のシナリオは、このような何か行くかもしれない：（さんはこのクライアントアプリは3日であることを簡単にするために仮定しましょう

1. サードパーティのクライアントアプリケーションを操作するユーザをあなたのWebAPIにユーザの名前でアクセスする必要がある機能を使用したいと考えています。
2. クライアントがWebAPIへの呼び出しを行う際、クライアントはユーザーの限定された偽装に対して承認を取得する必要があります。まず、サービスの認証エンドポイントへのOAuth 2リダイレクトから始めます。これがDotNetOpenAuthを使用して実装されている場合、WebServerClientクラスを使用できます。
3. 承認エンドポイントはOAuth 2認証サーバーの役割を満たしており、DotNetOpenAuthのAuthorizationServerクラスを使用します。最初に行うことは、要求に含まれるASP.NETフォーム認証Cookieがあるかどうかを確認することです。このクッキーは、ユーザーがあなたのブラウザにあなたのサービスに既にログインしているかどうか、もしあれば、そのユーザーが誰であるかについての自然な表示です。このクッキーを確認するのは、Controller.Userへの簡単な呼び出しです。認可エンドポイントは、クライアントアプリケーションではなくブラウザー/ユーザーに対する応答であるため、WebAPIではなくMVCです。そのようなクッキーがなく、Controller.Userがヌル（またはUser.Identity.IsAuthenticatedがfalse）であると仮定しましょう。このエンドポイントの実装方法については、OAuthAuthorizationServerサンプルを参照してください。
4. 承認エンドポイントは、完全に着信するOAuth 2認証リクエストURLを保持するクエリ文字列のredirectUrlパラメータを含むユーザーログインページへのリダイレクトで応答します。
5. あなたのユーザーログインページは、OpenID依存パーティとして機能するMVCエンドポイントです。このエンドポイントはDotNetOpenAuthのOpenIdRelyingPartyクラスを使用します。このエンドポイントには、OAuth 2や認証情報は何もありません。単にユーザーを認証するだけです。ユーザーの認証後、redirectUrl引数のURLにリダイレクトされます。これを行う方法は、OpenIdRelyingPartyMvcサンプルを参照してください。
6. この時点ではFormsAuthenticationクッキーが存在することを除いて、認証エンドポイントは前の手順を繰り返します。したがって、クライアントにユーザーのデータにアクセスする権限を与えるかどうかを尋ねるページをユーザーに表示します。ユーザーが「はい」をクリックします。 （注意：XSRFを実装し、このユーザー認証ページでクリックジャッキを緩和する）。
7. 許可エンドポイントはユーザーの肯定応答を処理し、AuthorizationServerを呼び出して許可レコードを作成し、その応答をクライアントに返します。この呼び出しの結果の1つは、認証コードを与えるクライアントへのリダイレクト応答の定式化です。
8. ブラウザは、認証コードを渡すクライアントアプリケーションのURLを取得しようとしています。次に、クライアントはWebServerClientクラスを使用してアクセストークン（通常はリフレッシュトークン）の認証コードを交換します。
9. クライアントアプリケーションは、HTTP認証ヘッダーにOAuth 2で取得したアクセストークンを含め、WebAPI URLを直接呼び出します。
10. WebAPIがOAuth2リソースサーバーの役割を満たし、着信OAuth 2アクセストークンを検証するためにWebAPIメソッドに適用する承認フィルタ属性は、DotNetOpenAuth ResourceServerクラスを使用して作業を行います。これを行う方法については、OAuthResourceServerサンプルを参照するか、さらにはDavid Christiansen's WebAPI sampleを参照してください。

これはすべての話です。そして、クライアントの役割は、使用している言語やライブラリに関係なく、簡単に書くことができます。

私が参照するDotNetOpenAuthサンプルは、NuGet経由では配布されません。あなたはget the samples from SourceForgeです。