很抱歉我没能早点回复。我能想到的一种方法是在每个 Angular SPA 和遗留系统中嵌入一个 iframe,从另一个系统加载接收页面。这个接收页面的作用是让用户登录/退出其他系统。此外,您不想将 JWT 或任何敏感信息存储在公用文件夹中;将 localStorage 用于 JWT,将会话保持在客户端级别就足够了。
有关实施 iframe 的信息,您可以参考https://jcubic.wordpress.com/2014/06/20/cross-domain-localstorage/
让我们看看以下场景。根据您实施身份验证的方式,这些可能需要进行一些修改才能应用:
场景 1:用户登录 Angular 应用程序
当用户登录到您的 Angular SPA 时,通过旧版 API 进行的身份验证会返回一个 JWT 并存储在 localStorage 中。每次用户通过您的 Angular 应用程序发出请求时,JWT 都会通过您的 Authorization 标头发送,以便识别用户。
现在,当登录后返回 JWT 时,向嵌入式 iframe(指向您的旧接收页面)发送登录消息,以便接收页面在您的旧域上创建用户会话/cookie。您应该将 cookie 设置为与您的 JWT 具有相同的过期时间。
场景 2:用户退出 Angular 应用程序
从本地存储中删除 JWT。向您的 iframe 发送消息,以便在您的旧域中销毁用户的会话 cookie。
场景 3:用户登录旧版
您将需要稍微修改登录名。当用户登录到你的遗留系统时,你还需要生成一个 JWT,并在登录成功时返回到页面。通过您的嵌入式 iframe(现在指向您的 Angular 应用程序)发送一条消息,以将您的 JWT 保存在您的 SPA 域中的 localStorage 中。
您不必在 Angular 端创建用户会话,因为 JWT 就足够了,但请记住,用户会话到期时间应该与您的 JWT 到期时间同步。
场景 4:用户退出旧版
通过 ifame 向您的 Angular SPA 发送消息,以从 localStorage 中删除 JWT。同样,您无需担心 Angular 端的用户会话,因为您已经在使用 JWT 进行授权。
关于安全的一些话
显然,要实现这种 iframe 方法,如果您的站点位于不同的域中,则需要启用 CORS。确保您实施了适当的安全措施,以防止诸如 XSS 或嵌入 iframe 等漏洞在不允许的域中加载您的网站。
此外,当我使用 JWT 时,我会生成一个 id (JTI) 并将其作为 JWT 有效负载的一部分,并将散列后的 JTI 存储为 cookie。这样,每当用户使用 JWT 发出请求时,我都可以检查浏览器是否有 JTI cookie,并确保用户不只是窃取 JWT 以在另一台机器上使用。
如果您还有其他问题,请告诉我!