• 發行項

本文章是由機器翻譯。

技術最前線

ASP.NET MVC 4 中的社交驗證

Dino Esposito

如我所見的事情，大多數需要使用者進行身份驗證的 Web 網站將使用社會身份驗證閘道。在這方面，社會身份驗證閘道是僅僅公開通過 Twitter 和 Facebook 等最受歡迎的社交網路的身份驗證平臺。如果你覺得回到早期ASP.NET的你不能不注意到一些護照倡議背後的思想與今天的社會身份驗證閘道之間的相似性。他們當然不是同樣的事，但在這兩種方案中，您可以識別出使使用者的生活更容易通過減少的數量的憑據，他們必須不斷跟蹤的目標。

使用相同的憑據集有利弊。一方面它降低了圍繞您的隱私安全屏障。總是使用相同的使用者名和密碼，你給駭客更多的時間來猜猜你的秘密 ； 同時，你公開了更多的資訊，一次駭客攻擊。另一方面，雖然，反復使用相同的憑據使它更容易您連接並嘗試一下新的服務。為服務業主這是偉大，因為他們可以看到使用者數量的生長得更快，這意味著服務有更多的機會獲得成功。

總括來說，更多的和更多的網站，旨在吸引龐大的使用者群今天提供的雙選項註冊通過選擇您自己的憑據，或者通過社交網路的身份驗證閘道。趨勢是這樣有趣的在最新版本的ASP.NETMVC 4 你找到一個特設的框架，通過大量的社會網路的使用者進行身份驗證。在這篇文章中，我會檢討，你從ASP.NETMVC 4 專案範本的代碼。社會身份驗證閘道使用開放式身份驗證 (OAuth) 協定，原來是相當詳細的協定。因此，所產生的代碼並不是完全微不足道，可能需要一些進一步的解釋。

向 MVC 身份驗證的最快方法

ASP.NETMVC 讓您開始編碼從範本已經包含身份驗證的代碼的機會。你與ASP.NETMVC 4 的互聯網應用程式範本延伸到社會閘道的支援。然後，我們假設您有一個全新的互聯網應用專案。對第一次生成的代碼，將發生什麼特別。在頁圖 1 通知你已尚未啟用沒有外部身份驗證服務。


圖 1ASP.NETMVC 4 範本時沒有外部身份驗證服務配置

您可以通過更改一些輕 global.asax 代碼隱藏檔啟用的任何支援服務。ASP.NETMVC 4 建議，專案中包括一個 App_Start 資料夾與執行初始化任務的 xxxConfig 類。這樣的類是平原的容器，更好地組織應用程式的引導代碼的靜態方法。這裡是一個快照:

protected void Application_Start()
{  ...  AuthConfig.RegisterAuth();}

RegisterAuth 方法包含到讓的使用者日誌從 Facebook 和 Twitter 等其他網站使用其帳戶中的代碼：

public static class AuthConfig
{
public static void RegisterAuth()
  {
    OAuthWebSecurity.RegisterTwitterClient(
      consumerKey: yourTwitterAppKey
      consumerSecret: yourTwitterAppSecret);
    OAuthWebSecurity.RegisterFacebookClient(
      appId: yourFacebookAppKey,
    appSecret: yourFacebookAppSecret);
  }
}

OAuthWebSecurity 類來自于 Web 頁框架，坐落在 Microsoft.Web.WebPages.OAuth 命名空間中。當 DotNetOpenAuth (DNOA) 圖書館在實施此類環繞起來 OAuth 協定核心功能 （請參閱 dotnetopenauth.net)。

對社交網路的使用者進行身份驗證，您首先需要創建在社交網路應用程式。所以你需要一個 Twitter 應用程式和一個 Facebook 應用程式在您的網站內通過 Twitter 和 Facebook 的使用者進行身份驗證。最有可能就會創建一個 Twitter/Facebook 應用程式與您的網站的名稱相同，並配置它以連結到您的 Web 網站。什麼引用在這裡作為一個 Twitter/Facebook 應用程式不是一個成熟的應用程式 ； 此外，它有特殊的開發­oper 權杖以程式設計方式訪問 Twitter、 Facebook 和其它社交網路。在此列專用於 Facebook 程式設計的過去分期付款我涵蓋這方面相當深入。本文中，Twitter/Facebook 應用程式包含一對字串 — — 一個稱為金鑰和其他已知的作為秘密。唯一與社會應用程式相關聯的鍵和秘密。您通過傳遞金鑰初始化 OAuthWebSecurity 和秘密為每個社會網路你打算支援。

通過簡單地添加對 RegisterTwitterClient 和 RegisterFacebookClient 的調用，示例專案的使用者介面更改為顯示為按鈕這些註冊選項。如果使用者按一下登錄按鈕，她就會重定向到 Twitter/Facebook 網站以進行身份驗證。如果這一切工作正常她然後就會重定向到原始網站和承認的ASP.NET作為經過身份驗證的使用者。

聽起來很簡單的事，好嗎？很好，有很多的引擎蓋下細枝末節。

考慮到身份驗證的 OAuth 路線

當使用者按一下 Twitter 按鈕時該網站定位到帳戶/ExternalLogin。讓我們看一看 （代碼位於中的 AccountController.cs 檔） 的方法的代碼：

public ActionResult ExternalLogin(String provider, 
  String returnUrl)
{
  return new ExternalLoginResult(provider,
    Url.Action("ExternalLoginCallback",
    new { ReturnUrl = returnUrl }));
}

ExternalLoginResult 類是一種包裝，真的不會工作的聯繫，身份驗證閘道的以下代碼：

OAuthWebSecurity.RequestAuthentication(Provider, ReturnUrl);

ExternalLoginResult 類是也發現在 AccountController.cs 檔中的説明器類。 你應該注意到專案範本代碼中的提供程式名稱解決看名稱屬性的按鈕：

<button type="submit"
  name="provider"
  value="@p.AuthenticationClient.ProviderName"
  title="Log in using your @p.DisplayName account">
  @p.DisplayName
</button>

在一天結束，RequestAuthentication 方法接收的身份檢查器提供者 （Twitter、 Facebook 或任何其他受支援的供應商） 和 URL 返回的名稱。預設情況下，OAuthWebSecurity 支援下列提供程式：Twitter、 Facebook、 LinkedIn、 谷歌、 微軟和雅虎。在內部，該方法使用 DNOA 庫來執行該任務。讓我們看看會發生什麼如果使用者選擇通過 Twitter 進行身份驗證。

作為第一步，Twitter 的身份驗證的預設頁被顯示給使用者。頁包含的 Twitter 應用程式正在進行的任務的名稱 — — 它的在示例中所示的 tFun 圖 2。當您配置一個 Twitter 應用程式時，您還指示使用者需要登錄時應用程式授予的許可權。通過正確地配置社會應用程式你可以給ASP.NETWeb 網站跟隨新使用者或發佈代表已連接的使用者的許可權。這不是這種情況的應用程式範例。


圖 2 通過 Twitter 進行身份驗證

如果使用者輸入的憑據，Twitter （或選擇的社會網路） 確認為有效，Twitter 網站重定向回提供的返回 URL。你重新控制過去的身份驗證下一種方法是 ExternalLoginCallback。你知道此時才正試圖訪問您的應用程式的使用者已被成功地確認為 Twitter 使用者。你不知道什麼她，甚至不是她的使用者名。我幾乎不能想到的應用程式需要身份驗證的使用者，並可以幸福地忽略使用者名或電子郵件地址。回從身份驗證步驟，應用程式只接收代碼，但還沒有尚未被授權以程式設計方式訪問 Twitter API。對於這種情況發生，必須為一個訪問權杖 （通常時間限制，防止濫用) 交換收到在這一階段的代碼。這是給你找到體內的 ExternalLoginCallback 的 VerifyAuthentication 方法調用的目的。你從 VerifyAuthentication 回來的 AuthenticationResult 物件就帶來了一些有關使用者的資訊。你得到的實際資訊可能會略有不同，提供程式 ； 但是，它通常包含至少該使用者名。

從成員資格身份驗證

對使用者進行身份驗證只是第一步。下一步，您需要通過名稱網站內跟蹤該使用者。經典ASP.NET成員資格系統中你首先顯示一個登錄表單、 驗證憑據，然後再創建身份驗證 cookie 使用者名和其他關鍵資訊可選）。Twitter 或 Facebook 保存你的負擔安排一個登錄表單並驗證憑據，再加上非平凡的存儲和管理敏感資訊 （如密碼與帳戶負擔。

底線，雖然，是幾乎任何應用程式，需要驗證使用者還需要成員資格系統在每個普通使用者跟蹤的名稱。建立這樣一個體系仍然是你的責任。ASP.NETMVC 4 範本來拯救通過提供額外的步驟哪裡自動給予使用者輸入她的顯示名稱，然後保存到本地成員表的機會。這是必需只在使用者登錄到給定網站的首次。換句話說，在顯示的表單圖 3 加入登記和第一次登錄的目的。


圖 3 第一次登錄和完整登記到網站

在這一階段輸入的名稱用於創建ASP.NET身份驗證 cookie，絕對關閉圈子。你用 Twitter 來檢查憑據，要求使用者輸入她的顯示名稱和創建一個週期性身份驗證 cookie。從現在開始，一切都像往常一樣在工作ASP.NET對於需要身份驗證的網站。

預設ASP.NETMVC 4 專案範本將使用者資料保存到 App_Data 資料夾下創建一個.mdf 本機資料庫。表是使用網頁框架從繼承的簡單會員 API 來管理的。

下面的代碼演示的示例專案範本如何獲取的頁中的顯示名稱圖 3：

var loginData = OAuthWebSecurity.SerializeProviderUserId(
  result.Provider, result.ProviderUserId);
var name = OAuthWebSecurity
  .GetOAuthClientData(result.Provider)
  .DisplayName;
  return View("ExternalLoginConfirmation",
  new RegisterExternalLoginModel {
    UserName = result.UserName,
    ExternalLoginData = loginData
  });

對 GetOAuthClientData 的調用是在您訪問任何的 Twitter 供應商共用已登錄的使用者資訊。 在 ExternalLoginConfirmation 方法中兩個關鍵的事情發生，總結了下面的代碼：

OAuthWebSecurity.CreateOrUpdateAccount(provider, providerUserId, model.UserName);
OAuthWebSecurity.Login(provider, providerUserId, createPersistentCookie: false);

第一行設置為應用程式的成員資格本機資料庫中的新記錄。 第二條線實際創建身份驗證 cookie。 為資料庫表 UserProfiles 和 webPages_OAuth 等一堆提供了預設範本­成員資格。 後者表存儲一條記錄與該提供程式的名稱 （即，Twitter），供應商的唯一 ID 使用者和一個指標，指向的內部 ID 唯一地標識使用者在 UserProfiles 表中的顯示的名稱，使用者自己在中所示的頁面中選擇圖 3。

其他考量

OAuth 協定管理提供程式和一個用戶端應用程式之間的交互。 Twitter、 Facebook 和其他幾個受歡迎的社交網路公開其通過 OAuth 的 Api。 用戶端應用程式可以使用 Twitter API，兩個主要目的：普通使用者身份驗證和代表私下進行使用者操作對提供程式。 在這兩種情況下用戶端應用程式必須登錄到該提供程式，並得到一個訪問權杖。 訪問權杖中的時間有限的 （但可以以程式設計方式被刷新） 並被授權執行最終使用者批准她輸入憑據時的操作 （見圖 2）。 一旦應用程式包含一個訪問權杖，會發生什麼取決於應用程式的需要。 該標記可用於檢索的電子郵件地址，並將其存儲在特定于應用程式的成員資格系統中。 權杖還可以用於代表使用者發佈。 甚至當使用者斷開連接從 TwitterASP.NET身份驗證 cookie 仍然有效。 如果斷開該使用者，從 Twitter 應用程式，但是，不能發佈。

ASP.NETMVC API — — 具體 OAuthWeb­安全類 — — 很好，位址的身份驗證方案，但它沒有涵蓋與以外獲得的顯示名稱的社會提供程式進行交互。 它還集成好了簡單的成員資格提供程式的 Web 頁的用於存儲本地 Twitter 和 Facebook 使用者名稱。

Dino Esposito  是"構建移動解決方案的企業"（微軟出版社，2012年） 的作者和"程式設計ASP.NETMVC 3"（微軟出版社，2011年） 和他的"Microsoft.NET：構建企業應用程式"（微軟出版社，2008年）。埃斯波西托在義大利的基礎，是經常在世界各地的行業活動中發表演講。跟著他在 Twitter 上 twitter.com/despos。

由於以下的技術專家對本文的審閱：摩尼勃拉曼尼亞 (Microsoft)
摩尼勃拉曼尼亞一直參與發展和測試軟體專案的重點放在 SOA 過去 12 年，雲計算和核心。 淨。