Office 365 与 Outlook OAuth2 offline_access 与 refresh_token 请求不一致答案

【问题标题】：Office 365 vs. Outlook OAuth2 offline_access inconsistencies with refresh_token requestsOffice 365 与 Outlook OAuth2 offline_access 与 refresh_token 请求不一致
【发布时间】：2017-03-11 05:53:39
【问题描述】：

我正在开发一个 Web 应用程序，该应用程序应该为具有 Outlook 或 Office 365 帐户的用户访问联系人和其他信息，但我在离线访问 Office365 帐户时遇到了一些问题。

在初始身份验证后，代码运行良好，我可以访问 Outlook 和 Office 365 帐户所需的一切。

在初始访问令牌过期后出现不一致。对于 Outlook 帐户，我始终可以刷新访问令牌，而对于 Office 365 帐户，完全相同的代码失败并出现“400 Bad Request”错误。

感觉在刷新访问令牌时应该为 Office 365 帐户做一些不同的事情，但我不知道是什么......我什至不知道如何判断用户是否使用过 Otlook 和 Office 365 帐户我以后可以弄清楚这一点。

我使用的授权 URL 是 https://login.microsoftonline.com/common/oauth2/v2.0/token，我认为 Outlook 和 Office 365 可能应该有所不同，但除了 refresh_token 请求之外，其他一切似乎都适用于这两种帐户类型。

感谢您的帮助！谢谢！

【问题讨论】：

您能发布一个示例刷新请求吗？也许我们可以发现问题所在。
好的，谢谢！现在我觉得自己很愚蠢，但我已经解决了这个问题。原来刷新请求中发送的redirect_url 不包含我的主机名。 ... 有趣的是，对于 outlook.com 帐户，这似乎根本不重要，而对于 Office365 帐户，这是一个问题。奇怪....
嗯，好的，是的，最好在此处包含整个 URL :)。您应该将其发布为答案。

标签： oauth-2.0 outlook-restapi office365-restapi

【解决方案1】：

这很奇怪，但问题的解决方案是确保刷新令牌请求中使用的 redirect_url 参数与注册的重定向 url 完全匹配，包括主机名。

令人惊讶的是，这仅适用于 Office 365 帐户并且仅适用于刷新令牌请求。看起来 Outlook 和 Office 365 帐户的所有其他 API 都不关心提供的重定向 URL，而是使用为应用注册的任何内容。

【讨论】：