我正在开发一个使用 Outlook 日历 REST API 的 Android 应用程序。我试图保持同步并更新多个用户( session 室)的日历。
我的问题是:
1) 初始授权码多久后过期？
2) 而对于刷新 token 呢？
access token 在 60 分钟后过期。我不知道刷新 token 是在 6 小时、14 天还是 90 天后过期。
3) 后者是可配置的吗？我可以让它永不过期吗？
`
更新:(来自 https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx)
“未提供刷新 token 的生命周期，它会根据策略设置和授权代码授予被 Azure AD 撤销的时间而有所不同。应用程序应该预期并处理新访问 token 请求失败的情况。在这种情况下，它应该返回请求新访问 token 的代码。”
还有:(来自 http://blogs.msdn.com/b/exchangedev/archive/2014/03/25/using-oauth2-to-access-calendar-contact-and-mail-api-in-exchange-online-in-office-365.aspx ) “刷新 token 没有指定的生命周期。通常，刷新 token 的生命周期相对较长。但是，在某些情况下，刷新 token 会过期、被撤销或缺乏足够的权限来执行所需的操作。客户端应用程序需要预期和处理 token 颁发端点正确返回的错误。当您收到带有刷新 token 错误的响应时，丢弃当前的刷新 token 并请求新的授权代码或访问 token 。特别是，在授权代码授予流程中使用刷新 token 时，如果您收到带有 interaction_required 或 invalid_grant 错误代码的响应，请丢弃刷新 token 并请求新的授权代码。”
那么我如何保证我的应用程序始终让所有用户登录？
它将在夜间处于飞行模式，并且它也应该自动从崩溃中恢复。 我可以在不以编程方式存储凭据的情况下对用户进行身份验证的情况下解决吗？
谢谢
最佳答案
答案:
- 几分钟。确切的值是一个实现细节，可以随时更改。收到代码后，您应该尽一切努力兑换它。
- 参见 http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/
- 从今天起，无法更改生命周期限制。我们正在开发可让您拥有更多控制权的功能，但目前我们没有可分享的预计到达时间
保证用户登录的唯一方法是成功兑换刷新 token ，或通过身份验证流程。缓存凭据的使用仅限于极少数情况，并且在即将推出的服务版本中可能会被禁止。
如果刷新 token 过期，您应该计划执行交互式身份验证。请注意，刷新 token 也可能因同意撤销而失效，这将在所有情况下强制交互。
关于oauth-2.0 - OAuth 授权流程 - token 过期，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35353319/