域名不一致情况下，使用LocalStorage存储token，如何防止XSS问题？

不好意思，最近忙着写新系统，这么晚才看到。新系统准备发布了，希望到时候对你也有帮助。

首先感谢认真的提问!

做好跨站脚本攻击的核心是要尽可能解决嵌入恶意脚本，如果这一块做好了，存储这一块其实就不是重点。理论上，后端开发这一块要有强烈意识。
在我最新要发表的作品中，其中已经有尽可能严格控制 param，并且严格控制 MVC 的参数只能在各自层级使用。
但是我们假设后端没做好防范，被植入恶意脚本，那 localStorage 确实不够安全，至少对比传统的 Cookie 是这样的，这个暂时无解，但是感觉安全性半斤八两。
还有就是作为产品经理，在核心逻辑，比如跟钱有关系的上面，最好是做好二次验证，避免可以直接触发接口行为。

不知道什么类型是传统架构，什么类型又是新型架构?这个我不理解。
目前我了解到的最新型的算是：Okta 了，这种我觉得挺好的，就是靠大环境决定，基本在国内比较难。
其他的翻来覆去都是一个样，如果硬要区分的就是：带不带用户体系。
比如 keycloak 就是带整套用户体系的，很多企业老板是不允许这样迁移的。
比如 cas 是不带用户体系的，也挺好的，痛点就是项目很大，但是就一个人维护，根本力不从心。
现在 Java 业界用的比较多的就是 Spring Security OAuth 了，TKey 本质其实和它一样，只是实现简单化，没那么多工程逻辑和考虑而已。
所有，有对比才有伤害。目前的业界感觉没啥特别有新意的，所以感觉没啥区别呀。你可以看下很多基于 Spring Security OAuth 的开源项目都是直接使用 password 模式，如果是 HTTPS 其实也没什么不可以的。所以，看下你们团队怎么想了，多几个肉眼看不到的跳转我是觉得无所谓的，不行 HTTPS 下的 password 也是可以的。没啥银弹，至少目前是。