我正在构建一个api，我们称之为 CommonApi ，其他API会消耗。对于此示例，我们假设我们有一个使用superNewTrendyFrameworkThatsTheBest.js前端的应用程序和一个WebApi后端，我们称之为 AppApi 。我们正在使用我们的IDP提供的MS Identity。
因此，应用程序将使用自己的api，AppApi来呼叫IDP并对用户进行身份验证，通过声明获取所有角色和权限，以及访问令牌以继续使用AppApi和所有它是门卫的光荣资源。
现在，我稍微坚持的部分是在用户已经过身份验证后访问CommonApi的方式。我已经拥有来自IDP的访问令牌（可能是JWT）以及所有角色和权限。我需要检查AppApi是否允许访问CommonApi，但我也想要每次调用CommonApi时检查数据库，或者再次拨打IDP，如果它是＆＃39可以避免
是否应该有第二个令牌才能访问CommonApi？如果可能的话，我想避免这种情况，但如果这是最好的方式，那就是我要做的事情。我不是在寻找特定于技术的解决方案 - 库，中间件等，而是了解我应该做什么。
答案 0 :(得分：1)
我认为你只是从错误的角度看问题。正确的观点应该可以消除你的困惑。
其他API正在访问您的API这一事实无关紧要。在一天结束时，您的API会为客户端提供服务，而您需要知道的是，某些客户端正在访问您的API。这可能是另一个API，用户，控制台应用程序，服务等等。没关系。
该客户需要获得授权才能使用您的应用程序。获得授权的认证方法可以根据客户端而有所不同，但它们都实现了相同的目标。例如，像其他API这样的东西很可能通过客户端身份验证（id /密钥对）进行身份验证。在这里，您要授权客户端，因此，如果该客户端代表特定用户行事，则他们将需要单独作为该用户进行身份验证（通常通过OAuth）。或者，如果其他API专门针对特定用户，则可以通过OAuth简单地实现整个过程（即客户端本身不进行身份验证，而是客户端的用户通过客户端提供的OAuth工作流进行身份验证。在任何一种情况下，客户端最终会得到一个身份验证令牌，然后他们可以通过进一步的请求来发送授权请求。
重要的部分是身份验证令牌。无论采用何种身份验证方法，都会给出身份验证令牌，而 是用于授权请求的权限。
根据您在此处提供的方案。最可能的方法是AppApi应通过客户端身份验证与CommonApi进行身份验证（将为其分配客户端ID和客户端密钥，并将其发送到CommonApi上的端点以获取然后，它将使用 访问令牌授权CommonApi的所有请求。该网站的用户将对该网站进行身份验证，并根据该身份验证与AppApi进行交互，但这应该与CommonApi发生的任何事情无关。唯一的例外是如果AppApi 冒充 CommonApi的用户。例如，我可能有一个API可以在Facebook上做一些事情。如果我需要做一些事情，比如通过该API发布作为特定用户，那么用户需要通过使用该API的OAuth工作流程直接通过Facebook进行身份验证。之后，API被授予访问令牌代表用户执行操作。