如何通过外部IdentityServer的OAuth2保护Angular代码并实现API鉴权

核心选型建议 #

优先采用「NGINX OAuth2 代理 + 前端轻量适配」的方案，比自定义中间件稳定性更高，完全匹配你「服务器层做SPA资源访问控制、应用层不处理授权流程」的需求。

落地流程 #

1. NGINX层配置 #

• 所有静态资源请求先走OAuth2代理校验access_token有效性：无有效token时自动302跳转到IdentityServer完成认证，认证通过后再下发Angular应用代码。
• 配置透传响应头：认证通过后，把Authorization请求头里的access_token、以及token过期时间写入自定义响应头（比如X-Access-Token、X-Token-Expires）返回给前端。
• 后端API统一走NGINX反向代理：所有API请求自动走同一套OAuth2校验逻辑，无需额外做权限判断，也可直接透传Authorization头到后端服务。

2. 前端适配逻辑（无需完整引入OIDC授权流程） #

• 应用初始化时，直接从响应头中提取服务端下发的access_token，存入内存（不要存到localStorage/sessionStorage，降低XSS泄露风险），通过Angular HTTP拦截器统一挂载到API请求的Authorization头中。
• token过期处理：从X-Token-Expires头中拿到过期时间，提前30s触发静默刷新，直接调用OAuth2代理自带的刷新端点，无需跳转登录页即可拿到新token更新内存值；如果刷新失败（如refresh_token也过期），直接访问NGINX的认证触发路径，由服务端自动完成重定向登录，全程前端不需要处理授权跳转逻辑。

3. oidc-client使用建议 #

可以引入oidc-client的工具能力，不需要启用它的完整授权流程，只用来做JWT格式校验、过期时间计算、静默刷新的逻辑封装，比自己手写相关逻辑可靠性更高，避免踩JWT解析的边界问题。

现有自定义中间件方案的优化方向 #

如果不想切换到NGINX方案，可在现有中间件基础上补充两个接口即可：

• 新增/auth/refresh接口：处理token静默刷新，返回新的token和过期时间
• 新增/auth/logout接口：清理服务端会话，跳转IdentityServer登出页
  前端逻辑和上面的适配方案完全一致，无需额外修改。

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