Блог

Я запрашиваю следующие области (URL в кодировке):

 offline_access user.read https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/SMTP.Send
 

Процесс авторизации с помощью OAuth 2.0 с использованием нового Microsoft Graph API, похоже, работает нормально, но при использовании токена доступа для подключения к IMAP через XOAuth2 я получаю NO AUTHENTICATE , что указывает на недопустимость токена.

Оказывается, это проблема не с пользователем, а с Graph API от Microsoft. Хотя это не задокументировано, в настоящее время вам не разрешено запрашивать токен с областью, которая подпадает под двух клиентов, или он выберет один и завершится без сбоев.

В этом случае User.Read подпадает под действие Microsoft Graph tenancy. С технической точки зрения, если ваш пользователь является организационным пользователем Outlook / Office365, у них, вероятно, на самом деле не установлен Microsoft Graph, и правильная область будет https://outlook.office.com/User.Read . Однако конечная точка профиля Outlook устарела и ее не рекомендуется использовать (у вас также нет возможности узнать, имеет ли ваш пользователь MS Graph tenancy). Похоже, это решает проблему, user.read разрешение можно запросить без указания URL-адреса Microsoft Graph.

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

Поскольку это не разрешено, он автоматически завершается сбоем и по умолчанию используется клиент по умолчанию. С большинством их API это все еще работает, но, в частности, с IMAP / SMTP вы не можете запросить ключ большей области / мультитенанта, иначе он не будет проверяться через XOAuth2. Вы заметите, что токены доступа, возвращаемые только для IMAP / SMTP, всегда намного меньше, чем токены доступа для других областей.

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

 offline_access https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/SMTP.Send
 

После этого вам необходимо запросить токен доступа для профиля. Однако с октября 2020 года вам больше не разрешается использовать один код авторизации для предоставления токенов множественного доступа. Таким образом, вам нужно будет войти в систему пользователя еще раз — канонический способ сделать это — просто вернуть его обратно к URL-адресу авторизации, оставив login_hint поле пустым. Это будет зависеть от того, как вы создаете свой URL-адрес, но вот пример в JS:

 url = 'https://login.microsoftonline.com/common/oauth2/v2.0/authorize?'
url  = `client_id=${clientId}`
url  = 'amp;response_type=code'
url  = 'amp;redirect_uri=${redirectURI}'
url  = 'amp;response_mode=query'
url  = 'amp;login_hint='
url  = 'amp;scope=offline_access User.Read https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/SMTP.Send'
url  = 'amp;state=12345
 

Обратите внимание, что ваш код авторизации должен запрашивать полную область (включая обе User.Read области и области IMAP, например IMAP.AccessAsUser.All , для обоих запросов маркеров доступа. Указание меньшей области не гарантирует, что профиль, который вы читаете, обязательно будет соответствовать учетной записи Outlook.

После получения этого второго кода авторизации (он не будет запрашивать у пользователя повторный вход в систему вручную, просто загрузите немного и автоматически разрешите второй код) вы можете запросить новый токен доступа со следующей областью:

 user.read
 

Вы можете включить любые другие области Graph API выше, но указание чего-либо в Outlook и особенно в IMAP приведет к путанице в ваших областях. Область ответа по-прежнему будет содержать области доступа EAS и Outlook, но с добавлением user.read разрешения.

Вы должны использовать этот второй токен для доступа к профилю и обновлять его отдельно от первого токена (который следует использовать только для IMAP / SMTP).