OKTA：在 Okta 中验证 OIDC 配置的 clientId 和 clientSecret答案

【问题标题】：OKTA: Validating clientId and clientSecret for OIDC configuration in OktaOKTA：在 Okta 中验证 OIDC 配置的 clientId 和 clientSecret
【发布时间】：2021-07-31 20:46:57
【问题描述】：

我想在我的应用程序中测试客户为 OIDC 配置提供的 Okta clientId 和 clientSecret。我认为唯一有用的 API 是令牌 API ({issuerURI}/oauth2/default/v1/token)，但此 API 要求管理员为授权服务器创建一个自定义范围，以作为“范围”参数的值以及“grant_type：client_credentials”传递。这会影响用户体验。现有的默认范围，例如“openid、email、profile”等不适用于“client_credentials”grant_type。有没有办法验证 clientId 和 clientSecret？

【问题讨论】：

标签： openid-connect okta okta-api oauth2-proxy

【解决方案1】：

验证 client_id/secret 的唯一方法是尝试进行身份验证并获取令牌。

由于不涉及用户，因此您不使用经典的 openid 或电子邮件范围，因为 client_credentials 流程仅用于机器对机器的通信，在此流程中您不需要任何用户详细信息。

如果需要，您可以配置后端以包含自定义声明。

【讨论】：

剩下的唯一选择是告诉用户创建自定义范围并将其与客户端凭据一起提供。感谢您的信息！
如果您可以详细说明您想要实现的目标，那么也许有更好的解决方案？为什么需要创建新范围？也许可以使用 API 中的访问令牌和授权规则中的声明来实现？
当然。因此，我的应用程序使用 Okta 登录对用户进行身份验证，并通过 Oauth2_proxy（使用 OIDC）完成对 Okta 的重定向。为此，客户需要在我的应用程序 UI 中配置其 Okta（OIDC 将使用 clientId、clientSecret、IssuerURI）。在将它们保存到我的数据存储之前，我需要验证管理员提供的凭据（使用名为“测试连接”的按钮）。
也许只是要求一个没有任何范围的访问令牌？试一试！
也许这已经足够了？我想您总是需要一个范围才能使客户端凭据起作用。如果您认为它解决了您的问题，请随时接受我的回答。