通过GoDaddy购买的Office365帐户未返回刷新令牌。

Question

背景

我们的应用程序与Office365之间有一个功能，使用Office365 REST API（此处）同步日历条目和联系人。我们正在使用API的版本1。对于授权，我们通过Azure AD进行授权，如此处所述。

问题

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

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

期望行为

此时，我们期望收到一个新的访问令牌以及一个新的刷新令牌，就像使用普通 Office365 帐户一样。

实际行为

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

显然，当打算进行长时间同步时，这是一个破坏性的案例，因为用户将无法在此之后刷新其令牌。

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

问题：

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

- drunkel

---

在第一次刷新后，响应中是否显示了详细的错误消息，说明为什么没有收到新的刷新令牌，或者只是获得了访问令牌，但没有返回刷新令牌？ - Nan Yu

@NanYu-MSFT 没有消息，只有普通的响应，没有任何刷新令牌。一个“坏”的响应看起来像这样：https://gist.github.com/drunkel/bf9fd7c8b9f69c5a03b0eb364a629262 - drunkel

请为此提供修复，GoDaddy。+100。 - HankHendrix

我不熟悉GoDaddy的Office365设置，但是为什么用户会从Office 365重定向到GoDaddy Office 365？他们是否需要两次登录Office 365？如果是这样，初始收到的“refresh_token”是否为第一次登录，而第二次登录使其失效？或者反过来，即“refresh_token”用于第二次登录，但是Office 365 Auth只识别第一次登录？ - brendonofficial

嗨，这是一个有趣的问题，我想进一步研究一下。@drunkel，当您交换刷新令牌以获取新令牌时，您可以尝试从请求中获取correlation_id吗？您可以使用像Fiddler这样的网络跟踪工具找到它。 - Daniel Dobalian

@DanielDobalian，看起来你提到的唯一一个头文件是：x-ms-request-id →12a84a47-3ab6-4358-8bc8-eb54c48a0c00。这正确吗？ - drunkel

Answer 1

我是GoDaddy公司的软件工程师，可以确认这个问题已经解决。在 现代身份验证 下更频繁的登录请求的原因是，由于这些用户是联合用户，并且正如你在问题中提到的那样，刷新令牌未被返回。这是由于 AAD 用户的 StsRefreshTokensValidFrom 属性没有被正确更新所导致的。

- bray

Answer 2

每个供应商都可以决定如何实现自己的oAuth服务器，并制定有关如何处理某些授权类型以及有关授予/撤销刷新令牌/ID令牌/访问令牌及其生命周期属性的策略。

这是购买Office 365帐户时与GoDaddy相关的已知问题。请参见此处，以及此处和此处。

因此，似乎GoDaddy决定使用受限安全策略实现其OAuth服务器，即在通过GoDaddy购买Office 365帐户时，在调用OAuth身份验证和授权的API时不启用并且不返回刷新令牌。

这是一项安全增强/阻止措施，旨在禁用您的应用程序持有永久刷新令牌（如果刷新）可永久使用的这些在Godaddy购买的Office 365帐户。通常，与Azure Active Directory集成实现的OAuth服务器具有以下令牌生存期（但您可以更改并决定覆盖配置以不同方式实现，第三方使用自己的策略关于令牌）。另一个重要的功能是Go Daddy不支持Office 365帐户的多因素身份验证(mfa)，可在此处找到。

1. Azure 生命周期策略： Azure Active Directory 可配置令牌生命周期属性

2. 另一个重要问题是，如果您想在用户离线时继续刷新令牌，您必须请求用户的 access_type="offline"，因此在用户不活动期间，您可以继续刷新令牌并持有长期有效的令牌。

3. 如果用户因任何原因决定撤销令牌，则令牌立即过期。

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

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

- Tal Avissar