【问题标题】：Refresh token not returned for Office365 accounts purchased through GoDaddy通过 GoDaddy 购买的 Office365 帐户未返回刷新令牌
【发布时间】：2017-05-04 15:43:57
【问题描述】：

背景

我们有一项功能，可以使用here 概述的 Office365 REST api 在我们的应用程序和 Office365 之间同步日历条目和联系人。我们正在使用 API 的版本 1。对于授权，我们通过 Azure AD 执行授权，大纲为here。

问题

在正常情况下（使用直接从 Microsoft 购买的 Office365 帐户时），我们的系统按预期工作：我们能够在用户令牌过期时刷新它们，并返回一个新的访问和刷新令牌作为交换。

在第二种情况下，当使用 Office365 帐户purchased via GoDaddy 进行测试时，我们遇到了可以在这一系列步骤中概述的阻塞问题： 1.用户是从我们的应用程序-> Office365登录页面发送的。 2. 用户输入电子邮件地址 3. 用户被重定向到 GoDaddy Office365 登录页面。 4. 用户完成授权，并在响应中使用访问代码重定向回我们的应用程序。 5. 应用程序从 Office365 交换 access_token 和 refresh_token 的访问代码。 6.一段时间过去了，access_token过期了 7. App使用refresh_token刷新用户的access_token

预期行为

此时，我们希望收到一个新的 access_token 和一个新的 refresh_token，就像我们在使用常规 Office365 帐户时所做的那样

实际行为

仅对于通过 GoDaddy 购买的帐户，我们不会在第一次刷新后的响应中收到新的刷新令牌。

显然，当打算进行长时间运行的同步时，这是一个突破性案例，因为用户将无法再刷新他们的令牌。

Postman 跟踪（可以保存为 .json 并导入 Postman 进行调试 https://gist.github.com/drunkel/7ec66ed33f66d0070148694651699d03（ID 和机密已被删除）

问题：

这是一个已知问题吗？
有解决方法吗？

【问题讨论】：

是否有详细的错误信息显示第一次刷新后响应中为什么没有收到新的刷新令牌。还是只获取访问令牌但刷新后没有返回刷新令牌？
@NanYu-MSFT 没有消息，只有正常响应，没有任何刷新令牌。一个“坏”的响应看起来像这样：gist.github.com/drunkel/bf9fd7c8b9f69c5a03b0eb364a629262
+100 解决这个问题，请 GoDaddy。
我不熟悉 GoDaddy 的 Office365 设置，但用户如何从 Office 365 重定向到 GoDaddy Office 365？他们是否两次登录 Office 365？如果是这样，是否最初收到的“refresh_token”是用于第一次登录，但第二次登录使其无效？反之亦然，“refresh_token”用于辅助登录，但 Office 365 Auth 仅识别第一个？
嘿，这是一个有趣的问题，我想进一步研究。 @drunkel 当您将刷新令牌换成新令牌时，您可以尝试从请求中获取correlation_id 吗？您可以使用 fiddler 之类的网络跟踪工具来找到它。

标签： azure oauth office365 azure-active-directory office365api

【解决方案1】：

我是 GoDaddy 的软件工程师，可以确认此问题已得到解决。 Modern Authentication 下更频繁的登录请求的原因是因为这些是联合用户，并且正如您在问题中提到的那样，没有返回刷新令牌。这是由于 AAD 用户的 StsRefreshTokensValidFrom 属性未正确更新造成的。

【讨论】：

【解决方案2】：

每个提供者都可以决定如何实施自己的 oAuth 服务器，并使用特定的策略来处理特定的授权类型，以及关于授予/撤销刷新令牌/id 令牌/访问令牌及其生命周期属性的策略。

这是购买 Office 365 帐户时 go daddy 的一个已知问题。请参阅 here 以及 here 和 here。

因此，当您通过 GoDaddy 购买 Office 365 帐户时，GoDaddy 似乎决定通过不启用也不向调用 OAuth 身份验证和授权的 API 发送刷新令牌来实施其 OAuth 服务器，并使用有关刷新令牌的受限安全策略。

这是一项安全增强/阻止，以禁用您的应用程序，使其不持有可以永久存在（如果刷新）到这些在 Godaddy 上购买的 Office 365 帐户的终身刷新令牌

通常，通过与 Azure Active Directory 集成实现的 OAuth 服务器具有以下令牌生命周期（但您可以更改并决定覆盖 以不同方式配置它们 第三方使用自己的令牌策略实现自己的服务器)

找到了另一个重要功能，即 Go Daddy 不支持 Office 365 帐户的多重身份验证 (mfa) here。

Azure 生命周期策略： Azure Active Directory Configurable token lifetime properties
另一个重要问题是，如果您希望能够在用户离线时继续刷新令牌，您必须向用户询问 access_type="offline"，因此在用户不活动的时间，您可以继续刷新令牌并为帐户持有长寿命令牌。
如果用户出于任何原因决定撤销令牌 - 令牌将立即过期。

您描述的步骤中的另一个问题是：

用户是从我们的应用程序发送的 -> Office365 登录页面。
用户输入电子邮件地址
用户被重定向到 GoDaddy Office365 登录页面。 所以现在 Office 365 的刷新令牌从服务器流到 Godday 服务器的手中。
用户完成授权并被重定向回我们的应用程序，响应中包含访问代码。（但没有在最后一个服务器到服务器步骤中获得刷新令牌。Godaddy 代表 365 帐户保持安全性将其保留给自己，而不是将其返回给最终用户。
应用程序从 Office365 交换 access_token 和 refresh_token 的访问代码。 6. 一段时间过去了，access_token 过期了 7. App 使用 refresh_token 刷新了用户的 access_token

【讨论】：