在ASP.NET Core中,通过将身份验证转发到另一个方案,可以在一个方案中抢占新用户吗？

Question

由于我们的应用程序的性质,我们可以让用户通过大量的auth提供程序进入,其中一些使用OAuth 1.0(特别是LTI).每当我们不识别登录然后不得不处理复杂的身份合并时,我们不想总是创建一个新的用户帐户,我们希望邀请显然是新用户通过OpenID识别自己(Google和Microsoft主要是因为这涵盖了我们的大多数用户.)我们可以问他们他们的U/P,除了我们不做U/P - 我们总是倾向于只支持通过第三方身份提供商登录,并且真的不想改变它.

因此情况将是我们的自定义身份验证方案(LTI/OAuth1.0)收到第三方声明,确定这些声明对我们的系统是新的,然后将挑战转发给我们的默认身份验证方案.完成该方案后(成功的auth或用户拒绝(即NoResult))我们理想情况下将返回原始方案,以完成使用提供的声明创建新用户或向现有用户添加其他登录.完成所有这些操作后,将返回最终的AuthenticationTicket,并且请求将在进行身份验证后正常进行.

我可能会想到这一切都是错的,如果是这样的话,我很乐意接受更好的指导.但基本的业务要求是,我不希望在为传入的个人提供通过其他登录方法将自己标识为现有用户的机会之前创建新用户.

目标环境是ASP.NET Core 2.0或2.1.

Answer 1

当您选择从第 3 方提供商登录时，ASP.NET Core 文件 -> 新项目模板（当您选择第 3 方身份验证时）会执行类似的操作。它将第 3 方声明存储在 cookie（签名）中，并将您带到注册页面。一旦您提交表单，它就会从此 cookie 中获取声明以及注册详细信息，在数据库中创建用户，删除此临时 cookie，并发出其他所有内容都会查看的真实身份验证 cookie。为了减轻重放攻击，这个中间 cookie 只是一个会话 cookie，并且会在很短的时间（我认为是 5 分钟）后过期。您绝对走在正确的道路上。