使用okta身份验证和客户端凭据API身份验证的前端服务器和资源服务器的集成

问题描述 投票:1回答:2

我们有一个带有前端UI(这是一个Web应用程序)的应用程序,它与资源服务器进行通信。我们的前端将使用资源服务器中的一些API来获取数据。

我正计划向Okta添加前端,并提供对okta注册用户的访问权限。

在资源服务器中,我们希望向客户公开一些API,以便以编程方式集成到他们的系统中。要使用我们的API,我们必须向它们提供客户端凭据(客户端ID /秘密)。使用clientId / Secret,他们将获得access_token并将在后续请求中使用它。一旦用户通过Okta登录,我们就可以通过前端UI显示此clientId / Secret。

我应该如何验证从前端到资源服务器的请求?以及如何使用clientId / Secret通过客户认证对资源服务器的请求?我是否应该为此目的使用一个或两个不同的令牌?

Okta是否提供每个用户的客户端ID /秘密,用户(客户)可以使用该ID /秘密来获取access_token并将其发送到访问资源服务器,并且资源服务器针对Okta验证令牌。

authentication oauth oauth-2.0 okta okta-api
2个回答
0
投票

我只是做了非常相似的事情。您可以在此处了解我的经历: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,它们之间是不同的-数据仍然相同)。


0
投票

您将必须使用2个不同的访问令牌。这里有2种不同的流程:

  • Web UI到API
  • API的业务合作伙伴系统

从技术上来说是指:

  • 授权码流(PKCE)
  • 客户凭证流程

就令牌而言,它的意思是:

  • 在第一种情况下,有一个最终用户以访问令牌表示('sub'声明)
  • 在第二种情况下,访问令牌中仅包含客户ID声明

如果需要,我可以提供令牌验证技术的建议-让我知道。

对我来说,这似乎是一个体系结构问题-尤其是在识别出调用者并进行版本控制/升级之后,应用授权。

根据我的经验,基于两类API,这些天我倾向于使用以下架构:例如,这些API暴露在互联网上:

  • 用户体验API服务于用户界面
  • [Partner API与B2B交易

并且两个入口点API都调用相同的内部核心服务。可能值得与您的利益相关者讨论..


推荐问答