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
Related
I was reading up about API Gateways (Kong) and I wanted to integrate it into my application. Every tutorial I've seen creates consumers for the services using Kong API or through a dashboard like Konga. I already have a user registration/auth service. How can the API Gateway replace that ? How should the user registration be changed so that Kong knows about it ? And how would login work because In all the examples I've seen the ApiKeys or JWT secrets are created in Kong ? Can any body shed some light on how this works in practice ?
In my opinion Kong is not supposed to replace a user registry / authentication service. However, it can help you enforce authentication.
There are several options of securing your APIs against unauthorized access. These include:
API key: this type is used with the key-auth plugin and is not intended for authenticating users (meaning natural persons) but consumers (meaning other systems).
JWT tokens: this type is used with the jwt plugin and is suitable for user authentication. Kong is responsible for validating the JWT tokens (by checking the signature and expiry of the self contained token). You can of course do further checks either with custom Kong plugins or within your upstream service.
So I think you shouldn't think of Kong as a replacement for your user service, but as a complement/addition which helps you enforcing security policies even before the request reaches your upstream service.
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 simple Spring Gateway project that uses 3 microservices - 1 service for doing authentication and 2 "secured" microservices (i.e. all requests to these services must be authenticated).
The authentication service which is responsible for authentication (generate JWT tokens) works fine via the Gateway.
As in I can access it via the Gateway to create tokens and via the Gateway to confirm if a token is valid.
In my scenario when the user attempts to access a “secure” microservice I want
Call the auth service to verify the user has the correct JWT token
If the use does not have the required permission confirmed in (a) return some Http status 404 code with a specific message
If the user is authenticated confirmed by (a) allow the call to proceed to request route
Reading around seems to suggest I would need to apply some filter on the Spring Gateway routes to do this.
The examples on https://cloud.spring.io/spring-cloud-gateway/multi/multi__developer_guide.html#_writing_custom_gatewayfilter_factories aren’t too clear on how to achieve this. Wondering is this the reccomended approach?
If so can someone point me in the direction of what this would look like in terms of the routing code in Spring Gateway
builder.routes()
.route(route -> route.path("/auth/**")
.uri(LOAD_BALANCED_AUTHENTICATION_SERVICE)
.id("authentication-service"))
.route(route -> route.path("/images/**")
.filters(SOME_AUTHENTICATION_FILTER)
.uri(LOAD_BALANCED_IMAGES_SERVICE)
.id("images-service"))
.route(route -> route.path("/inbox/**")
.filters(SOME_AUTHENTICATION_FILTER)
.uri(LOAD_BALANCED_INBOX_SERVICE)
.id("inbox-service"))
.build();
Note I haven't implemented the filter (SOME_AUTHENTICATION_FILTER) shown above yet as I'm not clear from the examples how to call the authentication service from the filter. Also unclear from the examples how the filters would terminate a request or allow the request to proceed.
As I understand, you have two questions, first one the routing recommended flow; and as you defined exactly will be good, if the filter worked correctly move route to Service X.
For the other part, How to define the custom filter? you need to do the authorization check inside it using your secure service; there is a good example which can tell you how to handle this, and how to terminate the request also with descriptive messages.
You can find it here Spring Cloud Gateway Custom Filter
I have separate auth service and products service.
I need to have an api gateway in front of the services and do this function for protected url:
Call the auth service and validates the user token
if token is valid attach the user id to the request and make the request to products service.
Is there any API gateway supports this custom logic to handle requests ?
Thanks.
The answer depends on the technology stack you are using. Which language? Which framework? Where to deployed? Do you use client sessions or JWT? Oauth or Saml or custom auth service?
If you can give more details we can help better. Here are three random examples:
If you have an AWS based stack (e.g. serverless) you can use AWS API Gateway with a custom auth handler. See this.
If you develop with a framework that supports middleware you can write a small middleware to handle auth. Example for golang here. Example for laravel here.
Hosting your own Zuul gateway with oauth example.
For a lot of technologies you will find standard oauth or saml components that you can use as middleware.
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.