Получить код авторизации OAuth 2.0 без участия пользователя - PullRequest
Новая
       31

Получить код авторизации OAuth 2.0 без участия пользователя

1 голос
/ 07 июня 2019

Я пытаюсь создать рабочий процесс с помощью Microsoft Flow. Некоторые из моих шагов - выполнение HTTP-запросов с использованием Microsoft Graph API. Проблема, с которой я сталкиваюсь, состоит в том, что некоторые API не поддерживают тип разрешения приложения, а скорее делегированы. Я пытаюсь создать план в Microsoft Planner ( см. Эту ссылку ). В этом сценарии я создал учетную запись службы, которая будет выполнять определенный рабочий процесс, и на стороне приложения Azure AD я предоставил разрешения от имени пользователя как администратора.

Поскольку я должен выполнить определенные HTTP-запросы как «пользователь», я пытаюсь получить токен авторизации пользователя, здесь есть два шага:

  1. Получить код авторизации
  2. Получить токен на основе кода авторизации

Я не могу пройти Шаг 1. Я следую этой документации: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow и каждый раз, когда я пытаюсь выполнить следующий HTTP-запрос: 

GET https://login.microsoftonline.com/{my-tenant-id}/oauth2/v2.0/authorize?
client_id={my-client-id}
&response_type=code
&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fnativeclient
&response_mode=query
&scope=Group.ReadWrite.All

Я использую обычную аутентификацию, передавая имя пользователя и пароль. Но я получаю ответ: «Мы не можем войти в систему, ваш браузер в настоящее время настроен на блокировку файлов cookie». Ну нет браузера это сервисный аккаунт. Я что-то упускаю или то, чего я пытаюсь достичь, невозможно, и у меня должно быть веб-приложение? Microsoft сделала соединители, которые используют API Планировщика, но они сделали все, кроме соединителя, чтобы планировать в планировщике ...

EDIT:

Мне известно, что проблема аналогична этой теме здесь , но в ответе в этой теме говорится об использовании «Авторизации приложений», на которую Microsoft специально указала в своей документации, что в этом сценарии вы не можете. Мне известно о том, что мне нужны реальные разрешения пользователя, поскольку разрешен только тип разрешения

Делегированный (рабочий или учебный счет)

именно поэтому конкретная тема не отвечает на мой вопрос, поскольку этот ответ указывает на разрешение приложения, которое не поддерживается в этом сценарии.

1 Ответ

1 голос
/ 07 июня 2019

Я думаю, что вы столкнулись с проблемой, потому что Поток предоставления кода авторизации предназначен для работы с взаимодействием с пользователем , т. Е. Пользователь перенаправляется на страницу входа для интерактивного ввода учетных данных. Вы можете прочитать больше об этом в этой связанной публикации SO OAuth2 - Авторизация без взаимодействия с пользователем (это не относится только к Azure AD, но в целом относится к потоку предоставления кода авторизации OAuth 2.0.

Альтернатива

  1. Поток предоставления учетных данных клиента

    Это был бы идеальный и лучший выбор для любого фонового процесса / процесса демона, но он будет работать с разрешениями приложения. К сожалению, API, который вы пытаетесь использовать, работает только с делегированными разрешениями, как вы упомянули, поэтому этот грант не будет работать.

  2. Поток предоставления пароля владельца ресурса (это может работать, но нарушает рекомендации по безопасности и имеет функциональные проблемы)

    ROPC работает напрямую с учетными данными пользователя (т. Е. Ваш код имеет прямой доступ к имени пользователя и паролю, что ни в коем случае не является хорошей практикой) и не требует явного взаимодействия. Несмотря на то, что это может сработать, имейте в виду, что этот грант нарушает многие рекомендации по безопасности и имеет функциональные ограничения (например, не работает с многофакторной аутентификацией или с личными учетными записями).

    См. Это SO Post , где я рассмотрел их немного подробнее. Обычно я бы воздерживался от упоминания этого гранта, но я не вижу другого гранта, работающего в вашем случае, и это единственная причина для его включения.

    Пример запроса 

     // Line breaks and spaces are for legibility only.

 POST {tenant}/oauth2/v2.0/token
 Host: login.microsoftonline.com
 Content-Type: application/x-www-form-urlencoded

 client_id=6731de76-14a6-49ae-97bc-6eba6914391e
 &scope=user.read%20openid%20profile%20offline_access
 &username=MyUsername@myTenant.com
 &password=SuperS3cret
 &grant_type=password

  3. Использование токена обновления (может работать, но также хрупко и больше похоже на обходной путь)

    При таком подходе вы можете сначала получить токен refesh, используя служебную учетную запись. Вам нужно будет сделать это отдельно от общей работы приложения, скажем, как часть начальной настройки и взаимодействия с пользователем.

    Затем вы можете приобрести токен на основе этого токена обновления. Жетоны обновления могут быть аннулированы или истекли. Поэтому вам нужно знать, как долго действует токен refesh и события, когда он может стать недействительным. Такое событие, как смена пароля, также может сделать недействительным существующий токен обновления. Кроме того, вам необходимо защитить токены обновления как конфиденциальную информацию (почти как сам пароль)

Итак, AFAIK, я предлагаю только несколько плохих вариантов, т. Е. 2 ​​и 3. К сожалению, API, не поддерживающий разрешения для приложений, выбирает хороший вариант.

...