对不起，这里没有代码，因为我正在寻找一个更好的主意，或者如果我在正确的轨道上?
我有两个网站，分别叫它们A和b。
A是一个暴露在互联网上的网站，只有拥有有效账户的用户才能访问。
B是一个内部(intranet)网站(使用Active directory进行Windows身份验证)。我希望应用B(内部网)为应用a创建用户
应用程序A正在使用内置的ASP。. NET JWT令牌认证
我的想法是在外联网网站(a)上公开一个Api，并让(B)访问这个Api。我可以使用CORS来确保只有(B)可以访问端点，但我不确定这是否足够好的保护?我们将从第三方公司执行安全渗透测试，所以这可能无法通过安全测试?
或
我可以使用实体框架手动更新AspnetUsers表。我不知道这样做是否可行，是否正确。
还有其他解决方案吗?
在我看来，不要将您的内部义务暴露给外部解决方案，如实现api等…
仅共享数据库通过这种方式，服务器管理是唯一的安全问题，没有人知道你是如何工作的。此外，如何实现每个用户身份验证(无论是Windows身份验证还是JWT)并拥有独立的基础设施并不重要。
对于这个问题有多种解决方案。然后它结束，这真的取决于你的具体标准。
可以这样写:
- B(内部网)网站，进入数据库并根据需要创建用户。
- 一个(internet)网站，有一个API暴露必要的端点来创建用户。
- 一个(internet)网站，不时运行数据迁移以插入用户。
但人生总有起起落落，我试着给你讲讲。
API解决方案Ups:
- 单一的责任，你只有一段代码接触这个数据库，这使得它更容易减轻副作用
- 它是"面向未来的";使用这个api，你可以很容易地拥有更多的服务。
唐斯:
- 攻击面增加，API是公开的，所以受到第三方试图玩它。
- 在数据库模型更改时维护API(多一件要维护)
- 不是最快的解决方案。
数据库直接访问
Ups:
- 攻击面最小。
- 快速开发
唐斯:
- 数据库模型需要维护两次
- 迁移和部署必须协调，难以维护。
- 使系统更容易出错
发布时迁移
Ups:
- 开发成本最低
- 插件的最高性能
唐斯:
- 不灵活的 非常慢许多部署
- 手工作业(随着时间的推移成本会增加)
在我看来，我建议您使用API，使用OAuth机制保护API访问。它OAuth太耗时，无法放置到位。也许你可以尝试一些更简单的认证协议。