通过 GoDaddy 购买的 Office365 帐户未返回刷新令牌
Refresh token not returned for Office365 accounts purchased through GoDaddy
背景
我们有一项功能可以在我们的应用程序和 Office365 之间同步日历条目和联系人，使用概述的 Office365 REST apis here. We are using Version 1 of the API. For authorization we are performing authorization via Azure AD as outline here。
问题
在正常情况下（当使用直接从 Microsoft 购买的 Office365 帐户时），我们的系统按预期工作：我们能够在用户令牌过期时刷新用户令牌，并返回一个新的访问和刷新令牌作为交换。
在第二种情况下，当使用 Office365 帐户 purchased via GoDaddy 进行测试时，我们遇到了一个阻塞问题，可以在这一系列步骤中概述：
1. 用户从我们的应用程序-> 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 购买的帐户，我们不会在第一次刷新后的响应中收到新的刷新令牌。
显然，当打算进行长时间 运行 同步时，这是一个突发情况，因为用户将无法再刷新其令牌。
Postman traces（可以另存为.json导入Postman进行调试
https://gist.github.com/drunkel/7ec66ed33f66d0070148694651699d03（ID 和机密已被删除）
问题：
- 这是一个已知问题吗？
- 有解决办法吗？
每个提供者都可以决定如何实施自己的 oAuth 服务器，其中包含关于如何处理特定授权类型的特定策略以及关于 granting/revoking 刷新 tokens/id tokens/access 令牌及其生命周期的策略特性。
这是购买 Office 365 帐户时 go daddy 的一个已知问题。参见 here and also here and here。
因此，GoDaddy 似乎决定通过在您购买时不启用也不向 API 调用 OAuth 身份验证和授权的 API 发回刷新令牌来实施其 OAuth 服务器，该服务器具有关于刷新令牌的受限安全策略通过 GoDaddy 的 Office 365 帐户。
这是安全措施 enhancement/block 禁止您的应用程序持有可以永久存在（如果刷新）到这些在 Godaddy 上购买的 office 365 帐户的生命周期刷新令牌
通常，与 Azure Active directory 集成实现的 OAuth 服务器具有以下令牌生命周期（但您可以更改并决定覆盖 以不同方式配置它们 第 3 方使用他们自己的代币政策）
发现 Go Daddy 不支持 Office 365 帐户的多重身份验证 (mfa) 的另一个重要功能 here。
Azure 生命周期策略：
Azure Active Directory Configurable token lifetime properties
另一个重要的问题是，如果你想在用户离线时能够继续刷新令牌，你必须向用户询问access_type="offline"，所以在用户不活动期间，您可以继续刷新令牌并为帐户持有长寿命令牌。
如果用户出于任何原因决定撤销令牌 - 令牌立即过期。
您描述的步骤中的另一个问题是：
- 用户是从我们的应用程序-> Office365 登录页面发送的。
- 用户输入电子邮件地址
- 用户被重定向到 GoDaddy Office365 登录页面。
现在 Office 365 的刷新令牌从服务器流到 Godday 服务器的手中。
- 用户完成授权并被重定向回我们的应用程序，响应中包含访问代码。 （但没有在最后一个服务器到服务器步骤中获得的刷新令牌。代表 365 帐户保持安全的 Godaddy 将其保留给自己，而不将其返回给最终用户。
- 该应用程序从 Office365 交换 access_token 和 refresh_token 的访问代码。 6. 一段时间过去，access_token 过期 7. 应用程序使用 refresh_token
刷新用户的 access_token
我是 GoDaddy 的一名软件工程师，可以确认此问题已得到解决。 Modern Authentication is that as these are federated users and as you mentioned in your question, the refresh token was not being returned. This was caused by the StsRefreshTokensValidFrom attribute on the AAD 用户下更频繁的登录请求未正确更新的原因。
背景
我们有一项功能可以在我们的应用程序和 Office365 之间同步日历条目和联系人，使用概述的 Office365 REST apis here. We are using Version 1 of the API. For authorization we are performing authorization via Azure AD as outline here。
问题
在正常情况下（当使用直接从 Microsoft 购买的 Office365 帐户时），我们的系统按预期工作：我们能够在用户令牌过期时刷新用户令牌，并返回一个新的访问和刷新令牌作为交换。
在第二种情况下，当使用 Office365 帐户 purchased via GoDaddy 进行测试时，我们遇到了一个阻塞问题，可以在这一系列步骤中概述： 1. 用户从我们的应用程序-> 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 购买的帐户，我们不会在第一次刷新后的响应中收到新的刷新令牌。
显然，当打算进行长时间 运行 同步时，这是一个突发情况，因为用户将无法再刷新其令牌。
Postman traces（可以另存为.json导入Postman进行调试 https://gist.github.com/drunkel/7ec66ed33f66d0070148694651699d03（ID 和机密已被删除）
问题：
- 这是一个已知问题吗？
- 有解决办法吗？
每个提供者都可以决定如何实施自己的 oAuth 服务器，其中包含关于如何处理特定授权类型的特定策略以及关于 granting/revoking 刷新 tokens/id tokens/access 令牌及其生命周期的策略特性。
这是购买 Office 365 帐户时 go daddy 的一个已知问题。参见 here and also here and here。
因此，GoDaddy 似乎决定通过在您购买时不启用也不向 API 调用 OAuth 身份验证和授权的 API 发回刷新令牌来实施其 OAuth 服务器，该服务器具有关于刷新令牌的受限安全策略通过 GoDaddy 的 Office 365 帐户。
这是安全措施 enhancement/block 禁止您的应用程序持有可以永久存在（如果刷新）到这些在 Godaddy 上购买的 office 365 帐户的生命周期刷新令牌
通常，与 Azure Active directory 集成实现的 OAuth 服务器具有以下令牌生命周期（但您可以更改并决定覆盖 以不同方式配置它们 第 3 方使用他们自己的代币政策）
发现 Go Daddy 不支持 Office 365 帐户的多重身份验证 (mfa) 的另一个重要功能 here。
Azure 生命周期策略： Azure Active Directory Configurable token lifetime properties
另一个重要的问题是，如果你想在用户离线时能够继续刷新令牌，你必须向用户询问access_type="offline"，所以在用户不活动期间，您可以继续刷新令牌并为帐户持有长寿命令牌。
如果用户出于任何原因决定撤销令牌 - 令牌立即过期。
您描述的步骤中的另一个问题是：
- 用户是从我们的应用程序-> Office365 登录页面发送的。
- 用户输入电子邮件地址
- 用户被重定向到 GoDaddy Office365 登录页面。 现在 Office 365 的刷新令牌从服务器流到 Godday 服务器的手中。
- 用户完成授权并被重定向回我们的应用程序，响应中包含访问代码。 （但没有在最后一个服务器到服务器步骤中获得的刷新令牌。代表 365 帐户保持安全的 Godaddy 将其保留给自己，而不将其返回给最终用户。
- 该应用程序从 Office365 交换 access_token 和 refresh_token 的访问代码。 6. 一段时间过去，access_token 过期 7. 应用程序使用 refresh_token 刷新用户的 access_token
我是 GoDaddy 的一名软件工程师，可以确认此问题已得到解决。 Modern Authentication is that as these are federated users and as you mentioned in your question, the refresh token was not being returned. This was caused by the StsRefreshTokensValidFrom attribute on the AAD 用户下更频繁的登录请求未正确更新的原因。