Токен доступа и аутентификация для гостевого пользователя

Question

TLDR: возможно ли иметь гостевую учетную запись, например guest@organization.onmicrosoft.com, в облаке MS Office 365 компании, которая будет иметь разрешение на «чтение» для календарей и событий пользователей организации с маркером постоянного доступа? Под токеном постоянного доступа я имею в виду, что я один раз регистрируюсь для этого гостевого пользователя и получаю токен постоянного доступа из Azure AD (например, для аутентификации доступа к приложению, но в качестве гостевой учетной записи).

У меня есть учетная запись MS Office 365 моей компании с несколькими пользователями. Существует одна глобальная учетная запись администратора и несколько постоянных пользователей. Есть вторая компания, назовем это XYZ, со своей собственной учетной записью MSO365 со многими администраторами и пользователями. Большая компания.

Сейчас я пишу простое приложение, в котором мне нужен доступ для чтения календарей и событий пользователей компании XYZ. У меня есть список необходимых пользователей в моем приложении с правильными идентификаторами MSO365. Я думаю, что привилегии «чтения» достаточно, поскольку мы можем отправлять приглашения на мероприятия через обычное электронное сообщение. Мое приложение будет читать пользовательские события через MS Graph API и т. Д. С некоторой логикой и публиковать их (отправлять приглашения на события и т. Д.) С заданиями CRON.

А вот и моя проблема с аутентификацией. Я не хочу иметь права доступа к приложению Azure AD в моем приложении. Я знаю, что политика безопасности компании XYZ не будет применяться, поскольку «доступ к приложениям» дает доступ ко всем учетным записям в организации. Доступ к приложению означает, что глобальный администратор компании XYZ применяет привилегии приложения для моего Приложения путем единого входа в Azure AD. Если он это делает, у меня есть токен доступа, который я могу использовать для вызовов API в моем приложении без необходимости дополнительной аутентификации.

Я также не могу использовать аутентификацию Azure AD "пользовательский доступ". Из-за моих заданий CRON и вызовов API, которые запускаются тогда Доступ пользователя означает, что пользователь должен войти в службу входа Azure AD, что дает мне токен доступа и токен обновления для вызовов API. Срок действия этих токенов составляет 1 час.

Так что я подумал: есть ли возможность иметь гостевую учетную запись в MSO365 компании XYZ, которая позволила бы мне использовать механизм аутентификации, такой как «доступ к приложению»? Под этим я подразумеваю, что глобальный администратор компании XYZ создает мне гостевую учетную запись, такую ​​как guest@xyz.onmicrosoft.com, которая будет иметь доступ для чтения календаря пользователей и событий. Более того, мне нужна эта учетная запись, чтобы иметь токен постоянного доступа, который я могу использовать в вызовах API моего задания cron без необходимости входа в Azure AD.

Вопрос: возможно ли это? Если да, то как это сделать?

Answer 1

Единственный способ (AFAIK) - использовать токены обновления. Доступ на уровне приложений более надежен, но требует доступа в масштабе всей организации.

Таким образом, вы используете делегированный доступ (пользовательский доступ), где-то храните токены обновления. Вы можете использовать эти токены в основном на неопределенный срок, однако некоторые события могут истечь токен обновления. Это случается не часто, но может случиться. В этом случае вам потребуется снова войти в систему, чтобы вы могли получить новый токен обновления. Вам также следует сохранить новый токен обновления, полученный при получении токенов с использованием токена обновления. Этот новый токен может перезаписать старый токен для этого пользователя.

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

Если нам не удастся получить токен в фоновом процессе, этот пользователь получает установленный флаг, что его токен не работает, и они получат уведомление о необходимости повторной аутентификации для возобновления работы функции.