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表示“我不确定你是谁请先证明身份”对应的是未认证状态通常触发登录跳转或返回 401Forbid表示“我已经知道你是谁但你没有权限做这件事”对应的是已认证但无权访问通常触发 403。这个区分在面试中是明显的分水岭能聊清楚的人说明至少读过框架源码或看过多层中间件的执行逻辑。面试官还会顺着问“身份对象是什么”。在 ASP.NET Core 里HttpContext.User的类型是ClaimsPrincipal它包含若干ClaimsIdentity每个 identity 里承载一组Claim。Claim 是一条条“关于用户的陈述”比如UserNamezhangsan、RoleAdmin、UserId10086。认证的本质就是把令牌里声明的这些 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 ListClaim { 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; }再写继承自AuthorizationHandlerCanModifyOrderRequirement的处理器public class CanModifyOrderHandler : AuthorizationHandlerCanModifyOrderRequirement { 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.AddSingletonIAuthorizationHandler, 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 是事实”。意思是RoleAdmin代表一个身份组合而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”或者反过来。我建议不要背结论而是记住一张对比表然后根据场景现场推导维度JWTCookie 认证凭据存储客户端自定义保存内存/localStorage浏览器自动保存请求传递手动加 Authorization 头浏览器自动携带跨域支持天然灵活适合前后端分离需配置 CORS 和凭据策略吊销能力难过期前基本无法作废可配合服务端会话实现即时吊销CSRF 风险较低如果走 Authorization 头必须防 CSRFXSS 风险较高localStorage 可被脚本读取较低HttpOnly 保护实现复杂度需要处理刷新、过期等逻辑框架自带成熟简单面试答法参考这样的逻辑如果系统是传统多页应用由服务端渲染页面Cookie 是最自然的选择如果是 SPA 对接纯 APIJWT 的跨域体验更好但必须先想清楚令牌放哪、如何续期、如何应对 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 的适用场景又表明你清楚它的弱点且有对策。如果被问到不会的技术点我的建议是不要硬编一个方案而是说“这个方向我没实际做过但我会先从官方文档和日志线索入手去定位问题”。诚恳地给出排查思路通常比一个漏洞百出的现编答案更像真实工程师。正准备这套面试内容时我建议你把前面几篇聊过的中间件顺序、依赖注入生命周期和配置系统也拿过来一起复习。认证授权不是一个孤立模块它嵌在管道处理流程里和宿主启动、中间件注册、配置读取都有关联。把这些串起来面试官问你任意一个环节你都能顺着管道往下讲这种“体系感”才是面试精讲系列想让你真正带走的东西。