ASP.NET Core认证与授权核心机制：从JWT到策略授权面试精讲

1. 认证与授权：先分清这两个词，才算没白准备

1.1 一次登录之后，系统内部发生了什么

很多准备 ASP.NET Core 面试的人会把认证和授权混在一起背，一开口就是“JWT 可以无状态地保护接口”，这个说法本身没错，但太粗略了。面试官真正想听到的是：一次登录之后，系统内部到底发生了什么？你的身份信息是怎么从一次请求带到下一次请求的？

我用一个场景把这条链路讲清楚。用户在登录接口提交账号密码，校验通过后，服务端签发一个令牌返回给前端。后续每次请求，前端把令牌放在请求头里带回来，由认证中间件解析令牌、验证签名和有效期，然后把令牌里携带的声明还原成一个身份对象，挂到HttpContext.User上。到这为止，系统只完成了“你是谁”的确认。下一步才轮到授权：拿着这个身份对象，去比对当前用户能不能访问某个接口、能不能执行某个操作。

在 ASP.NET Core 的项目模板里，启动管道中通常有app.UseAuthentication()和app.UseAuthorization()两个中间件。强调一下，注册的先后顺序是有讲究的：认证必须在前，授权在后。道理很简单，授权需要拿“已经确认的身份”去做判断，如果先走授权，HttpContext.User还是空的，所有权限检查都会失败。

为了帮助你记忆，可以类比成写字楼的门禁体系。认证是访客在前台出示证件，前台确认“这是张三”；授权是张三拿门禁卡去刷特定楼层的门，能不能刷开某个门才是权限问题。如果没有前面那步认证，后边全都不成立。

1.2 面试官抛出“什么是认证，什么是授权”时，他想听到什么

这个问题看起来基础，但翻车率非常高。常见错误是：有人背教科书定义，把“Authentication is the process of verifying who you are”这类英文原句甩出来，然后就说完了。面试官追问一句“那 ASP.NET Core 里 Challenge 和 Forbid 的区别是什么”，直接愣住。

Challenge 和 Forbid 是认证授权机制里两个容易被忽略但很重要的概念。简单说，Challenge表示“我不确定你是谁，请先证明身份”，对应的是未认证状态，通常触发登录跳转或返回 401；Forbid表示“我已经知道你是谁，但你没有权限做这件事”，对应的是已认证但无权访问，通常触发 403。这个区分在面试中是明显的分水岭，能聊清楚的人，说明至少读过框架源码或看过多层中间件的执行逻辑。

面试官还会顺着问“身份对象是什么”。在 ASP.NET Core 里，HttpContext.User的类型是ClaimsPrincipal，它包含若干ClaimsIdentity，每个 identity 里承载一组Claim。Claim 是一条条“关于用户的陈述”，比如UserName=zhangsan、Role=Admin、UserId=10086。认证的本质，就是把令牌里声明的这些 Claim 还原成ClaimsPrincipal；授权的本质，则是拿这些 Claim 去与权限要求做匹配。

这段内容虽然浅，却是整套认证授权机制的地基。地基不稳，后边讲 JWT 多深入都容易被一句追问击穿。

2. JWT 原理不背概念：把三段签名亲手拆一遍

2.1 Header、Payload、Signature 各自回答什么问题

JWT 几乎是 ASP.NET Core 面试的必考点，但很多人只会在项目里配AddJwtBearer，被问到“JWT 由哪几部分组成，签名到底在防什么”就卡壳。其实拆开以后并不难，它由三个用点分隔的片段组成：Header、Payload、Signature。

Header 存放令牌元信息，最核心的是alg，也就是签名算法，常见的有HS256（对称密钥）和RS256（非对称密钥）。它回答的问题是“这个令牌怎么签出来的”。Payload 存放声明集合，除了自定义的用户信息，还会有exp过期时间、aud受众、iss签发方之类的标准声明。它回答的问题是“这个令牌携带了哪些身份信息”。Signature 则是把前两段内容拼接起来，用alg声明的算法和密钥计算出的签名结果，回答的问题是“这个令牌有没有被篡改过”。

这里有一个很多面试者都会误解的地方：JWT 不是加密协议。Header 和 Payload 里的内容只是做了 Base64Url 编码，不是密文，任何人都可以解码看到原文。Signature 存在的意义是防篡改，不是防偷窥。所以，敏感数据如密码、手机号、身份证号绝对不要塞进 Payload，哪怕你全程走 HTTPS，令牌一旦被截获，里面的内容就形同裸奔。这个点拿出来讲，面试官会立刻觉得你踩过真实项目的坑。

2.2 签发与验证的代码骨架：对称密钥最容易出问题

我直接贴一段能跑通的签发代码，这也是一个典型的使用HS256对称密钥的例子：

var key = new SymmetricSecurityKey( Encoding.UTF8.GetBytes(config["Jwt:Key"])); var credentials = new SigningCredentials( key, SecurityAlgorithms.HmacSha256); var token = new JwtSecurityToken( issuer: config["Jwt:Issuer"], audience: config["Jwt:Audience"], claims: new List<Claim> { new Claim(ClaimTypes.Name, user.UserName), new Claim(ClaimTypes.Role, user.Role) }, expires: DateTime.UtcNow.AddMinutes(30), signingCredentials: credentials); var tokenString = new JwtSecurityTokenHandler() .WriteToken(token);

验证端的配置长这样：

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options => { options.TokenValidationParameters = new TokenValidationParameters { ValidateIssuer = true, ValidateAudience = true, ValidateLifetime = true, ValidateIssuerSigningKey = true, ValidIssuer = config["Jwt:Issuer"], ValidAudience = config["Jwt:Audience"], IssuerSigningKey = key }; });

这段代码看起来简单，实际项目里踩坑全在细节上。最典型的是对称密钥长度不足，HmacSha256要求密钥至少 256 位，也就是 32 个字符。很多人用一串很短的字符串当 Key，运行时报错或者令牌验证失败，还以为是两端 Key 不一致。另一个高频坑是服务器时间偏差，ValidateLifetime开启后，如果签发服务器和验证服务器的时间差超过几分钟，令牌明明没过期却被判定为无效。稳妥的做法是在TokenValidationParameters里设置ClockSkew，比如ClockSkew = TimeSpan.FromMinutes(5)，给时间校验留一点缓冲。

2.3 有效期、刷新令牌与“踢人下线”的世纪难题

JWT 无状态是优点也是隐患。优点在于服务端不用存会话，天然适合分布式部署；隐患在于令牌一旦签出去，在过期之前无法主动吊销。假如用户修改了密码，旧令牌仍然有效；管理员删除了某个账号，他的 token 还能继续访问接口。这个矛盾是面试里最容易往下追问的点。

常见的方案有三种。第一种，把access_token的生命周期设得非常短，比如 15 分钟，配一个refresh_token用来换新令牌。用户频繁使用时无感续期，令牌泄漏后的危害窗口也变小。第二种，做一个吊销清单，把被强制下线的用户 ID 放进分布式缓存，在认证中间件里做一次比对。第三种，给用户表加一个版本号字段，每次密码修改或权限变更就递增版本号，签发和验证令牌时都带上版本号，版本不匹配直接拒绝。

这三种方案的成本和复杂度是递增的。面试的时候不需要把每一种都说得滴水不漏，但至少要把“无状态会导致吊销困难”这个问题点出来，然后给出一种你实际用过的方案。很多应届生止步于“JWT 更安全”，有经验的面试官一听就知道项目经验有限。

3. 授权不写死：从角色到策略，绕开“到处 if 用户是哪个角色”的泥潭

3.1 基于角色的授权和策略授权，本质区别在哪

项目初期，很多团队用基于角色的授权，控制器上挂[Authorize(Roles = "Admin")]，简单直接。但业务一旦复杂起来，这种写法就开始吃紧。比如“只有订单创建者本人或者管理员可以修改订单”，这句话就没办法单靠角色表达，因为订单归属权是动态数据，不是静态身份属性。

基于策略的授权把问题拆解成了两步。第一步，声明一个策略名，比如CanModifyOrder，代表一条权限规则；第二步，把如何验证这条规则的逻辑写在一个 Handler 里。控制器和业务代码只需要关心“接口要求什么权限”，不需要关心规则具体怎么实现。将来权限规则从“创建者或管理员”变成“创建者或管理员或财务审核人”，只改策略定义，不用动控制器。

这个抽象其实很像面向对象里的依赖倒置：上层业务依赖的是策略这个抽象，而不是具体的角色判断细节。项目里的接口一旦多起来，策略授权的维护成本明显低于满屏的角色判断。

3.2 自定义 AuthorizationHandler 的完整接线过程

空谈没有意义，我把一套最小可用的自定义授权写完整。

先定义一个需求类，实现IAuthorizationRequirement空接口即可，它的作用是给策略一个标识：

public class CanModifyOrderRequirement : IAuthorizationRequirement { public bool AllowAdmin { get; set; } = true; }

再写继承自AuthorizationHandler<CanModifyOrderRequirement>的处理器：

public class CanModifyOrderHandler : AuthorizationHandler<CanModifyOrderRequirement> { protected override Task HandleRequirementAsync( AuthorizationHandlerContext context, CanModifyOrderRequirement requirement) { var user = context.User; var isAdmin = user.IsInRole("Admin"); var orderOwnerId = user.FindFirstValue(ClaimTypes.NameIdentifier); // orderOwnerIdFromRoute 应从路由或资源对象中获取 if (isAdmin || orderOwnerId == orderOwnerIdFromRoute) { context.Succeed(requirement); } return Task.CompletedTask; } }

然后在启动类注册：

services.AddSingleton<IAuthorizationHandler, CanModifyOrderHandler>(); services.AddAuthorization(options => { options.AddPolicy("CanModifyOrder", policy => policy.AddRequirements(new CanModifyOrderRequirement())); });

控制器上的用法是[Authorize(Policy = "CanModifyOrder")]。

这里有两个容易让新手绕晕的细节。第一个是context.Succeed(requirement)并不是返回布尔值，它是在向授权上下文标记“这个需求被当前 Handler 满足了”。如果策略里有多个 Handler，任何一个成功都会被认定为有权访问，除非你的需求设计成了必须全部满足。第二个是 Handler 注册成Singleton还是Scoped？我自己用Singleton，因为 Handler 本身应当是无状态的，它每请求被调用，但内部不依赖请求级数据；如果非要去查数据库，则会引入额外的复杂性和潜在的线程安全问题。

3.3 Claim 的设计比写 Handler 更考验功底

写完这段代码之后，面试官很可能会问“那你用户的权限数据从哪来”。这个问题其实比 Handler 本身更难回答。

我看到过不少项目，登录的时候把用户的所有权限拼成一个逗号分隔的字符串塞进 Claim，然后 Handler 里用Contains判断。这种做法的坏处是令牌体积膨胀，而且权限一变就要重新登录。更合理的设计思路是：令牌里只放稳定的、低频变化的基础声明，比如用户 ID、姓名、角色；细粒度的权限码可以放在服务端缓存里，每次授权时从缓存读取，缓存没有再回源数据库。这样既不会让每个请求都穿透数据库，又能做到权限变更后相对及时生效。

还有一个值得提的观点是“角色是组合，Claim 是事实”。意思是Role=Admin代表一个身份组合，而Permission.CanDeleteOrder是一条独立的权限事实。一个用户可以有多个角色，一个角色可以聚合多条权限，授权规则应该去匹配权限，而不是到处判断角色。面试时把这句话讲出来，比单纯展示代码要高级得多。

4. Cookie 认证没有过时：面试里它常以“方案对比题”出现

4.1 Cookie 认证的内部机制回顾

现在很多看中台化、前后端分离的项目用 JWT，导致一些初学者以为 Cookie 认证是淘汰技术。其实不是，Cookie 认证在服务端渲染、BFF（后端为前端）模式里依然非常普及，面试官也喜欢拿它出来和 JWT 做对比。

Cookie 认证的核心过程是这样的：登录成功后，调用SignInAsync，框架把当前用户身份序列化成票据，也就是AuthenticationTicket，然后用 Data Protection API 加密，通过Set-Cookie响应头发回浏览器。浏览器之后的每个请求会自动携带这个 Cookie，认证中间件拿到后解密、反序列化，还原出ClaimsPrincipal。整个过程中，服务端默认不需要保存任何会话数据，加密票据本身就承载了身份信息。

代码怎么写呢：

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) .AddCookie(options => { options.LoginPath = "/login"; options.AccessDeniedPath = "/forbidden"; options.Cookie.HttpOnly = true; options.Cookie.SecurePolicy = CookieSecurePolicy.Always; options.Cookie.SameSite = SameSiteMode.Lax; });

几个配置项值得记住。HttpOnly = true是必须的，防止页面脚本直接读取 Cookie，降低 XSS 后的窃取风险；SecurePolicy = Always强制 Cookie 只在 HTTPS 连接下传输；SameSite = Lax可以限制跨站请求是否携带 Cookie，是缓解 CSRF 的手段之一。面试里能把这些配置的用途讲清楚，说明你真的部署过而不是背过配置。

4.2 一张表看穿 JWT 与 Cookie 的取舍

面试现场最常出现的题目是“你这个项目为什么用 JWT 而不用 Cookie”，或者反过来。我建议不要背结论，而是记住一张对比表，然后根据场景现场推导：

面试答法参考这样的逻辑：如果系统是传统多页应用，由服务端渲染页面，Cookie 是最自然的选择；如果是 SPA 对接纯 API，JWT 的跨域体验更好，但必须先想清楚令牌放哪、如何续期、如何应对 XSS。关键点是“没有绝对方案，只有场景适配”。很多候选人被问崩是因为非要证明其中一个完全优于另一个，这种立场本身就暴露了认知局限。

5. 连环追问里的那些边角：跨域、防伪令牌、状态码语义

5.1 CORS 与认证中间件的顺序：一个真实的配置坑

这个坑我在项目里遇到过不止一次：前端是 SPA，后端接口配置了 JWT 认证，两者不同源。后端已经加了UseCors，但前端请求浏览器一直报 CORS 错误，最诡异的是某些接口能通，某些接口报 401。后来定位下来，问题居然出在中间件注册顺序上。

ASP.NET Core 中间件是按注册顺序执行的，CORS 中间件需要足够早地进入管道，才能在预检请求阶段直接响应。典型错误是把UseCors写在UseAuthentication后面：

app.UseAuthentication(); app.UseAuthorization(); app.UseCors("frontend"); // 错误示例

正确的顺序应该是：

app.UseCors("frontend"); app.UseAuthentication(); app.UseAuthorization();

为什么顺序会产生这么大的影响？因为浏览器发送跨域请求前，如果请求带了Authorization头、自定义头或非简单请求，会先发出一个OPTIONS预检请求。这个预检请求不带认证凭据，CORS 中间件必须在它能处理的阶段拦截并返回允许跨域的响应头。如果UseCors注册得太靠后，预检请求走到认证环节，由于没有凭据会被直接返回 401，浏览器看到 401 就判定预检失败，于是前端看到的就是一排 CORS 报错。这种问题排查起来最花时间，因为表象在浏览器，根因在后端中间件管道。

5.2 CSRF 防伪令牌与 JWT 的“天然免 CSRF”误区

CSRF（跨站请求伪造）是 Cookie 认证里必须面对的问题。因为浏览器收到Set-Cookie后会保存，后续即使是从其他站点发出的请求，只要目标是你的站点，浏览器也会自动带上本机存储的 Cookie。攻击者诱导用户访问一个恶意页面，这个页面向你的后端接口提交请求，请求里自然会带上受害者的登录 Cookie，服务端看到 Cookie 有效，就认为是本人操作。

对付的办法是防伪令牌：服务端生成一个随机值下发给前端，前端在提交请求时把这个值放在请求头或表单里，服务端比对是否一致。由于跨站攻击页面拿不到这个随机值，伪造请求就会被拦下。在 ASP.NET Core 中对应的是AddAntiforgery服务以及生成的验证令牌。

很多人以为 JWT 放在localStorage里就天然免疫 CSRF，这个说法不准确。准确地说，JWT 如果通过Authorization头传递，确实不会被浏览器自动携带，所以 CSRF 风险确实很低；但代价是令牌放进了localStorage，页面里的恶意脚本一旦能执行，就能直接读走令牌。而如果把 JWT 存在 Cookie 里让它自动携带，那 CSRF 风险又回来了，同样需要防伪令牌。面试里能说出“威胁模型不同，代价不同，不存在零成本方案”，比单方面吹 JWT 高级得多。我在实际项目中更倾向于把敏感令牌放在内存变量里，刷新即丢失，配合 refresh token 从接口重新获取，这样 XSS 和 CSRF 的暴露面都能压到最低。

5.3 401 与 403 的语义不要搞反

这个点属于看着简单、一问就露馅的典型。有两种答案在面试中经常出现：一是把 401 和 403 混为一谈，说“反正都是没权限”；二是只记得 401 是未登录，被反问 403 和 401 的区别时支支吾吾。

准确的含义是：401 Unauthorized 表示未认证或凭据无效，服务器不知道你是谁；403 Forbidden 表示服务器知道你是谁，但你不具备执行操作的权限。在 ASP.NET Core 的中间件机制里，Challenge和Forbid正好对应这两种状态。未认证用户访问受保护接口，认证中间件触发Challenge，默认返回 401；已认证但授权策略验证失败，授权中间件触发Forbid，默认返回 403。

在前后端分离的 API 场景，默认的登录跳转行为并不合适，接口需要返回结构化 JSON。这时可以借助JwtBearerEvents自定义响应：

options.Events = new JwtBearerEvents { OnChallenge = context => { context.HandleResponse(); context.Response.StatusCode = 401; context.Response.ContentType = "application/json"; return context.Response.WriteAsJsonAsync(new { code = 401, message = "未认证或登录已过期" }); }, OnForbidden = context => { context.Response.StatusCode = 403; context.Response.ContentType = "application/json"; return context.Response.WriteAsJsonAsync(new { code = 403, message = "当前账号无权执行此操作" }); } };

这里HandleResponse()表示中止默认的跳转逻辑，由你接管响应输出。很多接口联调时前端抱怨“明明登录了还返回 401”，多半是后端把 403 的场景错写成了 401，或者前端拿到了 401 就去跳登录页。把这两个状态码的语义理清楚，不只是面试有用，排错时也能少走弯路。

6. 准备这套面试内容的实操建议

6.1 用最短时间亲手走一遍的 Demo 路径

纸上谈兵和亲手跑通完全是两回事。我建议所有准备面试的人花一两个小时，把下面这个最小闭环做一遍，比刷十道八股文都有用。

用dotnet new webapi创建一个空项目。先启动配置里加认证授权服务和 JWT 验证参数；再写一个登录接口，返回签发的 token；接着给某个接口挂上[Authorize(Policy = "CanModifyOrder")]特性并实现对应的 Requirement 和 Handler。然后用 Postman 分三步验证：不带 token 请求受保护接口，应该得到 401；用普通用户 token 请求，应该得到 403（前提是你的 Handler 没有放行普通用户）；用具备权限的 token 请求，才能得到 200。

做完这套之后，再花十分钟做一个实验：把UseAuthentication和UseAuthorization顺序调换，看看会发生什么。这个实验能帮你真正理解中间件管道的执行顺序，以后面试被问到“中间件顺序错了会有什么表现”，你就可以直接说“我试过，Authorization 拿不到 User，接口全部变成 403”。这种回答是编不出来的。

6.2 被追问“为什么这么做”时，怎么组织语言

面试官追问的目的，往往不是想听标准答案，而是看你能不能把知识串成体系。所以回答任何选型问题时，我都建议遵循一个固定结构：先讲场景约束，再讲你的方案，最后讲代价。

比如被问“为什么用 JWT 而不是 Cookie”，不要上来就说“JWT 跨域方便”。更好的回答是：“我的项目是纯前端分离的 SPA，后端只提供 API。在这种拓扑下，JWT 放在 Authorization 头里跨域比较顺手。但我知道它也有代价，比如吊销难、XSS 风险需要管控，所以我把 access_token 生命期设得很短，配合 refresh_token 续期，并且敏感数据不进 Payload。”

这段话信息量很大，既说明你知道 JWT 的适用场景，又表明你清楚它的弱点且有对策。如果被问到不会的技术点，我的建议是不要硬编一个方案，而是说“这个方向我没实际做过，但我会先从官方文档和日志线索入手去定位问题”。诚恳地给出排查思路，通常比一个漏洞百出的现编答案更像真实工程师。

正准备这套面试内容时，我建议你把前面几篇聊过的中间件顺序、依赖注入生命周期和配置系统也拿过来一起复习。认证授权不是一个孤立模块，它嵌在管道处理流程里，和宿主启动、中间件注册、配置读取都有关联。把这些串起来，面试官问你任意一个环节，你都能顺着管道往下讲，这种“体系感”才是面试精讲系列想让你真正带走的东西。