In ASP.NET Core, can new user creation be pre-empted in one scheme by forwarding authentication to another scheme?

Question

Due to the nature of our application we can have users coming in via a wide number of auth providers, several of them using OAuth 1.0 (specifically, LTI). Rather than always creating a new user account whenever we don't recognize a login and then having to deal with complex identity merges later, we want to invite apparently new users to identify themselves via OpenID (Google and Microsoft primarily since that covers most of our users.) We could ask them for their U/P, except we don't do U/P - we have always preferred to only support login via 3rd party identity providers and don't really want to change that.

So the scenario would be that our custom authentication scheme (LTI/OAuth1.0) receives the 3rd party claims, determines that these claims are new to our system, and then forwards a challenge to our default auth scheme. Upon completion of that scheme (either successful auth or the user declining (i.e. NoResult)) we would ideally return to the original scheme to complete either creating a new user using the provided claims or adding an additional login to the existing user. Once all of that was complete, the final AuthenticationTicket would be returned and the request would proceed normally as authenticated.

I may be thinking about this all wrong, and if so I would be glad to be guided in a better direction. But the basic business requirement is that I don't want to create a new user prior to giving incoming individuals the opportunity to identify themselves as existing users via another login method.

Target environment is ASP.NET Core 2.0 or 2.1.

Answer 1

The ASP.NET Core file -> new project template (when you pick 3rd party auth) does something similar when you choose to login from a 3rd party provider. It stores the 3rd party claims in a cookie (signed) and hands you to the registration page. Once you submit the form, it grabs the claims from this cookie together with the registration details, creates the user in the database, nukes this temporary cookie, and issues the real auth cookie that everything else looks to. To mitigate replay attacks, this intermediate cookie is only a session cookie and expires after a short time -- 5 minutes, I think. You're definitely on the right track.