Как создать токен с помощью Identity Server 4 для внешнего провайдера аутентификации

Question

Я создал приложение, используя библиотеку ID4, в котором могут войти два типа пользователей.

1. Внешний пользователь - эта информация пользователя хранится в членской базе данных pNet.
2. Внутренний пользователь - эта информация пользователя хранится в Azure Active Directory.

Предпосылки реализации: Я интегрировал Microsoft AAD для внешней аутентификации после того, как пользователь прошел валидацию из AAD и выполнить обратный вызов приложений, затем мы получаем требуемые заявки из Microsoft AccessToken и создаем новый AccessToken ID4.

Требование: Теперь мое требование заключается в создании AccessToken без какого-либо взаимодействия с пользователем (используя пароль тип предоставления), чтобы получить токен доступа, я использую конечную точку / connect / token , которая прекрасно работает для внешних пользователей , но единственная проблема в том, что я не могу использовать эту конечную точку получить токен для внутренних пользователей в качестве информации этого пользователя, хранящейся в Azure Active Direc а не в As pNet членство в БД. Поэтому всякий раз, когда я нажимаю / подключаю / к конечной точке токена, он проверяет данные пользователя в As pNet DB и всегда возвращает ответ «invalid_username_or_password».

Что я думаю:

Я могу создать новую пользовательскую конечную точку, которая будет проверять внутреннего пользователя с использованием LDAP или GraphAPI. Как только проверка пользователя пройдет успешно, я создам Access4oken ID4 (аналогично конечной точке / connect / token ). Пожалуйста, поправьте меня, если я что-то не так понял.

Буду признателен за любую помощь / помощь. Оставьте комментарий, если вы хотите понять его подробно или провести мозговой штурм со мной.

Answer 1

Вы можете использовать Учетные данные пароля владельца ресурса OAuth 2.0 в Azure AD . В вашем сценарии клиент отправит учетные данные пользователя на сервер идентификации, возможно с параметром, показывающим, какой поставщик идентификаторов (Azure AD / локальная база данных) пользователь хочет использовать. Если пользователь хочет использовать Azure AD, вы можете напрямую отправить учетные данные в Azure AD и создать токены IDS на основе идентификатора ID, возвращенного из Azure AD.

Но, как показывает документ, этот поток не рекомендуется :

Microsoft рекомендует не использовать поток ROP C. В большинстве сценариев ios доступны и рекомендуются более безопасные альтернативы. Этот поток требует очень высокой степени доверия к приложению и несет риски, которых нет в других потоках. Этот поток следует использовать только в том случае, если нельзя использовать другие более безопасные потоки.

И этот поток имеет ограничения в Azure AD:

• . Конечная точка платформы идентификации Microsoft поддерживает ROP C только для Azure клиентов AD, но не для личных учетных записей. Это означает, что вы должны использовать конечную точку c, определяемую арендатором (https://login.microsoftonline.com/ {TenantId_or_Name}), или конечную точку организации.
• Личные учетные записи, приглашенные в Azure AD арендатор не может использовать ROP C.
• Аккаунты без паролей не могут войти через ROP C. Для этого сценария мы рекомендуем вместо этого использовать другой поток для своего приложения.
• Если пользователям необходимо использовать многофакторную аутентификацию (MFA) для входа в приложение, они будут заблокированы вместо этого.
• ROP C не поддерживается в сценарии гибридной федерации удостоверений ios (например, Azure AD и ADFS, используемые для аутентификации локальных учетных записей). Если пользователи перенаправлены на полную страницу локальным поставщикам удостоверений, Azure AD не сможет проверить имя пользователя и пароль для этого поставщика удостоверений. Сквозная аутентификация поддерживается с ROP C, однако.