個々 のアカウントと ASP.NET Web API 2.2 でのローカル ログインを使用して Web API をセキュリティで保護します。Secure a Web API with Individual Accounts and Local Login in ASP.NET Web API 2.2

作成者Mike Wassonby Mike Wasson

サンプル アプリをダウンロードします。Download Sample App

このトピックでは、メンバーシップ データベースに対する認証に OAuth2 を使用して、web API をセキュリティで保護する方法を示します。This topic shows how to secure a web API using OAuth2 to authenticate against a membership database.

このチュートリアルで使用されるソフトウェアのバージョンSoftware versions used in the tutorial

Visual Studio 2013 で、Web API プロジェクト テンプレートを使用して認証用の 3 つのオプション。In Visual Studio 2013, the Web API project template gives you three options for authentication:

  • 個々 のアカウント。Individual accounts. アプリでは、メンバーシップ データベースを使用します。The app uses a membership database.
  • 組織のアカウント。Organizational accounts. ユーザーが Azure Active Directory、Office 365、またはオンプレミスの Active Directory の資格情報でサインインします。Users sign in with their Azure Active Directory, Office 365, or on-premise Active Directory credentials.
  • Windows 認証。Windows authentication. このオプションは、イントラネット アプリケーションのためのものでは、Windows 認証の IIS モジュールを使用しています。This option is intended for Intranet applications, and uses the Windows Authentication IIS module.

これらのオプションの詳細については、次を参照してください。 Visual Studio 2013 で ASP.NET Web プロジェクトの作成です。For more details about these options, see Creating ASP.NET Web Projects in Visual Studio 2013.

個々 のアカウントは、ユーザーにログインするための 2 つの方法を提供します。Individual accounts provide two ways for a user to log in:

  • ローカル ログインします。Local login. ユーザー登録サイトでは、ユーザー名とパスワードを入力します。The user registers at the site, entering a username and password. アプリは、メンバーシップ データベースにパスワード ハッシュを格納します。The app stores the password hash in the membership database. ユーザーがログインすると、ASP.NET Identity システムは、パスワードを検証します。When the user logs in, the ASP.NET Identity system verifies the password.
  • ソーシャル ログインします。Social login. ユーザーが Facebook、Microsoft、Google などの外部サービスを使ってサインインします。The user signs in with an external service, such as Facebook, Microsoft, or Google. アプリは引き続き、メンバーシップ データベースで、ユーザーのエントリを作成しますが、すべての資格情報を格納しません。The app still creates an entry for the user in the membership database, but does not store any credentials. 外部サービスにサインインして、ユーザーを認証します。The user authenticates by signing into the external service.

この記事では、ローカル ログイン シナリオ。This article looks at the local login scenario. ローカルおよびソーシャル ログインは、Web API は、要求の認証に OAuth2 を使用します。For both local and social login, Web API uses OAuth2 to authenticate requests. ただし、資格情報フローでは、ローカルおよびソーシャル ログイン異なります。However, the credential flows are different for local and social login.

この記事では、ユーザーがログインし、web API への認証済みの AJAX 呼び出しを送信できる簡単なアプリを紹介します。In this article, I'll demonstrate a simple app that lets the user log in and send authenticated AJAX calls to a web API. サンプル コードをダウンロードするここします。You can download the sample code here. リリース ノートでは、Visual Studio で最初からサンプルを作成する方法について説明します。The readme describes how to create the sample from scratch in Visual Studio.

サンプル アプリは、データ バインディングと jQuery AJAX 要求を送信するための Knockout.js を使用します。The sample app uses Knockout.js for data-binding and jQuery for sending AJAX requests. アドレスは、この記事の Knockout.js を把握する必要はありませんに、AJAX 呼び出しに注目しましょう。I'll be focusing on the AJAX calls, so you don't need to know Knockout.js for this article.

その過程を説明します。Along the way, I'll describe:

  • どのようなアプリケーションのクライアント側で実行します。What the app is doing on the client side.
  • サーバーで何が起きています。What's happening on the server.
  • 中央の HTTP トラフィック。The HTTP traffic in the middle.

まず、OAuth2 の用語を定義する必要があります。First, we need to define some OAuth2 terminology.

  • リソースします。Resource. 一部のデータを保護できます。Some piece of data that can be protected.
  • リソース サーバーします。Resource server. リソースをホストするサーバー。The server that hosts the resource.
  • リソース所有者します。Resource owner. このエンティティは、リソースにアクセスする権限を許可できます。The entity that can grant permission to access a resource. (通常はユーザーです。)(Typically the user.)
  • クライアント:リソースにアクセスするアプリケーション。Client: The app that wants access to the resource. この記事では、クライアントは、web ブラウザーが。In this article, the client is a web browser.
  • アクセス トークンします。Access token. リソースへのアクセスを許可するトークンです。A token that grants access to a resource.
  • ベアラー トークンします。Bearer token. 特定の種類のすべてのユーザーはことに、トークンを使用してプロパティを使用して、アクセス トークン。A particular type of access token, with the property that anyone can use the token. つまり、クライアントには、暗号化キーまたはベアラー トークンを使用するには、その他のシークレットが不要です。In other words, a client doesn't need a cryptographic key or other secret to use a bearer token. そのため、ベアラー トークンは、HTTPS 経由でのみ使用する必要があり、比較的短い有効期限があります。For that reason, bearer tokens should only be used over a HTTPS, and should have relatively short expiration times.
  • 承認サーバーします。Authorization server. アクセス トークンを提供するサーバー。A server that gives out access tokens.

アプリケーションは、承認サーバーとリソース サーバーの両方として機能できます。An application can act as both authorization server and resource server. Web API プロジェクト テンプレートでは、このパターンに従います。The Web API project template follows this pattern.

ローカルのログイン資格情報フローLocal Login Credential Flow

Web API を使用して、ローカル ログインのリソース所有者パスワードのフロー OAuth2 で定義されています。For local login, Web API uses the resource owner password flow defined in OAuth2.

  1. ユーザーは、クライアント名とパスワードを入力します。The user enters a name and password into the client.
  2. クライアントは、承認サーバーにこれらの資格情報を送信します。The client sends these credentials to the authorization server.
  3. 承認サーバーは、資格情報を認証し、アクセス トークンを返します。The authorization server authenticates the credentials and returns an access token.
  4. クライアントには保護されたリソースにアクセスするには、HTTP 要求の Authorization ヘッダーにアクセス トークンが含まれています。To access a protected resource, the client includes the access token in the Authorization header of the HTTP request.

選択すると個々 のアカウントWeb API プロジェクト テンプレートで、プロジェクトにはユーザーの資格情報を検証し、トークンを発行する承認サーバーが含まれます。When you select Individual accounts in the Web API project template, the project includes an authorization server that validates user credentials and issues tokens. 次の図は、Web API のコンポーネントの観点から、同じ資格情報フローを示します。The following diagram shows the same credential flow in terms of Web API components.

このシナリオでは、Web API コント ローラーは、リソース サーバーとして機能します。In this scenario, Web API controllers act as resource servers. 認証フィルター、アクセス トークンを検証して、 [Authorize] 属性を使用してリソースを保護します。An authentication filter validates access tokens, and the [Authorize] attribute is used to protect a resource. コント ローラーまたはアクションが持っている場合、 [Authorize] 属性は、すべての要求をそのコント ローラーまたはアクションを認証する必要があります。When a controller or action has the [Authorize] attribute, all requests to that controller or action must be authenticated. それ以外の場合、承認が拒否されていると、Web API は 401 (未承認) のエラーを返します。Otherwise, authorization is denied, and Web API returns a 401 (Unauthorized) error.

承認サーバーと両方への呼び出しの認証フィルター、 OWIN ミドルウェアOAuth2 の詳細を処理するコンポーネント。The authorization server and the authentication filter both call into an OWIN middleware component that handles the details of OAuth2. このチュートリアルの後半で詳しくデザインを説明します。I'll describe the design in more detail later in this tutorial.

未承認の要求を送信します。Sending an Unauthorized Request

最初に、アプリを実行し、をクリックして、 API の呼び出しボタンをクリックします。To get started, run the app and click the Call API button. 要求が完了したら、エラー メッセージが表示されます、結果ボックス。When the request completes, you should see an error message in the Result box. 要求が承認されていないため、要求は、アクセス トークンを含まないためにです。That's because the request does not contain an access token, so the request is unauthorized.

API の呼び出しボタン、AJAX 要求を送信します ~/api/値、Web API コント ローラーのアクションを呼び出す。The Call API button sends an AJAX request to ~/api/values, which invokes a Web API controller action. AJAX 要求を送信する JavaScript コードのセクションを次に示します。Here is the section of JavaScript code that sends the AJAX request. サンプル アプリですべての JavaScript アプリのコードは Scripts\app.js ファイルにあります。In the sample app, all of the JavaScript app code is located in the Scripts\app.js file.

// If we already have a bearer token, set the Authorization header.
var token = sessionStorage.getItem(tokenKey);
var headers = {};
if (token) {
    headers.Authorization = 'Bearer ' + token;
}

$.ajax({
    type: 'GET',
    url: 'api/values/1',
    headers: headers
}).done(function (data) {
    self.result(data);
}).fail(showError);

ユーザーがログインするまでは、ベアラー トークンがありません、要求に Authorization ヘッダーしたがってがありません。Until the user logs in, there is no bearer token, and therefore no Authorization header in the request. これにより、要求が 401 エラーが返されます。This causes the request to return a 401 error.

HTTP 要求を次に示します。Here is the HTTP request. (使用してFiddler HTTP トラフィックをキャプチャします)。(I used Fiddler to capture the HTTP traffic.)

GET https://localhost:44305/api/values HTTP/1.1
Host: localhost:44305
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Accept-Language: en-US,en;q=0.5
X-Requested-With: XMLHttpRequest
Referer: https://localhost:44305/

HTTP 応答:HTTP response:

HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/8.0
WWW-Authenticate: Bearer
Date: Tue, 30 Sep 2014 21:54:43 GMT
Content-Length: 61

{"Message":"Authorization has been denied for this request."}

ベアラーに設定するという課題に Www 認証ヘッダーが応答が含まれることに注意してください。Notice that the response includes a Www-Authenticate header with the challenge set to Bearer. サーバーは、ベアラー トークンを示すです。That indicates the server expects a bearer token.

ユーザーを登録します。Register a User

登録セクションで、アプリの電子メールとパスワードを入力し、クリックして、登録ボタンをクリックします。In the Register section of the app, enter an email and password, and click the Register button.

このサンプルでは、有効な電子メール アドレスを使用する必要はありませんが、実際のアプリは、アドレスを確認します。You don't need to use a valid email address for this sample, but a real app would confirm the address. (を参照してくださいログイン、電子メールの確認とパスワードのリセットをセキュリティで保護された ASP.NET MVC 5 web アプリを作成)。パスワードを大文字、小文字、番号、および英数字以外の文字を"Password1!"、ようなものを使用します。(See Create a secure ASP.NET MVC 5 web app with log in, email confirmation and password reset.) For the password, use something like "Password1!", with an upper case letter, lower case letter, number, and non-alpha-numeric character. クライアント側の検証を残しましたをアプリをシンプルにするため、パスワードの形式に問題がある場合は、400 (Bad Request) のエラーが表示されます。To keep the app simple, I left out client-side validation, so if there is a problem with the password format, you'll get a 400 (Bad Request) error.

登録ボタン ~/api/Account/Register に POST 要求を送信する/。The Register button sends a POST request to ~/api/Account/Register/. 要求本文は、ユーザー名とパスワードを保持する JSON オブジェクトです。The request body is a JSON object that holds the name and password. 要求を送信する JavaScript コードを次に示します。Here is the JavaScript code that sends the request:

var data = {
    Email: self.registerEmail(),
    Password: self.registerPassword(),
    ConfirmPassword: self.registerPassword2()
};

$.ajax({
    type: 'POST',
    url: '/api/Account/Register',
    contentType: 'application/json; charset=utf-8',
    data: JSON.stringify(data)
}).done(function (data) {
    self.result("Done!");
}).fail(showError);

HTTP 要求:HTTP request:

POST https://localhost:44305/api/Account/Register HTTP/1.1
Host: localhost:44305
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Content-Type: application/json; charset=utf-8
X-Requested-With: XMLHttpRequest
Referer: https://localhost:44305/
Content-Length: 84

{"Email":"alice@example.com","Password":"Password1!","ConfirmPassword":"Password1!"}

HTTP 応答:HTTP response:

HTTP/1.1 200 OK
Server: Microsoft-IIS/8.0
Date: Wed, 01 Oct 2014 00:57:58 GMT
Content-Length: 0

この要求が処理、AccountControllerクラス。This request is handled by the AccountController class. 内部的には、 AccountController ASP.NET Identity を使用して、メンバーシップ データベースを管理します。Internally, AccountController uses ASP.NET Identity to manage the membership database.

Visual Studio からアプリをローカルで実行する場合、ユーザー アカウントが AspNetUsers テーブルに、LocalDB に格納されます。If you run the app locally from Visual Studio, user accounts are stored in LocalDB, in the AspNetUsers table. Visual Studio でのテーブルを表示する] をクリックして、ビューメニューの [サーバー エクスプ ローラーの順に展開データ接続します。To view the tables in Visual Studio, click the View menu, select Server Explorer, then expand Data Connections.

アクセス トークンを取得します。Get an Access Token

これまでに実行していない任意の OAuth でも、これで今回はアクションで、OAuth 承認サーバー アクセス トークンを要求するとします。So far we have not done any OAuth, but now we'll see the OAuth authorization server in action, when we request an access token. ログでサンプル アプリでの領域は電子メール アドレスとパスワードを入力しをクリックしてログでします。In the Log In area of the sample app, enter the email and password and click Log In.

ログでボタンは、トークン エンドポイントに要求を送信します。The Log In button sends a request to the token endpoint. 要求の本文には、次の形式で url でエンコードされたデータが含まれています。The body of the request contains the following form-url-encoded data:

  • grant_type: "password"grant_type: "password"
  • ユーザー名:<ユーザーの電子メール アドレス>username: <the user's email>
  • パスワード:<パスワード>password: <password>

AJAX 要求を送信する JavaScript コードを次に示します。Here is the JavaScript code that sends the AJAX request:

var loginData = {
    grant_type: 'password',
    username: self.loginEmail(),
    password: self.loginPassword()
};

$.ajax({
    type: 'POST',
    url: '/Token',
    data: loginData
}).done(function (data) {
    self.user(data.userName);
    // Cache the access token in session storage.
    sessionStorage.setItem(tokenKey, data.access_token);
}).fail(showError);

要求が成功すると、承認サーバーは応答本文でアクセス トークンを返します。If the request succeeds, the authorization server returns an access token in the response body. API に要求を送信するときに後で使用する、セッションの記憶域にトークンを保存したことに注意してください。Notice that we store the token in session storage, to use later when sending requests to the API. (Cookie ベースの認証の場合) などの認証の一部のフォームとは異なり、ブラウザーは自動的に含まれないアクセス トークン後続の要求で。Unlike some forms of authentication (such as cookie-based authentication), the browser will not automatically include the access token in subsequent requests. アプリケーションする必要があります明示的に行います。The application must do so explicitly. 制限するためには良いことだいるCSRF の脆弱性します。That's a good thing, because it limits CSRF vulnerabilities.

HTTP 要求:HTTP request:

POST https://localhost:44305/Token HTTP/1.1
Host: localhost:44305
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://localhost:44305/
Content-Length: 68

grant_type=password&username=alice%40example.com&password=Password1!

ユーザーの資格情報が要求に含まれることを確認できます。You can see that the request contains the user's credentials. する必要がありますトランスポート層セキュリティを提供する HTTPS を使用します。You must use HTTPS to provide transport layer security.

HTTP 応答:HTTP response:

HTTP/1.1 200 OK
Content-Length: 669
Content-Type: application/json;charset=UTF-8
Server: Microsoft-IIS/8.0
Date: Wed, 01 Oct 2014 01:22:36 GMT

{
  "access_token":"imSXTs2OqSrGWzsFQhIXziFCO3rF...",
  "token_type":"bearer",
  "expires_in":1209599,
  "userName":"alice@example.com",
  ".issued":"Wed, 01 Oct 2014 01:22:33 GMT",
  ".expires":"Wed, 15 Oct 2014 01:22:33 GMT"
}

読みやすくするためは、JSON をインデントされ、これは非常に長くアクセス トークンが切り捨てられます。For readability, I indented the JSON and truncated the access token, which is a quite long.

access_tokentoken_type、およびexpires_inプロパティは、OAuth2 仕様によって定義されます。その他のプロパティ (userName.issued、および.expires) は情報提供を目的用だけです。The access_token, token_type, and expires_in properties are defined by the OAuth2 spec. The other properties (userName, .issued, and .expires) are just for informational purposes. これらのプロパティが追加されているコードを検索することができます、 TokenEndpoint /Providers/ApplicationOAuthProvider.cs ファイル内のメソッド。You can find the code that adds those additional properties in the TokenEndpoint method, in the /Providers/ApplicationOAuthProvider.cs file.

認証された要求を送信します。Send an Authenticated Request

ベアラー トークンをしたら、API に認証された要求を実行できます。Now that we have a bearer token, we can make an authenticated request to the API. これは、要求に Authorization ヘッダーを設定して行います。This is done by setting the Authorization header in the request. をクリックして、 API の呼び出しボタンをもう一度参照してください。Click the Call API button again to see this.

HTTP 要求:HTTP request:

GET https://localhost:44305/api/values/1 HTTP/1.1
Host: localhost:44305
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Authorization: Bearer imSXTs2OqSrGWzsFQhIXziFCO3rF...
X-Requested-With: XMLHttpRequest

HTTP 応答:HTTP response:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/8.0
Date: Wed, 01 Oct 2014 01:41:29 GMT
Content-Length: 27

"Hello, alice@example.com."

ログアウトします。Log Out

ブラウザーでは、資格情報またはアクセス トークンをキャッシュしません、ためには、単にセッションの記憶域から削除することで、トークンを「忘れる」のログアウトです。Because the browser does not cache the credentials or the access token, logging out is simply a matter of "forgetting" the token, by removing it from session storage:

self.logout = function () {
    sessionStorage.removeItem(tokenKey)
}

個々 のアカウントのプロジェクト テンプレートを理解します。Understanding the Individual Accounts Project Template

選択すると個々 のアカウントASP.NET Web アプリケーション プロジェクト テンプレートで、プロジェクトが含まれます。When you select Individual Accounts in the ASP.NET Web Application project template, the project includes:

  • OAuth2 承認サーバーの場合は。An OAuth2 authorization server.
  • ユーザー アカウントを管理するための Web API エンドポイントA Web API endpoint for managing user accounts
  • ユーザー アカウントを格納するための EF モデル。An EF model for storing user accounts.

これらの機能を実装するアプリケーションのメイン クラスを次に示します。Here are the main application classes that implement these features:

  • AccountControllerAccountController. ユーザー アカウントを管理するためには、Web API エンドポイントを提供します。Provides a Web API endpoint for managing user accounts. Registerアクションは、このチュートリアルで使用した 1 つだけです。The Register action is the only one that we used in this tutorial. クラスの他のメソッドは、パスワードのリセット、ソーシャル ログイン、およびその他の機能をサポートします。Other methods on the class support password reset, social logins, and other functionality.
  • ApplicationUser、/Models/IdentityModels.cs で定義されています。ApplicationUser, defined in /Models/IdentityModels.cs. このクラスは、メンバーシップ データベース内のユーザー アカウントの EF モデルです。This class is the EF model for user accounts in the membership database.
  • ApplicationUserManager、/App で定義されている_からこのクラスの派生 Start/IdentityConfig.cs UserManagerパスワード、およびなどを確認する、新しいユーザーの作成などのユーザー アカウントに対して操作を実行し、自動的に保持データベースに変更します。ApplicationUserManager, defined in /App_Start/IdentityConfig.cs This class derives from UserManager and performs operations on user accounts, such as creating a new user, verifying passwords, and so forth, and automatically persists changes to the database.
  • ApplicationOAuthProviderApplicationOAuthProvider. このオブジェクトは、OWIN ミドルウェアに差し込むし、ミドルウェアによって発生したイベントを処理します。This object plugs into the OWIN middleware, and processes events raised by the middleware. 派生したOAuthAuthorizationServerProviderします。It derives from OAuthAuthorizationServerProvider.

承認サーバーを構成します。Configuring the Authorization Server

StartupAuth.cs では、次のコードは、OAuth2 承認サーバーを構成します。In StartupAuth.cs, the following code configures the OAuth2 authorization server.

PublicClientId = "self";
OAuthOptions = new OAuthAuthorizationServerOptions
{
    TokenEndpointPath = new PathString("/Token"),
    Provider = new ApplicationOAuthProvider(PublicClientId),
    AuthorizeEndpointPath = new PathString("/api/Account/ExternalLogin"),
    AccessTokenExpireTimeSpan = TimeSpan.FromDays(14),
    // Note: Remove the following line before you deploy to production:
    AllowInsecureHttp = true
};

// Enable the application to use bearer tokens to authenticate users
app.UseOAuthBearerTokens(OAuthOptions);

TokenEndpointPathプロパティは、承認サーバーのエンドポイントへの URL パス。The TokenEndpointPath property is the URL path to the authorization server endpoint. URL はそのアプリを使用してベアラー トークンを取得します。That's the URL that app uses to get the bearer tokens.

Providerプロパティは、OWIN ミドルウェアに接続して、ミドルウェアによって生成されるイベントを処理するプロバイダーを指定します。The Provider property specifies a provider that plugs into the OWIN middleware, and processes events raised by the middleware.

アプリがトークンを取得するときに次の基本的な流れに示します。Here is the basic flow when the app wants to get a token:

  1. アプリが要求を送信するアクセス トークンを取得するには、~/トークンです。To get an access token, the app sends a request to ~/Token.
  2. OAuth のミドルウェア呼び出しGrantResourceOwnerCredentialsプロバイダー。The OAuth middleware calls GrantResourceOwnerCredentials on the provider.
  3. プロバイダーの呼び出し、ApplicationUserManager資格情報を検証し、要求 id を作成します。The provider calls the ApplicationUserManager to validate the credentials and create a claims identity.
  4. 成功すると、プロバイダーは、トークンの生成に使用される認証チケットを作成します。If that succeeds, the provider creates an authentication ticket, which is used to generate the token.

OAuth のミドルウェアのユーザー アカウントについて何も認識します。The OAuth middleware doesn't know anything about the user accounts. プロバイダーは、ミドルウェア、ASP.NET Identity と通信します。The provider communicates between the middleware and ASP.NET Identity. 承認サーバーの実装の詳細については、次を参照してください。 OWIN OAuth 2.0 承認サーバーします。For more information about implementing the authorization server, see OWIN OAuth 2.0 Authorization Server.

ベアラー トークンを使用する Web API を構成します。Configuring Web API to use Bearer Tokens

WebApiConfig.Registerメソッドでは、次のコードは、Web API パイプラインの認証を設定します。In the WebApiConfig.Register method, the following code sets up authentication for the Web API pipeline:

config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));

HostAuthenticationFilterクラスは、ベアラー トークンを使用して認証を使用できます。The HostAuthenticationFilter class enables authentication using bearer tokens.

しないように SuppressDefaultHostAuthenticationメソッドが Web API、Web API パイプラインは、IIS または OWIN ミドルウェアのいずれかに到達する前に発生するすべての認証を無視するように指示します。The SuppressDefaultHostAuthentication method tells Web API to ignore any authentication that happens before the request reaches the Web API pipeline, either by IIS or by OWIN middleware. これにより、Web API のみベアラー トークンを使用して認証を制限できることです。That way, we can restrict Web API to authenticate only using bearer tokens.

Note

具体的には、アプリの MVC 部分は、cookie に資格情報を格納するフォーム認証を使用する可能性があります。In particular, the MVC portion of your app might use forms authentication, which stores credentials in a cookie. Cookie ベースの認証には、CSRF 攻撃を防ぐため、偽造防止トークンの使用が必要です。Cookie-based authentication requires the use of anti-forgery tokens, to prevent CSRF attacks. Web Api、問題の 1、偽造防止トークンをクライアントに送信する web API の便利な方法がないためにです。That's a problem for web APIs, because there is no convenient way for the web API to send the anti-forgery token to the client. (この問題の詳細については、次を参照してくださいWeb API での CSRF 攻撃の防止。)。呼び出すしないように SuppressDefaultHostAuthentication Web API が cookie に格納されている資格情報から CSRF 攻撃に対して脆弱でないことを確認します。(For more background on this issue, see Preventing CSRF Attacks in Web API.) Calling SuppressDefaultHostAuthentication ensures that Web API is not vulnerable to CSRF attacks from credentials stored in cookies.

クライアントが保護されたリソースを要求すると次 Web API パイプラインでの動作に示します。When the client requests a protected resource, here is what happens in the Web API pipeline:

  1. HostAuthenticationフィルターは、トークンを検証する OAuth ミドルウェアを呼び出します。The HostAuthentication filter calls the OAuth middleware to validate the token.
  2. ミドルウェアは、トークンを要求の id に変換します。The middleware converts the token into a claims identity.
  3. 要求は、この時点では、認証なく承認します。At this point, the request is authenticated but not authorized.
  4. 承認フィルターは、要求の id を検証します。The authorization filter examines the claims identity. クレームは、そのリソースに対してユーザーを承認する場合、要求を承認します。If the claims authorize the user for that resource, the request is authorized. 既定で、 [Authorize] 属性では、認証されたすべての要求を承認します。By default, the [Authorize] attribute will authorize any request that is authenticated. ただし、ロールまたはその他の要求を承認できます。However, you can authorize by role or by other claims. 詳細については、次を参照してください。 Web API で認証と承認します。For more information, see Authentication and Authorization in Web API.
  5. 前の手順が成功すると、コント ローラーは、保護されたリソースを返します。If the previous steps are successful, the controller returns the protected resource. それ以外の場合、クライアントは、401 (未承認) のエラーを受け取ります。Otherwise, the client receives a 401 (Unauthorized) error.

その他のリソースAdditional Resources