14

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

DotNetOpenAuth NuGet パッケージは既にダウンロードしていますが、これまでの例はすべて API ではなくクライアント アプリ用です。

私の問題は単純です。クライアントが認証リクエストを API に送信するようにしたいと考えています。API は OpenID プロバイダーで認証します。次に、API は、Web API 呼び出し全体で [Authorize] タグを使用するために必要なものを設定します。

.NET アプリケーションでは FormsAuthentication.SetCookie を呼び出すことができることは理解していますが、これは他の言語でも簡単に実装できますか?

一言で言えば質問。複数の言語で呼び出して使用できる Authorize タグを使用できるようにする MVC4 Web API に OpenID を統合するにはどうすればよいですか?

4

1 に答える 1

24

認証と承認の役割を混同している可能性があります。Web API には両方が必要なようです。

認可から始めましょう。すべての API (つまり、ブラウザー以外のクライアント アプリによってアクセスされる Web URL) は、匿名アクセスを許可するか、承認 (承認) する必要があります。認可はOAuthのドメインです。OAuth (おそらく v2) は、クライアントが WebAPI への呼び出しを承認する方法を記述します。

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

したがって、一度に 1 ステップずつ、シナリオ全体は次のようになります。

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

それが全体の話です。はい、クライアント ロールは、使用している言語やライブラリに関係なく簡単に記述できます。

ところで、私が参照している DotNetOpenAuth サンプルは、NuGet 経由で配布されていません。サンプルは SourceForge から取得します。

于 2012-09-03T21:21:07.837 に答える