How API Gateway and Micro services works.
Could anyone explain the basic flow of Micro service architecture with Gateway. I couldn't find the proper answer.
Say we have auth server and customer micro service running on separate instances and in front of all the services we have an API gateway.
My question is.
when user try to log in using username and password, the API gateway call auth server and return the access token to user.
Then user trying to access the specific url (/customers - customer micro service) that is running on separate instance.
what API Gateway do ?
validate the token with auth server and get the user id and pass the request to customer service with the user id ?
OR
validate the token and pass the request to customer microservice with the access token ? and customer microservice responsible is to the check the user id (Make an HTTP call to auth server) ?
I think that the most common approach is to use API gateway also as a security gateway, which means that API gateway is responsible for SSL termination and token validation. If token validation is successfully you can put user ID or user API key as a header and forward the request to microservice. Moreover you may also decide to perform not only authentication but also authorisation on the API gateway (usually with help of API management solutions).
Regarding your option #2 - I see no point in validating token 2 times. Best practise is to perform security validations on the edge, because in case of failed validation you use less resources (reject earlier)
To Answer your question , it is close to option #2 that you have mentioned . The API gateway will generally check the validity of the authentication token and then pass over the request to your micro-service . However you need to decide at design time if your micro-service will also do another level of verification of the token.
Please do note that the API gateway will not be enforcing Authorization , the authorization is something that your micro-service will have to enforce.
Related
i am creating a spring microservices project. my project is composed of eureka, spring cloud gateway and other microservices.
what i am doing is validating user jwt in spring cloud gateway, but validating the token only is not enough, i also want to check if user state is valid or not, for example I want the gateway to return to the client "UNAUTHORIZED" if his account is banned.
what i'm doing now is letting the user use his token until it is expired, but once the token is expired and the user tries to renew it, i inform him that he's banned and he can not get a new jwt.
what i want to do is block him even if his token is not expired yet, i don't want him to access endpoints once his account is suspended.
I know that I can call the user microservice in the gateway filter to obtain his state .. but I don't want to do this on every api call, because i think that's a little more expensive.
Are there solutions to manage this situation?
It's clear for me about users authorization in microservice architecture (API Gateway for handling auth, SSO, authorization microservice and so on).
Now i'm thinking about authorization request between microservices.
And there is one question - which options i have in case when i have not got a user?
For example - analytics service, which requests data from billing and builds complex reports. There is no user, but do i need authorize request from analytics service to billing?
I know that there can be endless tokens, but i think its not good idea.
What another options for authorization request between services?
In OAuth2 specification there is such thing called machine-to-machine token. Which is different than password credentials flow which is refering to your user authorization.
To create a machine-to-machine token you should implement a flow called client credentials flow. In this flow basically all services have a specific client id and client secret and with those you are making a call to your central oauth-server to get a token. As it is also required to configure client details in the central service you will have the authorization in between client calls in terms of which client could call which others. There is also configurations for the time to live for each token.
If you already have the OAuth2 setup on your side it might be easy to introduce this new flow. But if you don't to implement such a thing on your side with your own setup could be tricky. Please check https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#grant-type-client-credentials
I have been working on creating a platform utilizing microservices architecture with an API Gateway. One question that I'm stuck on, is how to have the API Gateway handle both authenticated and unauthenticated endpoints.
Here is a simplified and rough diagram of the system I am thinking about
For my system, I'll be using Auth0, and I think I want to have the service check if the token is valid using the public key, instead of the gateway doing it. This gives me more flexibility if I want to make one of my services public someday. And I think I want to keep my gateway small.
But how will the gateway handle a mixture of both authenticated an unauthenticated endpoints? I.E. I want to make the GET endpoint "open", and the POST endpoint require login. Which entity should manage whether an endpoint is "open" or "requires login", the gateway or the service?
Should I always have the gateway pass along the request to the service, regardless of whether the user is logged in or not, and have the service return a 401?
Or should the gateway contain some logic about which endpoints require login, and return 401 if there is no token in the request? Skipping the service entirely.
Yes it is configured on the gateway you will be using. For example on AWS API gateway you can have a lambda custom gateway authorizer for access points. The authorizer function can 'authorize' by returning ok for all request to that endpoint.
More reading here
This is one of main responsibilities of API Gateways in my opinion. It may depend on the specific API Gateway but one elegant solution that we used was:
All microservices define their endpoints and if they are protected or not in a descriptor file.
When it is deployed (perhaps in CI) it registers these definitions in the API Gateway
API Gateway accepts the request and check if it is protected or not
API Gateway may enrich request with user info if protected
All requests beyond Gateway is accepted secure to be accepted by services
This way we separate the concern of authentication from business logic / features
In a context with the following services:
API Gateway/OIDC client: connect to an external OpenId Connect Provider (to get access, refresh and id tokens) and act as proxy to forward requests to other services with the access token (Authorization code flow)
Several resource servers, incoming requests are handled by the API Gateway and include the access token (for validation, using the keys exposed by the OIDC provider)
I am using the Spring Security 5.2 Oauth2 client/resource server libraries.
What will be the recommended secure way to make all the resource servers services aware of the user information (included in the API Token).
I am evaluating several options:
Include the id_token in the request sent to the services. Each
service can then validate the token (in a filter).
Make the API Gateway act as a token issuer to make a new enhanced token based.
The resources servers will have to validate the token received with
a new key exposed by the API Gateway/Token issuer. With this
solution a custom AuthenticationManager has to be implemented.
I think option 2 is the more secure and future proof, is there any downsides I should consider? Also there are maybe other alternatives.
You should be able to achieve your goals without issuing a second level of token or sending id tokens to APIs. A common gateway solution is as follows:
Open Id Connect Provider (OICP) issues tokens to the client and does all the deep stuff like auditing of tokens issued + UIs for managing them
Client sends access token to resource server via API Gateway
API Gateway validates the access token, which can involve an introspection call to the OICP
API Gateway can send the access token to the user info endpoint of the OICP to get user info, then forward this to resource servers - perhaps via headers
API Gateway can be configured to cache claims (token + user info details) for subsequent calls with the same access token
Resource servers sometimes run in a locked down Virtual Private Cloud and don't need to revalidate the access token (if you are sure this is safe)
AWS API Gateway works like this when calling lambda functions. I actually like the pattern in terms of extensibility and it can also be used in standalone APIs.
My write up may give you some ideas, along with some sample authorizer code and a class that does the OAuth work.
I have a rest service which stores comments from the users in the database, my architecture is an angular fronted which connects to a load balancer server (zuul) which connects to an auth server to generate the jwt.
With the jwt the frontend generate the requests to the same zuul server with the jwt, this zuul server validate the jwt and if valid will connect to another backend service to store the comment.
The backend service where the comment is stored doesn't have any security validation all endpoints are accessible as the route of this microservices are not going to be exposed? Is there any risk on this?
As there is no jwt reaching the "comment backend service" how can I get the user that actually made the request? Should I implement some kind of filter in the zuul server to get the logged user from the jwt token and include the information in the request that is being sent to the "comment backend service"? If this is possible, any ideas on how to implement it?
Thanks
Regards
By default, Zuul considers the Authorization header as a sensitive header and it will not pass it downstream. So the first thing you need to do is to update Zuul configurations. Read the documentation here.
After that, in each of your downstream service, you need to add the capability to read the JWT token from the Authorization header and extract relevant information such as username, etc.