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.
Related
I am planning to use Firebase for auth purpose for my Application. The app has a java based back-end using Spring Boot. My understanding so far is that Firebase will handle different type of login options interacting directly with my front-end code and in return will give a token after user has logged in(primarily email based,Google or FB login). I have a few questions:
Does it provide a JWT type token that can be used in conjunction with my back-end without having to talk to Firebase servers from my back-end? I guess its not and SDK provides ways to validate token
Is there a good example of configuring my spring security to validate the the token and get user details?
I could not find a working example with Admin SDK of firebase using spring security.
What other tech stack options I have? I read Amazon Cognito could be one. My app is more of a POC and don't want to host my auth server as well.
What the recommendation on storing the user info in my own back-end or should I just rely on firebase servers to handle my user base?
Pardon my primitive understanding of Auth frameworks!
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
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.
I want to implement an api gateway for a bunch of micro services running on laravel. In front of the gateway there is an angular client where the user has to login with the username and password. The idea is that the user sends the request with the credentials to the gateway which forwards it to the authentication service. If the data is correct, a token will be issued, which will be included in every further request.
I think I will implement the gateway with kong and the oauth2 plugin. I have already looked at their documentation https://docs.konghq.com/hub/kong-inc/oauth2/#resource-owner-password-credentials but I don't really understand the flow.
Does the angular client have to communicate directly with the authentication service on the first request? And if so, does the authentication service need an own url? I think it would make more sense if all the request would go through the gateway, wouldn't it?
Thank you!
From what I understood, your angular app can send username:password to kong gateway and that will proxy the request to your authentication service. You can verify if the user is legit in your auth service.
1) if legit, then make a request to /oauth2/token endpoint provided by kong's oauth2 plugin. Kong will return your auth service an access_token which you can return back to the user
2) If not legit then throw an error.
Does the angular client have to communicate directly with the authentication service on the first request?
Only if your auth service is a third party service you can do that.
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.