外部身份服务器授权自己的资源答案

【问题标题】：External Identity server authorizing own resource外部身份服务器授权自己的资源
【发布时间】：2019-07-26 03:56:22
【问题描述】：

我的公司被要求使用外部身份服务器（我们的客户端）来授权我们负责和托管的 api。 IE，我们有一个我们构建的后台软件，客户端登录并使用托管在我们自己的基础设施中的（vpn）。我们有自己的网络农场，通过这个后台软件公开对某些功能的 API 访问。第三方（我们客户的客户）正在构建一个使用我们 API 的网站。我们被要求在网站和 api 之间使用客户端凭证流。通常我们希望我们自己的 api 的身份和授权位于我们自己负责的基础设施中。 IE 为我们自己的许多 API 提供的一种身份服务。在我们自己的基础设施之外授权我们的 api 资源是否正常？这是安全问题吗？

【问题讨论】：

标签： oauth-2.0

【解决方案1】：

如果任何其他第三方需要调用您的 API，这将不起作用。此外，您的 API SLA 现在跨 2 家公司 - 这不好。

更标准和可扩展的选项是让合作伙伴后端在您负责的授权服务器内调用您自己的 OAuth 令牌端点。

他们的代码将完全相同 - 但合作伙伴将使用不同的 URL 来获取令牌。

如今，大多数公司都使用低成本且高度可用的云提供商作为授权服务器（例如 AWS），而不是在本地托管此类组件。

很高兴回答任何后续问题..

【讨论】：

谢谢。它确实让我对 auth off prem 感到奇怪。（但是，oauth 还是被委派了身份验证？）他们使用 Okta 作为身份验证服务器？我认为哪个类似于身份服务器？我假设资源和令牌服务器应该在同一个主干上。目前，我们为客户托管一切。他们的合作伙伴（外部网站）只需调用我们的 oauth 令牌端点并将承载附加到 api 请求。放弃对客户端的授权会产生三角依赖，我会失去对访问的控制。 AWS 如何提供帮助？我假设 api 资源与它一起位于 AWS 内部？
是的 - 同意你的看法 - 客户端应该从你的令牌端点而不是他们自己的令牌端点获取令牌。通常，您自己的令牌端点不应该是您实际 API 的一部分 - 它应该是您的授权服务器（可能是 Okta、AWS 等）的一部分。您的 API 和身份验证服务器不必托管在一起。