Lets say I have 2 Microservices (customer and payment), both consume APIs of external system (e.g. Stripe).
API Authentication
Assume that before consuming any business API of Stripe, API Consumer (in my case Customer & Payment Service) has to first authentication itself using API Keys (AppId and secret).
Stripe provides access token which must be passed into HTTP header into subsequent API calls to Stripe.
below can be possible approaches,
Approach1
https://drive.google.com/file/d/1BGn-hiNwZT4u3BIBmEv-HkJC0w0dk5CB/view?usp=sharing
Approach2: https://drive.google.com/file/d/1JA1hFq7l7-4Ow3b32XNyb2co4tqxKZQ6/view?usp=sharing
Approach1
Multiple auth token though Stripe account is single (per service instance)
Each service to manage auth token expiration/renewal
Approach2
Single auth-token exists with all services.
dependency on auth service.
auth token expiration/renewal managed by single service (Auth Service)
would like know which should be best fit in Microservice architecture? Any other suggestion?
Approach 2 is slightly more scalable and maintainable if more services will require API access to external APIs.
However the correct implementation would be an egress gateway for all your external API calls.
If your going to spend the time to build an Auth service, you might as well go all the way and centralize your external API routing as well.
Benefits:
Single internal endpoint for external APIs, reduces duplication.
Handles all authn and authz with external APIs for your services.
Centralizes all logging, auditing, disaster recover, load balancing etc....
Most gateway products like kong can be used for egress as well.
Related
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.
We are trying to build an API gateway in front of our application (we may split the application to micro services ASAP), and we meet some problems.
1 - different API types.
There are two kinds APIs in our application, most of them will be used by ourselves(user login/logout, news add/remove), we call them Self-used API here. And some of APIs will be allowed to used by third party, we call them Open API here.
Should all of them get through the gateway?
2 - different authentication
Self-used API may require the user login-ed or have related permissions, the Open API will require the third-party app take a key which we will use to identify and limit the request rate.
Should all kinds of authentication completed in the gateway? If yes, the Self-used api authentication is business related, does it mean that this api gateway can not be shared by other application?
Furthermore, the third-party developer will create their application and get a key back, they can also update/remove the apps(Something like Google API Console).
I am not sure if this should be put in the gateway or another micro-service. IMO, I prefer to put these features in a new service, but the validation and rate limit is done in gateway, that means for each request, gateway will have to query the user, rate limit and other information by the key from the service, this will make the gateway coupled with the business again.
There are quite a few ways of implementing an API Gateway. You can use different endpoints with a single API gateway. Here are a few links that are relevant
Serverless blog "How to deploy multiple micro-services under one API domain with Serverless" https://serverless.com/blog/api-gateway-multiple-services/
Nginx "Do You Really Need Different Kinds of API Gateways? (Hint: No!)" https://www.nginx.com/blog/do-you-really-need-different-kinds-of-api-gateways-hint-no/
Sentialabs.io "Amazon API Gateway types, use cases and performance" https://www.sentialabs.io/2018/09/13/API-Gateway-Types-Compared.html
AWS API Gateway FAQs https://aws.amazon.com/api-gateway/faqs/
Think about the types of features you are trying to accomplish with your approach, and how API Gateway will help you address them.
I plan to use Kong in our project. I'm currently working on a POC to see how we can integrate it in our platform as the main API gateway. I also want to use the JWT plugin for authentication and authorisation. I know that all the API calls should go through the Kong gateway to be authenticated. Then, if the authentication is validated they can go to the API.
Clients ---> Kong gateway ----> Apis
The part that is not very clear in my mind is how the APIs and Kong fit together.
Imagine a scenario where a client try to call directly an API with a token (bypassing the Gateway). How can the API use Kong to validate this token ?
How does Kong authenticates the APIs (not the Client) ? In the examples I have seen so far, only the authentication of the clients is documented, not the authentication of the APIs that are "protected" by Kong.
When using kong as an API Gateway (or for that matter any gateway) we tend to put it at the point where external clients talk to your service. It is a means to discover the individual services. And kong can do good enough job to validate such request.
For the calls you make to other services from within your set of microservices, you may allow for the free passage by means of directly invoking the service. Challenge in that case will be how the services will discover each other. (One way is to rely on DNS entries. We used to do that but later moved to kubernetes and started using their service discovery), and restrict all the incoming traffic to a given service from outside world. So they can only get in via gateway (and thats where we have all the security)
The reason behind the above philosophy is that we trust the services we have created (This may or may not be true for you and if its not then you need to route all your traffic via an api gateway and consider your APIs as just another client and they need to get hold of access token to proceed further or may be have another service discovery for internal traffic)
Or you may write a custom plugin in kong that filters out all the traffic that originates from within your subnet and validates everything else.
In my webapp architecture i have an api gateway which proxies requests to my microservices, also there is a a common microservice which other microservices can query via rest api. All of these run on node servers.
i want the microservices to only be approachable from the api gateway, besides the common server which can also be approachable from the other microservices. what is the best network architecture to make this happen and do i need to handle authentication between the servers in some way?
Security needs to be handled at multiple layers and as such its a really broad topic. I will however share some pointers which you can explore further.
First thing first any security comes at a cost. And it's a trade off that you need to do.
If you can ensure that services are available only to the other services and API gateway, then you can delegate application layer security to API gateway and strip the security headers at API gateway itself and continue to have free communication between services. It is like creating restricted zone with ip restrictions (or other means on from where can service be accessed), and api gateway or reverse proxy handling all the external traffic. This will allow you to concentrate on few services as far as security is concerned. Point that you should note here is that you will be losing on authorization part as well but you can retain it if you want to.
If you are using AWS you need to look into security groups and VPN etc to set up a secure layer.
A part of security is also to ensure the service is accessible all the time and is not susceptible to DDOS. API gateways do have a means of safeguarding against such threats.
For the ‘API gateway’ front-end authentication you could use OATH2 and for the back-end part you can use OpenID connect which will allow you to use a key value that is relevant to the user, like for example a uuid and use this to set access control at the Microservice level, behind the API Gateway.
You can find in the next link further information about OpenID connect authentication.
Clients that communicate against a single point of entry via an API Gateway over HTTPS against a RESTful API
API Gateway: API Keys for tracking and analytics, oAuth for API platform authentication
User Micro service provides user authentication and authorization, generates JWT that is signed and encrypted (JWS,JWE)
Other micro services determine permissions based on claims inside JWT
Micro services communicate internally via PUB/SUB using JWT in the message and other info. Each micro service could be scaled out with multiple instances (cluster with a load balancer).
Question: Can I cluster the the API Gateway and have the load balancer in front of it. What do I need to consider with respect to managing authentication? ie: sharing of API Keys across the API Gateway cluster?
Extra notes, I'm planning on terminating SSL at the gateway and the use of bcrypt for passwords in the db.
Any feedback would be great, thank you.
Can I cluster the the API Gateway and have the load balancer in front
of it.
Yes, you can. Most of the good Api Gateway solutions will provide the ability to do clustering. e.g. https://getkong.org/docs/0.9.x/clustering/ or you can use cloud based Api Gateway: Azure API Management or AWS API Gateway
What do I need to consider with respect to managing authentication?
These specifics depends on your selection of API Gateway solution.