OAuth 2.0 客户端凭据流和证书凭据之间有什么不同答案

【问题标题】：what's the different between the OAuth 2.0 client credentials flow and Certificate credentialsOAuth 2.0 客户端凭据流和证书凭据之间有什么不同
【发布时间】：2017-10-26 17:57:04
【问题描述】：

我想编写一个守护程序服务以通过应用程序身份访问客户办公室 365 资源，从文档中我发现有两种方法可以支持它，一种是https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds，另一种是https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-certificate-credentials。我想知道它们之间有什么不同，哪个是实现守护程序服务的最佳解决方案。

谢谢

【问题讨论】：

标签： azure office365 outlook-addin

【解决方案1】：

根据我的理解，它们之间的唯一区别是证书凭证提供了更高级别的保证。比如可以灵活控制自己生成的client_assertion的过期时间。即使泄露了，也会根据client_assertion的生命周期将损失降到最低。（这里只是假设HTTPS不安全）。如果共享密钥被泄露，我们将无法在检测到它并禁用该密钥之前对其进行限制。

有关客户端凭据流程的更多详细信息，您也可以参考以下链接：

Service to service calls using client credentials (shared secret or certificate)

【讨论】：

感谢您的回答。那么根据您的意见，是否有任何场景可以使用client_credential？由于我遇到了一个问题，请求订阅失败，服务访问令牌基于此处的协议docs.microsoft.com/en-us/azure/active-directory/develop/… 并且返回错误是原因 =“访问令牌是使用一种太弱而无法访问的身份验证方法获取的应用程序。提供的身份验证强度为 1，要求为 2。";error_category="invalid_token"
似乎服务需要更多的安全方法来获取令牌。例如，使用证书（参考here）。
是的，我也有同样的想法，所以我创建了证书并更改了清单文件，但是在使用访问令牌调用订阅时仍然失败。
我找到了根本原因，因为我同时使用了范围 outlook.office.com 和 graph.microsoft.com，但是 seams /token api 不支持它，所以我只是得到了一个没有有效范围。我认为 msft 文档丰富了这种情况，因为在其他 api 中我们可以一次添加多个范围。
令牌中的受众是什么？它与您使用的资源匹配吗？