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?
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.
Related
My architecture considers an ApiGateway (ApiGee) that dispatches requests to a service behind.
All APIs (http and rest) have an authorization mechanism. So, the client needs to authenticate itself to an IAM before operate with my APIs.
In order to avoid bad security design, all services behind the ApiGateway accept authenticated requests.
For (technical and business) requirements reasons, I need to use internal/external different authentication mechanisms: when a client sends a request, that has to contains the authorization information provided by IAM1. Instead, the services behind accept authenticated APIs that contains Auth information that came from IAM2.
For the translation, I create a service 'translation-token-service' that exposes an API for implementing the token translation.
My desiderata is to "link" ApiGee to the 'translation-token-service' in order to let the clients to continue to use the authorization from IAM1 and the behind services to continue to use the authorization information from IAM2: when a request arrives, ApiGee should invoke the 'translation-token-service' for having a token with IAM2 authorization information, injects them into the request and dispatches it to the right behind service.
NB: the token conversation made by ApiGee should be in some how cached (I don't care about the storage type). So if a client makes two call with the same token, the first invocation asks to convert the token, the second one doesn't, for performance reason.
NB: IAM1 is not oidc compliant, IAM2 does.
How can I implement this flow?
We are trying to come up with a microservice Architecture where we need to identify whether its a good practice to implement authorization at micro service level when we have already done that gateway level.
We are using KONG as API Gateway which will interact with KeyCloak for Authorization.
After the Authorization is successful, is it really correct to apply a global filter at the resource level that will verify the JWT token passed inside the header. May be performance can take a hit but I am not sure if that is correct.
Ideally microservices should be accessible through API Gateway only. If that is the case in your scenario, then there no need to do authentication validation again.
I'm interested in using Azure APIMS to authenticate requests from a client app using Azure AD. However, I am interested in having the backend API know details about the user who was authenticated at the gateway such that I can perform logic based on that user.
Backend API would be ASP.NET Core 3.x web api.
What approaches are available to me?
One thing I can think of off the top of my head is to simply forward the Authentication header along to the backend API, and do some type of lookup there. But I am wondering if there is any way for me to aggregate the user details at the frontend api gateway layer, and pass that information along in a header?
How are backend applications obtaining details about the authenticated user when requests are authenticated at the frontend gateway layer?
I realize that if I was to add authentication at the backend API layer (which would duplicate the authentication/authorization) I may be able to technically accomplish it this way. However, this would violate the SRP principle and perhaps add some necessary overhead to the backend.
Azure AD authentication at APIM would mostly imply validating JWT token passed along with request. You can callout to other endpoints if you want to with send-request policy to obtain more information (for example, do group expansion), but that would have to be explicitly configured through policies.
After token is validated it's available to you in object model form so you can inspect its properties and use any part of the token in policy expressions, say to send parts of it as headers to your backend API.
In a microservice architecture, an API gateway lays in front of the API. The purpose of this is e.g. changing some request / response parameters, for single entry point or checking authentication etc. Now I would like to protect my API using OAuth2 flows to obtain an access token. The problem is to decide who is the actual OAuth client, I will demonstrate it by using a SPA example:
a) Is it the SPA that started the oauthorize request (to the api gateway) by using the implicit grant. Then, the Api gateway would simply route the request through to the OAuth authorization server, acting as a single entry point, with the /authorize stuff from the implicit flow
b) Is it the API Gateway itself, meaning the SPA sends the username and password of the enduser to the api gateway (of course, here the SPA needs to be trusted with the end users credentials), which then acts on its own as an oauth client using the resource owner password grant
c) dismiss the api gateway at all and create the oauth authorization server "parallel" to the api gateway, meaning you would loose the single entry point etc.
The following picture demonstrate a very abstract architecture, and the question is about the numer "[2]", if this request is initiated by the SPA and passed through by the api gateway, or if the api gateway is intercepting the request and acting on its own as an oauth client?
OAuth with API Gateway
My guess is to always use the best fitting grant type for a specific client, regardless of an API gateway being in between or not. This would mean, that when it comes to OAuth, the API Gateway would simply pass the client authorization request through, whatever grant type it used. Therefore, [2] in the picture would come from the client, and not from the API Gateway acting as the OAuth client. Is this correct? As mentioned, this really gets tricky when it comes to first party apps as you probably could use the password credentials grant, which has huge drawbacks,e.g. no refreshing possible for SPAs.
Please bear in mind that this is a purely opinion based answer, because your question is pretty vague.
I don't like the idea about using the API Gateway as the point which authenticates requests. I think that this defeats the Single Responsibility Principle. The gateways purpose usually is to expose your backend to external clients, perhaps change the contract for some specific clients, etc. But it shouldn't also authenticate calls. Besides it would have to do so based on the data passed to it, which you would have to gather somewhere else anyway.
Another thing which is I think undesirable, is that you're considering using the resource owner password grant for your SPA. This is not the correct use case for this grant flow. You could look into this article, which explains it much better than I could: https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications
I would suggest you use the Implicit grant type and use the api gateway to only route calls to the backend, don't authenticate the calls on that layer.
If you're using a spring cloud api gateway (essentially a zuul proxy), you will have to add proper configuration so that it forwards all security headers and redirects. This example works for me:
server:
use-forward-headers: true
zuul:
addHostHeader: true
routes:
<your oauth server route>:
url: <your oauth server url>
path: <if youve got any prefix>
sensitiveHeaders:
stripPrefix: false
It doesn't matter, what Krzysztof Chris Mejka in previous answer like or dislike. Take a look at BCP - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-6
Latest recommendation from oauth working group at IETF is to use a kind of Api gateway/reverse proxy, another words - you need to keep tokens out of js entirely.
I have project with many micro services each one doing its job. One of them responsible for authentication and authorization. But its not clear how other services should check users permissions. Is there any mechanism to deal with this task?
One of the best approaches is the OAuth delegation protocol with JSON token JWT
Authentication in micro-services architecture
the user send his credentials to the OAuth server
The server Checks the user's information (from LDAP server for example), then gives him an access token
the user send his request with the access token to the API Gateway
the API Gateway extracts out the access_token from the request, then he will talks to the Token Exchange endpoint to validate it and then issues a JWT
this JWT That contains all the necessarily information about the user will be sent to the micro-service.
the micro-service also should verify the validity of the token by talking to the token exchange endpoint.
when the token is checked, the micro-service can start its job.
I think this link will be useful for you Securing Microservices
You said that this responsibility belongs to a microservice. So, the other microservices don't check permissions, they delegate.
If you use an API Gateway and the other microservices are not accessible from the outside then it calls the authentication/authorisation microservice before forwarding the request to the upstream microservice.
If you don't use an API Gateway then each microservice call the authentication/authorisation microservice before actually performing the action.