我们有一个带有前端UI(这是一个Web应用程序)的应用程序,它与资源服务器进行通信。我们的前端将使用资源服务器中的一些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都调用相同的内部核心服务。可能值得与您的利益相关者讨论..