API REST Outlook.com — получение токена без динамического входа

Вариант использования: электронные письма, которые должны быть отправлены из веб-приложения по событию, как [email protected] через MS Exchange или Outlook.com, используя RESTful API, предоставляемые Outlook.com. Разрешен только HTTP-доступ (=> нет SMTP/IMAP).

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

Но это не будет работать для фоновой задачи (=> вход невозможен!), где необходим предварительно созданный токен (с некоторой предопределенной областью действия), чтобы к Outlook.com можно было получить доступ через API для отправки почты как пользователь. @somedomain.com.

Любые подсказки / указатели на то, как это можно сделать? По сути, автоматическая аутентификация без явного входа в систему как «[email protected]» на странице входа в MS Online.

Я не нашел документацию M$, касающуюся API REST Outlook, которая могла бы помочь, и нашел ее довольно полезной. трудно ориентироваться/понимать. :(

Спасибо!


rest email outlook outlook-restapi outlook.com
person raghava    schedule 04.04.2016    source источник
comment
Я не знаю этот API в частности, но обычно вы должны зарегистрироваться и получить ключ API, который будет использоваться в вашем коде. Эта ссылка упоминает токен, который вы можете получить после регистрации вашего приложения, возможно, вам стоит попробовать это.   -  person cdelmas    schedule 04.04.2016
comment
@cdelmas, спасибо, я пробовал. По-видимому, единственный возможный способ — зарегистрировать приложение в Azure AD (и, при необходимости, ограничить количество пользователей, которые могут получить доступ к приложению, опять же на уровне Azure AD), а затем позволить пользователю войти в приложение и, таким образом, создать токен, срок действия которого снова составляет 90 дней.   -  person raghava    schedule 05.04.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

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

person Jason Johnston    schedule 04.04.2016
comment
Спасибо за информацию, Джейсон! Таким образом, нельзя использовать API-интерфейсы Outlook.com в корпоративном решении, поскольку нельзя заставить администратора/специалиста по обслуживанию входить в учетную запись службы каждые 90 дней (и повторно генерировать токены обновления). Есть ли планы по размещению токенов обновления, которые действуют в течение длительного времени, как это регулируется пользователем? Вариант использования включает не обычного пользователя, а учетную запись службы (для которой традиционно не устанавливается срок действия пароля и т. д.). - person raghava; 05.04.2016
comment
Насколько я понимаю, да, эти планы есть. Однако я обеспокоен тем, что неправильно вас понял. Учетные записи Outlook.com обычно не связаны с корпоративным решением. Вы используете Office 365 (бизнес/рабочие учетные записи) или Outlook.com (личные потребительские учетные записи)? - person Jason Johnston; 05.04.2016
comment
›› Однако я обеспокоен тем, что неправильно вас понял. Учетные записи Outlook.com обычно не связаны с корпоративным решением. Вы используете Office 365 (бизнес/рабочие учетные записи) или Outlook.com (личные потребительские учетные записи)? Вариант использования заключается в создании почтового компонента для нашего клиента с перечисленными ниже ограничениями. 1. Клиент (скажем, somecompany.com) хочет, чтобы электронная почта направлялась только через их корпоративный обмен MS. 2. Отметка отправителя на исходящих электронных письмах должна быть [email protected]. 3. Нет доступа SMTP/IMAP к обмену. допустимый. [продолж..] - person raghava; 06.04.2016
comment
Этот компонент рассылки будет использоваться (в фоновом режиме) корпоративной системой, которая будет рассылать электронные письма на внешние (@[^somecompany].) или внутренние (*@somecompany.com) адреса. Итак, нам нужно будет 1. создать одну учетную запись службы, [email protected], 2. создать приложение в Azure AD какой-либо компании, 3. ограничить доступ для приложения к адресу [email protected] 4. Заставить его войти в систему и получить токен обновления 5. Используйте этот токен обновления для создания токенов доступа, чтобы почтовый компонент мог отправлять письма. [продолжение ..] - person raghava; 06.04.2016
comment
Теперь для этого потока потребуется: 1. [email protected] входить на онлайн-страницу MS каждые 90 дней, повторно генерировать токен обновления и 2. сделать этот новый токен доступным для почтового компонента, чтобы он мог использовать токен и отправлять письма в фоновом режиме. Это было бы неприемлемо для корпоративного решения (я имею в виду обязательство входить в систему каждые 90 дней). :( Надеюсь, я ясно изложил свой вариант использования. Пожалуйста, дайте мне знать, что вы думаете. Еще раз спасибо за помощь! - person raghava; 06.04.2016
comment
Прежде всего, чтобы внести ясность, REST API работают только с Office 365 или Outlook.com, а не с локальными установками Exchange. Если это соответствует вашему сценарию, вам следует взглянуть на поток аутентификации учетных данных клиента. В этом потоке вы не создаете учетную запись службы, вы предоставляете разрешения самому приложению. Администратор организации соглашается с приложением, после чего вы можете получить токены в автоматическом режиме. См. blogs.msdn.microsoft.com/exchangedev/2015/01/21/ - person Jason Johnston; 06.04.2016
comment
@JasonJohnston Можно ли использовать подобное решение для локальной установки Exchange? REST API недоступен для Exchange? - person philgo20; 10.02.2017