为什么 WSO2 在使用 OAuth2 内省令牌时需要租户用户名/密码？答案

【问题标题】：Why does WSO2 require a tenant username / password when introspecting tokens using OAuth2?为什么 WSO2 在使用 OAuth2 内省令牌时需要租户用户名/密码？
【发布时间】：2018-05-16 21:12:49
【问题描述】：

过去几天我一直在使用 OAuth2，我相信我已经大致弄清楚了，并且我的代码运行良好。我觉得奇怪的是 WSO2 不允许您使用 client_id / client_secret 授权 OAuth2 令牌自省。这是不允许的原因吗？

我对 OAuth2 的理解是，您应该在授权服务器上注册您的客户端（在 WSO2 下注册为服务提供者）。这使客户端能够通过服务器识别自己。租户用户有什么特别之处，还必须提供它来自省令牌？其他 OAuth2 系统没有此要求。

【问题讨论】：

标签： oauth-2.0 wso2 token wso2is introspection

【解决方案1】：

我认为这是他们的设计决策之一。通过token introspection 文档，我认为他们想要的是使自省独立于客户。这样任何其他知道最终用户（位于租户中）的凭据的应用程序都可以自省令牌以进行验证。我认为有满足此类需求的用例。

无论如何，RFC7662 - Token introspection 不强制实施使用客户端凭据。由实施者选择方法。但是是的，它确实提到了客户端凭据和承载令牌。

为了防止令牌扫描攻击，端点还必须要求访问此端点的某种形式的授权，例如客户端 OAuth 2.0 [RFC6749] 中描述的身份验证或单独的 OAuth 2.0 访问令牌，例如 OAuth 中描述的不记名令牌 2.0 承载令牌使用 [RFC6750]。 管理方法和方法验证这些身份验证凭据超出了此范围规范。

【讨论】：

谢谢。是的，这也与我得出的结论非常相似。我希望能了解他们的设计决策。我正在尝试制作一个通用的 OAuth2 接口，但我发现这有点棘手，因为每个实现都非常不一致。似乎我最好的选择是让人们配置参数名称和值，并让他们选择如何进行身份验证。这不是世界末日，但它似乎不如我通常的包装方式那么精致。
@jcfbvfjfn 是的，这就是我所看到的。 OAuth 2 实现因供应商而异。有供应商特定的要求和配置。这使得适应变得棘手并且彼此不同。可能您仍然应该制作通用包装器，但针对不同的供应商使用不同的内部实现。