如何使用Ocelot在Gateway中使用Gateway中的.NET Microservice应用程序
我们有一个基于.NET微服务的应用程序，其中使用Ocelot构建网关。到现在为止身份验证和授权。
我们还设有基于API密钥的身份验证，但直到现在才使用。
我添加了一个由API密钥完成的身份验证的新微服务，我想在网关中处理授权。这意味着网关应基于JWT令牌检查索赔，并使用API键标头将请求转发到微服务。
我该如何处理Ocelot，而不是为每个相应的微服务控制器和动作编写控制器和操作？我考虑过实施委派处理者来照顾它，但是也许有更好的方法？
We have a .NET microservice based app where the Gateway is built using Ocelot. Until now we didn't do any authentication in the Gateway, the frontend calls an Authentication Provider service which responds with an JWT token, the token gets added to request headers and then, the new requests go through gateway and each particular microservice is concerned with authentication and authorization.
We also have API Key based authentication in place, but it's not used until now.
I added a new microservice with authentication done by API Key and I want to handle authorization in the Gateway. That means the gateway should check the claims based on JWT token and if claims matches forward the request to the microservice using an API key header.
How can I do it with Ocelot, instead of writing controllers and actions for each corresponding microservice controllers and actions? I thought about implementing Delegating Handlers to take care of it, but maybe there is a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
做到这一点的干净方法是，在客户端和API网关之间访问令牌，然后使用令牌交换流在网关和基础API之间，以保持对初始访问令牌的潜在攻击表面并避免暴露内部力学（例如，在您的初始访问令牌中的多个基础API的受众群体，多个，多个API范围）。
有关此网络的信息来源很多。 这是一个让您开始。
A clean way to do this, is to have the access token between the client and the API gateway and to then use the token exchange flow between the gateway and the underlying APIs so as to keep a potential attack surface on the initial access token small and avoid exposing internal mechanics (e.g. multiple audiences of underlying APIs in your initial access token, multiple api scopes).
There are many sources of information about this online. Here's one to get you started.