類型 修改 必須 back import googl further set 包裝

The Web API v2用戶認證模板提供了流行的應用用戶認證場景,如.使用本地帳號的用戶名密碼認賬 (包括創建用戶、設置和修改密碼)以及使用第三方的認證方式，如facebook，google等等– 在本地中包含了外部帳號的連接 所有的這些均通過使用一個OAuth2認證服務進行.

To make all that happen the template combines quite a bit of new stuff together: OWIN, Katana authentication middleware, ASP.NET identity, OAuth2 and a bunch of new authentication related attributes…and I must admit figuring out exactly

what’s going on was a bit of a challenge. Two quotes constantly came to mind while digging through the source code and writing down my notes. One was: complexity is the natural enemy of security – and the other one was: shit’s hard. So enjoy.

為了實現這些，模板集合了一些技術：OWIN、Katana認證中間件、ASP.NET 標識、OAuth2以及一些新的與認證相關的特性…,必須指出這是一個挑戰.

In this post I want to focus on the general setup of the Katana authentication middleware, the following posts will deal with the local account features and the external authentication.

In Katana, every authentication middleware “registers” itself with the system. For that it needs a “name” – or technically speaking an AuthenticationType

. Using that name, some code like a framework can call into the authentication component. This is done using theIAuthenticationManager interface which hangs off the Authentication property on theOwinContext. It features methods like SignIn, SignOut, AuthenticateAsync or Challenge. Each of these methods require an AuthenticationType as a hint which middleware will do the actual work.

在Katana中，每個認證中間件將自己註冊到系統中，因此它需要一個名字，或從技術上稱之為一個認證類型。使用這個名字，代碼會想一個框架一樣可以調用認證組件。使用IAuthenticationManager 接口在OwinContext中處理認證的屬性，方法如：SignIn，SignOut，AuthenticateAsync 或Challenge。每個方法需要哦一個認證類型作為指示其如何具體工作。

One built-in mechanism that uses the authentication manager is the newHostAuthenticationFilter in Web API v2 – will come to that later. Let’s first have a look which authentication middleware gets actually wired up (see also Startup.Auth.cs).

一個內建的機制使用認證管理器，在Web API V2中是newHostAuthenticationFilter。我們首先看認證中間件是如何連接的（參照Startup.Auth.cs）。

For the implicit flow and the interaction with Google and friends, “browser tech” is needed (think web views in native apps, or the browser itself for JS) – this is where cookies come in:

在隱式流程和與Google和朋友互動時，需要前端技術的支持（考慮本地App的Web頁面或者瀏覽器的JS）,即就是使用Cookie。

app.UseCookieAuthentication(new CookieAuthenticationOptions());

This call adds supports for classic cookie based authentication. The authentication type is simply called Cookies or in code the middleware is referenced usingCookieAuthenticationDefaults.AuthenticationType.

這個調用將增加對基於經典Cookie認證的支持。認證類型簡單的被稱之為Cookies或這在中間件中使用usingCookieAuthenticationDefaults.AuthenticationType.

app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);

The second cookie middleware registers itself as ExternalCookie (or DefaultAuthenticationTypes.ExternalCookie). This cookie is used to temporarily store information about a user logging in with a third party login provider

這個Cookie中間件將其自身作為一個ExternalCookie（或DefaultAuthenticationTypes.ExternalCookie）註冊到系統中。這個Cookie被用在為使用第三方登錄提供方的臨時存儲用戶登錄信息。

Further there is one authentication middleware registered for every external login provider you want to support (authentication types: Google, Facebook, Twitter and Microsoft):

你需要為想支持的每個外部登錄提供方註冊一個認證中間件(認證類型：Google、Facebook、Twitter以及微軟)：

app.UseFacebookAuthentication(appId: “178…455″,appSecret: “f43…f”);

app.UseGoogleAuthentication();

OK – next up is all the plumbing to support token-based authentication – we need a token producer and consumer. This is all hidden behind the following line of code:

好了，接下來是對基於令牌認證的支持，我們需要一個令牌生產者和消費者。這些都會被隱藏在下面代碼的中執行：

app.UseOAuthBearerTokens(OAuthOptions);

This extension method actually registers three middlewares behind the covers:

這個擴展方法實際上註冊了三個中間件：

1. OAuth2 authorization server to deal with resource owner flow and implicit flow token requests. Application specific logic is encapsulated in theApplicationOAuthProviderclass which we’ll have a closer look in the next post.

OAuth2認證服務器來處理資源所有者流程以及隱式令牌獲取流程。應用程序指定包裝ApplicationOAuthProviderclass 的邏輯，在下篇中我們會詳細的探討。

1. Token-based authentication for local accounts using an authentication type of Bearer(or OAuthDefault.AuthenticationType). This middleware only accepts claims where the issuer has been set to LOCAL AUTHORITY.

為本地帳號進行基於令牌的認證使用一種認證類型為Bearer的認證（或OAuthDefault.AuthenticationType）。這個中間件只接受發行人被設置為本地權限的claims（聲明）

1. Token-based authentication for external accounts (resulting from an authentication handshake with an external login provider). It uses an authentication type ofExternalBearer (or DefaultAuthenticationTypes.ExternalBearer) and only accepts claims where the issuer is not LOCAL AUTHORITY (important technical detail – keep that in the back of your mind).

對外部賬戶進行的基於令牌的認證（結果來自一個與外部登錄提供者的認證握手）。他使用認證類型為ofExternalBearer （或DefaultAuthenticationTypes.ExternalBearer）並只接受發行人不是本地認證的聲明（重要的技術細節）

With that setup you can now control which authentication type is required to access which parts of the API surface – let me give you some examples:

有了這些步驟，現在你便可以控制需要的認證類型來訪問API,例如

In general Web API requires token-based authentication using local accounts (Bearer). This is why you find the following two lines of code in WebApiConfig.cs:

一般WebApi需要使用本地帳號（Bearer）基於令牌的認證。這是為什麽需要在WebApiConfig.cs 文件中找到下面兩行代碼：

config.SuppressDefaultHostAuthentication();

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

Let’s say you’d want to also accept tokens resulting from external authentication – but require an authenticated principal, the following would work (e.g. on a controller or action):

你也可以從外部認證獲取令牌，但是需要一個認證原則，下面的代碼便可以工作（如一個控制器或動作）

[Authorize]

[HostAuthentication(DefaultAuthenticationTypes.ExternalBearer)]

If you want to override the global setting and only accept an application cookie if present (a technique used in the account controller – more on that in the next post) – you could do this:

如果你想覆蓋全局配置並只允許一個應用程序的Cookie，你可以這樣做：

[OverrideAuthentication]

[HostAuthentication(DefaultAuthenticationTypes.ExternalCookie)]

[AllowAnonymous]

翻譯：WebApi 認證--用戶認證Oauth解析