Duende Identity Server授权后ASP.NET Core启动Angular SPA问题

现有实现流程梳理 #

• 站点首页提供用户名/密码登录表单
• 登录表单以HttpPost方式提交至携带[Authorize]特性的LoginController对应Action，授权校验环节对接Duende Identity Server完成身份核验
• 授权成功后Identity Server默认将请求重定向到业务域名下的/signin-oidc地址
• 当前实现中该回调请求以HttpGet方式回到同一个Login Action
• 确认用户完成认证后，该Action重定向到专门的控制器Action，负责承载Angular SPA的启动加载逻辑

针对性解答 #

疑问一：/signin-oidc的实现归属、调用方与部署位置 #

/signin-oidc既不是Identity Server的内部端点，也不需要开发者手动编写控制器Action实现，更不属于Angular SPA侧的实现逻辑。
该端点是ASP.NET Core OpenID Connect认证中间件默认自动注册的内置回调端点，实际部署位置就是你对接OIDC认证的后端服务（即当前的ASP.NET Core MVC应用）。中间件会自动拦截发往这个路径的请求，独立完成授权码交换、令牌校验、身份认证Cookie写入的全流程，不需要额外编写业务代码处理。
注意：当前实现把该回调路由到自定义Login Action的做法是错误的，会直接打断中间件的默认认证流程。

疑问二：当前整套实现方案是否合理 #

现有方案存在流程错位问题，并不合理，核心问题有两个：

• 错误拦截了OIDC中间件的内置回调端点/signin-oidc，绕开了中间件默认的令牌交换、认证会话建立逻辑，很容易出现认证状态丢失、令牌校验不通过、会话生命周期异常的问题
• 如果是MVC托管Angular静态文件的部署模式，不需要单独加一层Action做SPA启动跳转，中间件完成认证后直接重定向到SPA入口路径即可，多余的跳转层会徒增跨域、会话传递的复杂度。

疑问三：Angular SPA是否应当通过OIDC Client直接与Identity Server完成授权交互 #

这个选择完全取决于你采用的架构模式，没有强制要求：

• 若采用BFF（Backend for Frontend）后端托管会话架构：不需要Angular侧直接对接Identity Server，所有OIDC交互全由ASP.NET Core后端完成，Angular仅和后端交互，认证状态通过HttpOnly安全Cookie传递，这种模式避免了令牌在前端存储的泄露风险，也是Duende官方推荐的SPA对接方案。
• 若采用纯前后端分离、前端直接持有令牌的架构：Angular需要引入oidc-client-ts这类合规的OIDC客户端库，配合PKCE校验直接和Identity Server完成授权码流程，这种模式下/signin-oidc回调归Angular侧实现，后端MVC不需要承载登录交互逻辑。
  注意两种模式不要混用，你当前已经实现了后端对接OIDC的逻辑，就不要额外加前端直连的逻辑，避免出现会话状态不同步的问题。

疑问四：用户执行登出操作时，ASP.NET Core MVC应用是否可以正确感知用户的认证状态变更 #

分两种场景判断：

• 如果登出操作是从你自己的MVC应用触发：只要正确调用OIDC中间件的SignOutAsync方法，同时登出本地认证Cookie和Identity Server的远程会话，MVC会立刻清除本地认证状态，可以正常感知状态变更。
• 如果登出操作是用户直接在Identity Server侧、或者其他接入同一个Identity Server的应用端触发：默认情况下MVC应用不会实时感知状态变更，因为本地认证Cookie有独立的有效期。要实现跨应用登出状态同步，需要配合Identity Server的后端会话回溯、前端定时轮询会话状态、短有效期Cookie加滑动刷新的机制实现。

疑问五：/signout-callback-oidc端点实际应当在哪里实现 #

这个端点的实现归属和/signin-oidc逻辑完全一致：

• 若采用BFF后端对接OIDC的架构：该端点同样是ASP.NET Core OIDC中间件自动注册的内置端点，部署在ASP.NET Core后端应用中，不需要手动编写Action实现，中间件会自动处理登出后的回调逻辑，完成本地会话清除。
• 若采用Angular直连OIDC的纯前端架构：该回调端点归Angular SPA侧实现，由前端OIDC客户端库负责处理登出完成后的状态清理、页面跳转逻辑。

内容的提问来源于stack exchange，提问作者Jawahar