如何在两个MVC Web应用之间传递token/授权凭据

跨应用传递身份凭证的核心原则是不传输长期有效密钥、最小化跨环境流量、严格权限隔离，结合你提到的客户资源独立订阅留存、流量成本控制的要求，以下是可直接落地的方案，按推荐优先级排序：

方案1：短期一次性换票跳转（最推荐，安全无额外成本） #

绝对不要直接把长期有效的Authorization Token拼接在跳转URL中传递，这类操作会导致token被浏览器历史、服务器日志、Referrer头泄露，风险极高。一次性换票的实现逻辑完全规避这类问题：

• 用户在主门户完成身份校验、选定要跳转的目标客户应用后，主门户使用和目标应用提前约定的独立对称密钥（每个客户应用单独配置一份密钥，统一存在你的管控配置存储中，不需要跨订阅传输密钥），生成有效期15-30秒、仅可使用一次的加密JWT票据，票据内仅包含用户claims、目标应用标识、时间戳、过期时间，不携带长期有效token
• 主门户返回302响应，将用户跳转到目标应用的专用换票接口，例如https://{customer-app-domain}/auth/sso-exchange?ticket={one-time-ticket}
• 目标应用收到请求后，首先校验票据签名合法性、是否在有效期内、是否已经被使用过（可在目标应用本地设置1分钟过期的缓存存储已使用票据ID，防重放攻击），校验通过后目标应用直接基于票据内的用户claims，生成本应用范围内有效的Authorization Token，写入本地会话Cookie后重定向到应用首页
• 整个流程仅产生一次302跳转的极小流量，不需要跨订阅打通网络，客户资源完全留存于所属订阅内，几乎没有额外流量成本

方案2：Azure AD原生跨应用SSO（零自定义安全逻辑，适合已接入AAD的场景） #

如果你的统一门户和所有客户应用都接入Azure AD做身份管理，可以直接用平台原生能力实现，不需要自行开发凭证传递逻辑：

• 将统一登录门户、所有客户独立应用全部注册到同一个Azure AD租户下，为每个应用配置合法的重定向URI
• 用户在主门户完成AAD登录后，跳转目标应用时直接走OAuth2.0授权码流程，因为用户已经在同AAD租户下留存有效登录会话，AAD会直接向目标应用返回授权码，不需要用户二次输入凭证
• 目标应用用授权码兑换自身应用的访问token、建立本地会话即可
• 流程中产生的流量仅为和AAD端点交互的身份校验小数据包，流量成本可忽略，所有安全校验逻辑由Azure托管，不需要自行处理加密、防篡改逻辑

方案3：根域Cookie共享（适合所有应用归属同一根域名的场景） #

如果你的统一门户和客户应用都部署在同一个根域名下（例如主门户为portal.yourdomain.com，客户应用为{customer-id}.yourdomain.com），可以用根域Cookie实现无感知跳转：

• 用户在主门户登录完成后，将加密后的会话标识写入.yourdomain.com根域级别的Cookie，强制开启HttpOnly、Secure、SameSite=Lax属性，防范XSS、CSRF攻击
• 用户跳转子域名下的客户应用时，浏览器会自动携带该根域Cookie
• 目标应用读取Cookie中的会话标识后，到你主订阅下的统一会话存储校验会话有效性，拿到用户claims后生成本地应用的有效token和会话
• 注意不要给客户应用开放根域Cookie的写入权限，会话存储需要配置IP白名单，仅允许你管控的应用端点访问，避免单客户应用被攻破后影响全局身份体系

❗ 禁止操作清单

• 禁止将长期有效Authorization Token直接放在URL参数、前端localStorage/sessionStorage中通过postMessage跨域传递，泄露风险极高
• 禁止为了传递token打通跨订阅VNet对等连接，这类操作会产生持续的跨订阅/跨区域流量费用，完全没有必要
• 禁止在传递的凭证中省略签名校验、过期校验、重放校验逻辑，避免身份伪造风险

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