如何安全地让应用程序使用OAUTH和客户认证授权流访问不同的应用程序？
我是OAUTH和API访问和授权的新手，我一直在阅读关于OAUTH和API访问和授权的文章，目的是想出一个集成两个应用程序的高级解决方案。
我在A公司工作，A公司生产A产品，产品A托管在Azure上，是RESTful API。我们被B公司收购，后者生产产品B和产品B客户端服务器，而不是托管在网络上。
产品B在Azure上拥有自己的数据中心和产品A。产品A对于我们的每个客户都有单独的实例，如client1.productA.com、client2.productB.com等。Prod目前只是一个租户。
产品B和A将来将共享相同的客户端。
Prod B的实例通过发送JSON请求和接收响应来与产品A的实例对话，但在此之前，产品A登录到产品A UI中具有管理角色，必须生成承载令牌并通过加密的电子邮件与product人员共享该令牌，然后将该承载令牌插入到他们的环境变量中，然后流程启动。这可能需要两周的时间来交换电子邮件之类的。
我们要做的是移除人工干预，并在A和B之间实现自动化。产品B有OKTA作为他们的IDP，并且有OIDC。产品A是带有SAML2.0的ADFS，也支持OIDC。基本上，产品B应该请求对Product的访问，而Product应该验证它是产品B，然后共享服务器-服务器流的访问令牌。
问题
- 产品A如何验证产品B的访问请求？产品B的IDP (OKTA)是用来验证产品B的要求，还是它是产品A的ADFS？
我试图制定一个工作流解决方案，但我不确定我是否在正确的道路上。
回答 3
Stack Overflow用户
发布于 2022-05-18 19:25:43
App使用SAML对用户进行身份验证这一事实无助于对另一个应用程序(SAML不能对应用程序进行身份验证)进行身份验证，而对不代表用户的应用程序进行身份验证的应用程序使用OIDC客户端凭证流，该应用程序对必须手动添加的应用程序的连接实例使用客户端机密，这似乎需要2周的时间。
现在有两种可能性：
- 如果每个实例都不是代表用户进行身份验证，那么您所能做的就是通过每次创建App实例时启动自动化工作流这样的方法来改进/自动化2周流程。
- 如果应用程序B代表用户连接到应用程序A，那么您可以使用在Okta中将ADFS添加为外部标识提供程序 (应用程序本身有一个客户端秘密，而不是每个实例)，并将其配置为使用OIDC进行身份验证，并使用生成的令牌访问应用程序A。
我希望我的问题是正确的，这是有用的：)
Stack Overflow用户
发布于 2022-05-17 20:40:19
我可以在这里看到一些澄清/建议：
- 不管授权背后的机制是什么，无论如何都应该有一个手动步骤，允许您的应用程序B访问另一个应用程序A实例。换句话说，您需要首先创建配置或人工批准步骤。
- 在任何架构中，应用程序A和B都需要相同的authZ服务器
- 当B需要调用service时，它会转到他们的共享authZ服务器，并为A的实例请求一个令牌(假设您有很多，并希望将它们全部隔离)。它可以通过不同的OAuth范围来完成。
- 如果B被允许(批准，配置)，它将被赋予令牌，它将被发送给你的A。
- A在本地或通过/introspect验证令牌，以做出允许B在
诸如此类的问题，但你的问题肯定是一个建筑问题，所以不太适合这样做:)
Stack Overflow用户
发布于 2022-05-23 16:19:14
产品B可以使用OIDC对用户进行身份验证，以便产品B同时接收与用户及其角色相关联的ID令牌和访问令牌(AT)。然后，产品B可以使用该AT作为承载令牌向Product提出请求。产品A的API必须调整以根据产品B的IDP验证传入的承载方，并检查相关角色。
https://stackoverflow.com/questions/72280249
复制相似问题
腾讯云开发者
