ASP.NET Core 1.x提供了通过Cookie 中间件将用户主体序列化为一个加密的Cookie，然后在后续请求中验证Cookie并重新创建主体，并将其分配给HttpContext.User属性。如果您要提供自己的登录界面和用户数据库，可以使用作为独立功能的Cookie中间件。
ASP.NET Core 2.x的一个主要变化是不再存在Cookie中间件。取而代之的是在Startup.cs文件中的Configure方法中的调用UseAuthentication方法会添加设置HttpContext.User属性的 AuthenticationMiddleware 中间件。
添加配置
ASP.NET Core 1.x
按下列步骤操作：
在您的项目中安装Microsoft.AspNetCore.Authentication.CookiesNuGet包。此包包含Cookie中间件。
在Startup.cs文件中的Configure方法中添加下面的行，在app.UseMvc()语句之前：
app.UseCookieAuthentication(new CookieAuthenticationOptions()
{
AccessDeniedPath = "/Account/Forbidden/",
AuthenticationScheme = "MyCookieAuthenticationScheme",
AutomaticAuthenticate = true,
AutomaticChallenge = true,
LoginPath = "/Account/Unauthorized/"
});
ASP.NET Core 2.x
按下列步骤操作：
如果不使用Microsoft.AspNetCore.All 元包，则在您的项目中安装2.0版的Microsoft.AspNetCore.Authentication.CookiesNuGet包。
在Startup.cs文件中的Configure方法中调用UseAuthentication方法：
app.UseAuthentication();
在Startup.cs文件中的ConfigureServices方法中调用AddAuthentication和AddCookie方法：
services.AddAuthentication("MyCookieAuthenticationScheme")
.AddCookie("MyCookieAuthenticationScheme", options => {
options.AccessDeniedPath = "/Account/Forbidden/";
options.LoginPath = "/Account/Unauthorized/";
});
上面的代码片段配置了以下部分或全部选项：
- AccessDeniedPath - 当用户尝试访问资源但没有通过任何授权策略时，这是请求会重定向的相对路径资源。
- AuthenticationScheme - 这是一个已知的特定Cookie认证方案的值。当有多个Cookie验证实例，并且您想限制对一个实例的授权时，这就非常有用。
- AutomaticAuthenticate - 此标识仅适用于ASP.NET Core 1.x。它表示Cookie身份验证应在每个请求上运行，并尝试验证和重建序列化主体。
- AutomaticChallenge - 此标识仅适用于ASP.NET Core 1.x。这表示当授权失败时，1.x Cookie认证应将浏览器重定向到LoginPath或AccessDeniedPath。
- LoginPath - 当用户尝试访问资源但尚未认证时，这是请求重定向的相对路径。
其它选项包括为Cookie认证创建的设置选项，身份验证的Cookie的名称，Cookie的域和Cookie各种安全属性。默认情况下，Cookie身份验证为其创建的任何Cookie使用适当的安全选项，例如：
- 设置HttpOnly标志以防止客户端JavaScript中访问Cookie
- 如果请求是通过HTTPS访问，则将Cookie限制为HTTPS
创建身份认证Cookie
要创建一个保存用户信息的cookie，您必须构建一个ClaimsPrincipal 保存您希望序列化到Cookie中的信息。
ASP.NET Core 1.x
await HttpContext.Authentication.SignInAsync("MyCookieAuthenticationScheme", principal);
ASP.NET Core 2.x
await HttpContext.SignInAsync("MyCookieAuthenticationScheme", principal);
这将创建一个加密的Cookie并将其添加到当前响应中。在调用SignInAsync时，必须在配置中指定的AuthenticationScheme。
顺便提一下，使用的加密方式是ASP.NET Core的Data Protection系统。如果您在多台机器上进行托管、负载平衡或使用Web集群，则需要配置Data Protection才能使用相同的密钥和应用程序标识符。
Signing out(登出)
要退出当前用户并删除其Cookie，请在控制器中调用以下方法：
ASP.NET Core 1.x
await HttpContext.Authentication.SignOutAsync("MyCookieAuthenticationScheme");
ASP.NET Core 2.x
await HttpContext.SignOutAsync("MyCookieAuthenticationScheme");
服务端变化反馈
警告： 一旦创建了认证的Cookie，它将成为唯一的身份来源。即使您在服务系统中禁用用户，Cookie身份验证也无法了解此信息，只要Cookie有效，用户仍可登录。
Cookie认证在其选项中提供了一系列事件。ValidateAsync()事件可用于拦截和重写Cookie身份验证。
可以考虑在后端用户数据库中增加LastChanged列。为了在数据库更改时使Cookie无效，您应该首先在创建Cookie时添加一个LastChanged包含当前值的声明。数据库更改时，更新LastChanged例的值。
要重写ValidateAsync()事件的实现，您必须编写一个具有以下签名的方法：
Task ValidateAsync(CookieValidatePrincipalContext context);
ASP.NET Core Identity 在SecurityStampValidator实现了这一逻辑，链接地址。示例如下所示：
ASP.NET Core 1.x
public static class LastChangedValidator
{
public static async Task ValidateAsync(CookieValidatePrincipalContext context)
{
// Pull database from registered DI services.
var userRepository = context.HttpContext.RequestServices.GetRequiredService<IUserRepository>();
var userPrincipal = context.Principal;
// Look for the last changed claim.
string lastChanged;
lastChanged = (from c in userPrincipal.Claims
where c.Type == "LastUpdated"
select c.Value).FirstOrDefault();
if (string.IsNullOrEmpty(lastChanged) ||
!userRepository.ValidateLastChanged(userPrincipal, lastChanged))
{
context.RejectPrincipal();
await context.HttpContext.Authentication.SignOutAsync("MyCookieAuthenticationScheme");
}
}
}
然后，在Startup.cs文件中的Configure方法中将Cokie认证配置进行重写：
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
Events = new CookieAuthenticationEvents
{
OnValidatePrincipal = LastChangedValidator.ValidateAsync
}
});
ASP.NET Core 2.x
public static class LastChangedValidator
{
public static async Task ValidateAsync(CookieValidatePrincipalContext context)
{
// Pull database from registered DI services.
var userRepository = context.HttpContext.RequestServices.GetRequiredService<IUserRepository>();
var userPrincipal = context.Principal;
// Look for the last changed claim.
string lastChanged;
lastChanged = (from c in userPrincipal.Claims
where c.Type == "LastUpdated"
select c.Value).FirstOrDefault();
if (string.IsNullOrEmpty(lastChanged) ||
!userRepository.ValidateLastChanged(userPrincipal, lastChanged))
{
context.RejectPrincipal();
await context.HttpContext.SignOutAsync("MyCookieAuthenticationScheme");
}
}
}
然后，将在Startup.cs的ConfigureServices方法中将Cookie服务注册进行配置：
services.AddAuthentication("MyCookieAuthenticationScheme")
.AddCookie(options =>
{
options.Events = new CookieAuthenticationEvents
{
OnValidatePrincipal = LastChangedValidator.ValidateAsync
};
});
如果要非破坏性地更新用户主体，可以调用context.ReplacePrincipal()，并将context.ShouldRenew属性设置为true。
Cookie设置选项
CookieAuthenticationOptions类提供了各种配置选项，在创建时调整Cookie的配置。
ASP.NET Core 1.x
- ClaimsIssuer是由中间件创建的任何声明时使用的Issuer属性。
- CookieDomain是提供Cookie的域名。默认情况下，这是发送请求的主机名。浏览器仅将Cookie提供给匹配的主机名。您可能希望对此进行调整，以便您的域中的任何主机都可以使用Cookie。例如，将Cookie域名设置为.contoso.com，可以使用Cookie的域名有contoso.com、www.contoso.com、staging.www.contoso.com等。
- CookieHttpOnly是一个标识，指定Cookie是否只能由服务器访问。默认为true。如果您的应用程序具有Cross-Site Scripting(XSS)的问题，更改此值可能会导致Cookie被盗用。
- CookiePath可用于隔离在相同主机名上运行的应用程序。如果你有一个应用程序在/app1中运行，并希望限制发送的Cookie只发送到该应用程序，那么您应该将CookiePath属性设置为/app1。通过这样做，Cookie只适用于对/app1或其下任何内容的请求。
- CookieSecure是一个标识，表示创建的Cookie是否应该被限制为HTTPS，HTTP或HTTPS，或与请求相同的协议。默认为SameAsRequest。
- ExpireTimeSpan是TimeSpan类型，在此时间段之后Cookie将过期。将当前日期加上此时间段为创建Cookie的到期日期。
- SlidingExpiration是一个标识，指示当超过一半的ExpireTimeSpan间隔时，Cookie到期日期是否复位。新的到期日是当前时间加上ExpireTimespan。调用SignInAsync时，可以使用AuthenticationProperties类设置绝对到期时间。绝对到期时间可以通过限制认证Cookie有效的时间来提高应用程序的安全性。
在Startup.cs文件中的Configure方法中使用CookieAuthenticationOptions的例子如下：
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
CookieName = "AuthCookie",
CookieDomain = "contoso.com",
CookiePath = "/",
CookieHttpOnly = true,
CookieSecure = CookieSecurePolicy.Always
});
ASP.NET Core 2.x
ASP.NET Core 2.x 统一了用于配置Cookie的API。1.x API已被标记为过时，并且在CookieAuthenticationOptions类中引入了一种类型为CookieBuilder新的Cookie属性。建议您迁移到2.x API。
- ClaimsIssuer是由Cookie认证创建的任何声明时使用的Issuer属性。
- CookieBuilder.Domain是提供Cookie的域名。默认情况下，这是发送请求的主机名。浏览器仅将Cookie提供给匹配的主机名。您可能希望对此进行调整，以便您的域中的任何主机都可以使用Cookie。例如，将Cookie域名设置为.contoso.com，可以使用Cookie的域名有contoso.com、www.contoso.com、staging.www.contoso.com等
- CookieBuilder.HttpOnly是一个标识，指定Cookie是否只能由服务器访问。默认为true。如果您的应用程序具有Cross-Site Scripting(XSS)的问题，更改此值可能会导致Cookie被盗用。
- CookieBuilder.Path可用于隔离在相同主机名上运行的应用程序。如果你有一个应用程序在/app1中运行，并希望限制发送的Cookie只发送到该应用程序，那么您应该将CookiePath属性设置为/app1。通过这样做，Cookie只适用于对/app1或其下任何内容的请求。
- CookieBuilder.SameSite表示浏览器是否允许Cookie被附加到同一站点或跨站点的请求。默认为SameSiteMode.Lax。
- CookieBuilder.SecurePolicy是一个标识，表示创建的Cookie是否应该被限制为HTTPS，HTTP或HTTPS，或与请求相同的协议。默认为SameAsRequest。
- ExpireTimeSpan是TimeSpan类型，在此时间段之后Cookie将过期。将当前日期加上此时间段为创建Cookie的到期日期。
- SlidingExpiration是一个标识，指示当超过一半的ExpireTimeSpan间隔时，Cookie到期日期是否复位。新的到期日是当前时间加上ExpireTimespan。调用SignInAsync时，可以使用AuthenticationProperties类设置绝对到期时间。绝对到期时间可以通过限制认证Cookie有效的时间来提高应用程序的安全性。
在Startup.cs的ConfigureServices方法中使用CookieAuthenticationOptions的例子如下：
services.AddAuthentication()
.AddCookie(options =>
{
options.Cookie.Name = "AuthCookie";
options.Cookie.Domain = "contoso.com";
options.Cookie.Path = "/";
options.Cookie.HttpOnly = true;
options.Cookie.SameSite = SameSiteMode.Lax;
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
});
持久Cookie和绝对到期时间
您可能希望Cookie在浏览器会话中持续存在，并希望设置身份和Cookie传输的绝对过期时间。这种持久性应该只能是用户显示同意，在登录时的“记住我”复选框或类似的机制启用。您可以通过在创建身份认证Cookie时调用的SignInAsync方法中使用AuthenticationProperties参数来执行这些操作。例如：
ASP.NET Core 1.x
await HttpContext.Authentication.SignInAsync(
"MyCookieAuthenticationScheme",
principal,
new AuthenticationProperties
{
IsPersistent = true
});
上述代码片段中使用的AuthenticationProperties类，位于Microsoft.AspNetCore.Http.Authentication命名空间中。
ASP.NET Core 2.x
await HttpContext.SignInAsync(
"MyCookieAuthenticationScheme",
principal,
new AuthenticationProperties
{
IsPersistent = true
});
上述代码片段中使用的AuthenticationProperties类，位于Microsoft.AspNetCore.Authentication命名空间中。
上面的代码段创建一个身份和相应的Cookie，直到浏览器关闭。以前通过Cookie设置选项配置的任何滑动过期设置仍然有效。如果Cookie在浏览器关闭时过期，浏览器会在重新启动后清除它。如果Cookie在浏览器关闭时过期，浏览器会在重新启动后清除它。
ASP.NET Core 1.x
await HttpContext.Authentication.SignInAsync(
"MyCookieAuthenticationScheme",
principal,
new AuthenticationProperties
{
ExpiresUtc = DateTime.UtcNow.AddMinutes(20)
});
ASP.NET Core 2.x
await HttpContext.SignInAsync(
"MyCookieAuthenticationScheme",
principal,
new AuthenticationProperties
{
ExpiresUtc = DateTime.UtcNow.AddMinutes(20)
});
上述代码段创建一个持续20分钟的身份和相应的cookie。这将忽略以前通过Cookie设置选项配置的任何滑动过期设置。
ExpiresUtc和IsPersistent属性是互斥的。
原文：《Using Cookie Authentication without ASP.NET Core Identity》
翻译：Sweet Tang
本文地址：http://www.cnblogs.com/tdfblog/p/aspnet-core-security-authentication-cookie.html
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。