我们有一项功能，可以使用Office365 REST apis here同步我们的应用程序和Office365之间的日历条目和联系人。我们正在使用API的版本1 。对于授权，我们通过Azure AD执行授权作为大纲here。
在正常情况下（使用直接从Microsoft购买的Office365帐户时），我们的系统按预期工作：我们可以在用户过期时刷新用户的令牌，并在交换时返回新的访问权限和刷新令牌。
在第二种情况下，使用Office365帐户purchased via GoDaddy进行测试时，我们遇到了一个阻塞问题，可以在这一系列步骤中列出： 1.用户从我们的应用程序发送 - ＆gt; Office365登录页面。 2.用户输入电子邮件地址 3.用户被重定向到GoDaddy Office365登录页面。 4.用户完成授权，并通过响应中的访问代码重定向回我们的应用程序。 5.应用程序交换来自Office365的access_token和refresh_token的访问代码。 6.一段时间过去了，access_token过期了 7.应用程序使用refresh_token
刷新用户的access_token此时我们希望收到新的access_token以及新的refresh_token，就像我们使用常规Office365帐户时那样
仅对于通过GoDaddy购买的帐户，我们首次刷新后 在响应中收到新的刷新令牌。
显然，当打算长时间运行同步时，这是一个突破性案例，因为用户将无法再刷新其令牌。
邮差跟踪（可以保存为.json并导入Postman进行调试 https://gist.github.com/drunkel/7ec66ed33f66d0070148694651699d03（ID和秘密已被删除）
答案 0 :(得分：2)
我是GoDaddy的软件工程师，可以确认此问题已得到解决。在Modern Authentication下更频繁登录请求的原因是，由于这些是联合用户，并且正如您在问题中提到的，因此未返回刷新令牌。这是由AAD用户的StsRefreshTokensValidFrom属性未正确更新引起的。
答案 1 :(得分：1)
每个提供商都可以决定如何实施自己的oAuth服务器，其中包含有关如何使用某种授权类型的某些策略以及有关授予/撤消刷新令牌/ id令牌/访问令牌及其生命周期属性的策略。
这是购买Office 365帐户时go daddy的一个已知问题。请参阅here以及here和here。
因此，GoDaddy似乎决定使用受限制的安全策略来实施其OAuth服务器，因为当您通过GoDaddy购买Office 365帐户时，不会启用并且不会向调用OAuth身份验证和授权的API发回刷新令牌。
这是安全性增强/阻止，用于禁止您的应用程序不持有终身刷新令牌，该令牌可永久存在（如果刷新）到Godaddy上购买的这些Office 365帐户
通常，与Azure Active目录集成实现的OAuth服务器具有以下令牌生存期（但您可以更改并决定覆盖以不同方式配置第三方使用自己的令牌策略实施自己的服务器）
Go Daddy支持Office 365帐户的多因素身份验证（mfa）的另一个重要功能是here。
Azure生命周期政策： Azure Active Directory Configurable token lifetime properties
另一个重要问题是，如果您希望在用户离线时能够继续刷新令牌，则必须要求用户 access_type =＆＃34;离线＆＃34; ，因此在用户不活动期间，您可以继续刷新令牌并为该帐户保留长生命周期令牌。
如果用户因任何原因决定撤销令牌 - 令牌会立即过期。
您描述的步骤中的另一个问题是：