我有一个必须与Office365 API（Calendar API等资源）通信的应用程序。这个应用程序有自己的帐户，所以我需要一个'个人访问令牌'。
由于应用程序不是针对多个用户的服务，因此我不需要整个OAuth 2.0流程，具有重定向，权限等。我只需要一个我将在HTTP请求上发送的令牌，然后在Office365 UI上，我的应用程序执行的所有操作看起来都像是由用户执行的。
这种情况可能吗？例如，Github提供了这种替代方案：https://github.com/blog/1509-personal-api-tokens
在文档中，我读到了OAuth2 Client Credential Flow，这似乎是我案例的解决方案。但是，它看起来比它应该更复杂+我不知道应用程序代表哪个用户？也许代表注册该应用程序的用户？
非常感谢任何澄清或提示！
答案 0 :(得分：0)
如果您使用客户端凭据流，则不会代表任何人执行操作。在这种情况下，您将充当应用程序。这是你知道的最简单的流程，它并不复杂;）
真正的解决方案是使用授权代码流获取令牌，然后存储刷新令牌，以便始终通过刷新令牌流获取新的访问令牌。
这需要标准重定向，然后当您获得授权代码时，使用客户端ID +客户端密钥+代码+资源标识符（O365 API或Microsoft Graph API＆＃39; s）将其交换为令牌+您使用的重定向URI + grant_type = authorization_code。
刷新令牌非常简单，因为您使用grant_type = refresh_token +客户端ID +客户端密钥+刷新令牌+资源标识符来调用/ oauth2 / token端点。然后你会得到一个访问令牌+新的刷新令牌。
另一种解决方案（我不建议使用）是使用资源所有者密码凭据流。在那个中，您将客户端ID +客户端密钥+用户名+密码+资源标识符+ grant_type =密码发送到令牌端点。
不使用ROPC流程的原因：