Из-за характера нашего приложения у нас могут быть пользователи, входящие через большое количество поставщиков аутентификации, некоторые из которых используют OAuth 1.0 (в частности, LTI). Вместо того, чтобы всегда создавать новую учетную запись пользователя всякий раз, когда мы не распознаем логин, а затем иметь дело со сложным слиянием удостоверений позже, мы хотим предложить явно новым пользователям идентифицировать себя с помощью OpenID (Google и Microsoft прежде всего потому, что это касается большинства наших пользователей.) Мы могли бы запросить у них их U/P, за исключением того, что мы не делаем U/P - мы всегда предпочитали поддерживать вход только через сторонних поставщиков удостоверений и на самом деле не хотим изменить это.
Таким образом, сценарий может заключаться в том, что наша настраиваемая схема проверки подлинности (LTI/OAuth1.0) получает утверждения третьих сторон, определяет, что эти утверждения являются новыми для нашей системы, а затем перенаправляет запрос в нашу схему проверки подлинности по умолчанию. После завершения этой схемы (либо успешной аутентификации, либо отказа пользователя (т. е. NoResult)) мы в идеале вернемся к исходной схеме, чтобы завершить либо создание нового пользователя с использованием предоставленных утверждений, либо добавление дополнительного входа в систему для существующего пользователя. Как только все это будет завершено, будет возвращен окончательный AuthenticationTicket, и запрос будет выполняться как аутентифицированный.
Я могу думать об этом неправильно, и если это так, я был бы рад, если бы меня направили в лучшем направлении. Но основное бизнес-требование заключается в том, что я не хочу создавать нового пользователя до того, как предоставлю входящим лицам возможность идентифицировать себя как существующих пользователей с помощью другого метода входа в систему.
Целевая среда — ASP.NET Core 2.0 или 2.1.
