Я создал приложение Azure. После предоставления пользователем разрешения (раз в жизни) мой код Azure + JS извлекает данные почтового ящика Outlook с помощью graphAPI + accessToken.
Учетная запись Microsoft является частью моей организации (office365). Итак, когда я захожу на свой сайт (который использует код APP плюс JS для отправки graphAPI).
Если пользователь уже вошел в систему, я отключил дополнительную страницу входа.
Обратитесь к как подавить экран входа в систему при аутентификации Azure AAD Спасибо @juunas
Но если пользователь НЕТ предварительно вошел в учетную запись office365, пользователь будет перенаправлен на учетную запись office365. Я не хочу, чтобы мой пользователь видел эту страницу входа каждый раз, когда пользователь не вошел в систему заранее. Пользователь авторизовал это приложение, и это не очень удобно для пользователя.
Я просмотрел документацию, в которой говорится, что это возможно с помощью ADAL.js, но я не смог найти там свой точный вариант использования. Может ли кто-нибудь объяснить / направить меня к правильному ответу на мою проблему?
Жаль, что я не получаю уведомлений для @, но я смотрю этот тег, поэтому не беспокойтесь, я увижу вопрос: D
Пользователь должен уже войти в AAD, чтобы пропустить экран входа в систему. В противном случае вы не сможете его пропустить.
ADAL.js здесь не поможет?
ADAL.js может выполнять автоматический вход со скрытым фреймом iframe, но для этого требуется, чтобы у пользователя был активный сеанс, а также вы знали имя пользователя. Если вы вызовете ADAL.js collectToken (), он автоматически получит новый токен с помощью этого метода, если это необходимо.
Это означает, что я должен предоставить пользователю 2 логина: один для использования моего веб-сайта, а второй - для входа в aad, который получит мне необходимые данные. Нет вариантов?
Умм, давайте сделаем шаг назад :) Похоже, вы хотите, чтобы приложение само получало доступ к их данным. Для этого есть два возможных подхода. Оба требуют использования серверной части (вы не можете действовать как приложение из собственного приложения). Первый вариант - использовать токен обновления. Во-вторых, использовать учетные данные клиента. Первый вариант сложнее и немного более хрупкий, но следует принципу наименьших привилегий. Там ваш поток будет выглядеть следующим образом: логин + согласие + получение токена для вашей серверной части + обратный вызов + токен обмена для токенов на необходимый вам API. Надежно храните возвращенный токен обновления и используйте его в следующий раз, когда вам понадобится новый токен API.
Второй вариант - это учетные данные клиента, при этом ваша серверная часть должна требовать разрешения приложения вместо делегированных разрешений. Когда администратор соглашается на это, ваша серверная часть может использовать свой идентификатор клиента и секрет, чтобы получить токен, когда захочет. Хотя токены обновления могут истекать и зависят от пользователя, этот доступ необходимо явно отозвать, чтобы он был более надежным. Но это также доступ в масштабах всей организации, так что это обратная сторона.
Позвольте нам продолжить обсуждение в чате.
@juunas, не могли бы вы мне помочь?