Нужно уточнить поток приглашения в WingTipGames

Question

Я создаю API для поддержки подготовки пользователей для других групп приложений в моей компании.У меня есть хорошее представление о пользовательских политиках, и я рассмотрел поток приглашений в WingTipGames, однако пример приложения порой бывает трудным для подражания, учитывая огромное количество функций, которые оно предлагает.Я был бы признателен за разъяснения относительно того, какие функции я могу игнорировать, по сравнению с тем, что требуется для поддержки моего варианта использования.

Вариант использования:

Метод CreateUser моего API создает пользователя в B2C с помощью ADGraph, затем следует создать ссылку приглашения, которая включает в себя подписанный JWT с адресом электронной почты пользователя, и, наконец, отправить электронное письмоссылка на получателя.Новый пользователь щелкнет ссылку, которая должна перенаправить его непосредственно в политику приглашений для сброса пароля.

Требуется уточнение:

Я борюсь с простым созданием ссылки на приглашения.То, что показано в примере, кажется слишком сложным для моего API.В общем, я запутался в настройке OIDC, учитывая, что сам мой API (хотя отдельно требуются вызывающие абоненты для аутентификации) вообще не будет задействован, когда получатель нажимает на ссылку приглашения.И поскольку это API, а не приложение MVC, мне интересно, можно ли сократить процесс по сравнению с потоком приглашений в WingTipGames.

• Почему ChallengeAsync вызывается в методе Invitation\Create?Предположительно, именно поэтому мы приземлимся на OnRedirectToIdentityProvider событие.Является ли задача чем-то перехваченным и переведенным в ссылку для приглашения?
• Уместны ли здесь классы в WingTipCommon?А именно, расширения, обработчик и промежуточное ПО AspnetCore.Authentication.OpenIdConnect.Запрашиваемая, потому что пользователи никогда не должны заходить в API в ответ на нажатие на ссылку приглашения, поэтому, возможно, дополнительная сантехника не нужна.
• Пользователи всегда будут в новом браузере и сеансе при нажатии на ссылку для погашения приглашения и будут перенаправлены непосредственно в политику (если я правильно понимаю).Мне все еще нужно беспокоиться об обработке skipCorrelation и XSRF?

Любые другие общие предложения относительно того, что извлечь из образца и что игнорировать для поддержки моего варианта использования, приветствуются.

Спасибо Марк

Answer 1

Приложение Wingtip Games реализует следующие потоки приглашений:

1. Пригласительная ссылка на конечную точку приложения . Эта ссылка для приглашения содержит адрес электронной почты приглашенного пользователя, срок действия приглашения и подпись на основе HMAC. Когда ссылка приглашения открыта, конечная точка приложения проверяет подпись на основе HMAC и срок действия приглашения и, если они действительны, то перенаправляет приглашенного пользователя на конечную точку политики. Это перенаправление политики содержит подписанный JWT с адресом электронной почты приглашенного пользователя.
2. Пригласительная ссылка на конечную точку политики . Ссылки для приглашения содержат подписанный JWT с адресом электронной почты приглашенного пользователя.

Я предпочитаю и рекомендую первый поток для приглашений, потому что конечная точка приложения может реализовать логику приглашения до запуска политики приглашения (например, конечная точка приложения может проверить срок действия приглашения и, если оно недопустимо, то может отобразить сообщение об ошибке), а также после запуска политики приглашения (например, конечная точка приложения может отображать сообщение об успехе).

Чтобы ответить на ваши конкретные вопросы:

Почему ChallengeAsync вызывается в методе Invitation\Create?

Это называется вторым потоком для приглашений. Он вызывается так, чтобы промежуточное ПО аутентификации могло генерировать ссылку для приглашения и отправлять сообщение с приглашением . Он реализован так, что логике приложения не нужно знать идентификатор приложения, идентификатор политики или URI перенаправления, которые требуются для ссылки приглашения.

Уместны ли здесь классы в WingTipCommon? 1035 *

Они используются для поддержки второго потока для приглашений. Смотрите следующий ответ.

Мне все еще нужно беспокоиться об обработке skipCorrelation и XSRF?

Это реализовано для второго потока для приглашений. В соответствии с политикой приглашения Azure AD B2C выдает ответ аутентификации клиентскому приложению, где этот ответ аутентификации обрабатывается промежуточным ПО аутентификации. Поскольку промежуточное программное обеспечение для аутентификации не вызывает политику приглашения (т. Е. Оно вызывается по ссылке приглашения), тогда промежуточное программное обеспечение для аутентификации должно быть настроено , чтобы отключить встроенные проверки для корреляции аутентификации. запрос с ответом аутентификации .