我们有一个具有前端UI（这是一个Web应用程序）的应用程序，该UI与资源服务器进行通信。我们的前端将使用资源服务器中的一些API来获取数据。
我正计划向Okta添加前端，并提供对okta注册用户的访问权限。
在资源服务器中，我们有一些API要向客户公开以集成到他们的系统中（以编程方式）。要使用我们的API，我们必须向它们提供客户端凭据（客户端ID /秘密）。使用clientId / Secret，他们将获得access_token并将在后续请求中使用它。用户通过Okta登录后，我们便可以通过前端UI显示此clientId / Secret。
我应该如何验证从前端到资源服务器的请求？以及如何使用clientId / Secret通过客户认证对资源服务器的请求？我是否应该为此目的使用一个或两个不同的令牌？
Okta是否提供每个用户的客户端ID /秘密，用户（客户）可以使用该ID /秘密来获取access_token并将其发送到访问资源服务器和针对Okta的资源服务器验证令牌。
我只是做了非常相似的事情。您可以在这里了解我的经历：How to pass/verify Open ID token between .net core web app and web api?
我不知道您使用的是什么应用程序框架（.net，节点等），但是如果您使用的是.NET，则要执行以下步骤：（a）在Web应用程序中安装中间件，（b）安装api应用程序中的中间件，并且（c）确保从Web应用程序到api应用程序的调用传递了id_token。
如果除此之外，您还需要为外部用户保护它-它应该以相同的方式工作。唯一的区别是，它们将手动调用/ authorize端点以获取其令牌-但在两种情况下，中间件都应为您处理令牌验证。
请注意，我确实经历了一件奇怪的事情，那就是我需要传递id_token而不是 not access_token。还值得一提的是，在应用程序和api中对声明的解释是不同的（因为声明的名称，例如userid，它们之间是不同的-数据仍然相同）。
,您将必须使用2个不同的访问令牌。这里有2种不同的流程：
从技术上讲，这意味着：
就令牌而言，其含义是：
如果需要，我可以提供有关令牌验证技术的建议-让我知道。
对我来说，这似乎是一个体系结构问题-特别是在确定调用方和版本控制/升级后应用授权的问题。
根据我的经验，基于两类API，我最近倾向于采用以下架构：例如，这些API暴露在互联网上：
并且两个入口点API都调用内部相同的核心服务。可能值得与您的利益相关者讨论..