1.Просто сделайте это, подход без изменений (не рекомендуется)
Вы можете попытаться получить токен, используя Resource Owner Password Granttials Grant.(ROPC может быть наименее безопасным из всех поддерживаемых различных грантов и несет потенциальные риски атак. Также обратите внимание, что ROPC не работает с MFA и имеет проблемы с пользователями федеративной аутентификации или может вообще не работать в этих случаях)
Я не думаю, что существует какой-либо метод / конечная точка, специально предназначенные для проверки имени пользователя / пароля , но обходной путь - если имя пользователя или пароль неверны, вы получите исключение из конечной точки токена, когдаиспользуя ROPC, в противном случае вы получите верный токен, который означает, что учетные данные хороши.
О том, как получить токен с помощью ROPC, можно прочитать здесь: Предоставление учетных данных пароля владельца ресурса в Azure AD OAuth
2.Предложенный подход, требуются некоторые изменения (рекомендуется)
Вначале это может показаться немного неудобным, но это будет стоить усилий с точки зрения безопасности.Обратите внимание, что этот подход, как и первый, удовлетворит ваше требование не проходить через обычную страницу входа в систему.
Поскольку, так сказать, «пользователя за рулем» нет, мы можемt используйте обычный метод, который показывает страницу входа в Azure (https://login.microsoftonline.com/{tenantId}).
Поскольку вы упоминаете, что автономный процесс подобен службе Windows или запланированной задаче, с точки зрения Azure AD и OAuth 2.0 ваш процесс выглядиткак сервис Daemon . Таким образом, вместо использования учетных данных имени пользователя / пароля непосредственно из конфигурации, что нарушает рекомендации по безопасности, вам следует обратить внимание на использование Client Credentials Grant. Настоятельно рекомендуется НЕ собирать / управлять / хранитьУчетные данные конечного пользователя (или создание учетных записей старых служб) непосредственно в ваших приложениях.
Подробнее об этом можно прочитать здесь: Предоставление учетных данных клиента OAuth 2.0 с Azure AD .
Также посетите эту документацию для всех типов приложений и сценариев Azure AD, указанныхТе, которые перечислены для приложений Daemon. Ссылка
Короче говоря, ваш процесс представлен зарегистрированным приложением в Azure AD, а для части учетных данных вы можете использовать:
a.Идентификатор клиента + секретный ключ клиента (предоставляется Azure AD специально для вашего приложения. Вы можете создать более одного секретного ключа для разных целей с различным сроком действия и т. Д.). Пример кода C # с Client Secret
b.Идентификатор клиента + сертификат (передайте JWT, который вам нужно создать, и подпишите с помощью сертификата, зарегистрированного в качестве учетных данных для вашего приложения). Образец кода C # с сертификатом