I know one of API Gateway offers is to provide a security layer of any backend APIs. But how if the case is the backend has its own authentication already (let say api key, jwt or other)? What is the better approach / best practice:
Modify those backend APIs to become "plain API" (without any auth), so will rely only on API Gateway auth (OAuth2)
Keep the backend auth as it is, but then create a microservice that will act as wrapper API to handle that backend auth.
The goal is to prevent double authentication & give the same experience to the clients where they only need to pass 1 authentication which is by the API Gateway. Thank you!
I would keep the backend's API security. There is nothing wrong with having secured communication behind an API gateway. As a matter of fact, I recall this being a recommended approach.
To prevent double authentication, would it be a suggestion to define a public (unsecured) end-point on the API gateway to access the authentication end-point of the authentication server used by your backend services. The client receives the authentication token from that authentication server and the API gateway passes the token through to the API of your backend services.
Another possibility could be to authenticate towards the API gateway but let the API gateway use the same authentication server as your backend services. Some gateways allow you to forward the authentication to an authentication server somewhere outside of the API gateway.
Related
I created an API Gateway to allow a certain client to access specific routes in my app engine. The client prefers to authenticate using Pre-Shared Key (PSK) over TLS. Is it possible to do that in a Google API gateway?
With the GCP API gateway, you have a limited number of built-in authentication methods. I don’t think we can authenticate using Pre-Shared Key (PSK) over TLS. In order to authenticate using the GCP API Gateway you have to use one of the alternate authentication methods provided in the documentation.If you think it is valid request for GCP API gateway you may raise a Feature request at issue tracker
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.
I'm using KONG API Gateway, and I want to implement JWT authentication as separate microservice (not using KONG plugin), now I can easily register this service with KONG, and so users can register and login. Assume an authenticated user had sent a request with a token attached in the header, how to make KONG forwards the request to the authentication service first, then if it is valid the request is forwarded to the requested service?
Yes you can (But I have not used them) there is as far as I know two options:
https://docs.konghq.com/hub/kong-inc/openid-connect/ Enterprise
https://github.com/aunkenlabs/kong-external-auth Free
I'm in the progress of implementing a microservices architecture with a single entry endpoint for my clients, a API Gateway. This is my suggested authentication flow:
1). Client (SPA) passes user credentials to the API Gateway, which passes them further to my Authorization/Authentication Services.
2). The Auth Service validates credentials and issues some form of opaque token, which is passed back to the client through the API Gateway.
3). The Client sends the token as a header to each request. The API Gateway exchanges this opaque token to a JWT from the Auth Server and stores it in a cache. The JWT is then attached to all downstreaming requests and my internal microservices validates the JWT (Issuer, Audience).
I'm in doubt if any OAuth/OpenID protocols supports this out of the box or if I would have to implement this my self. (Not desirable!).
Would it be a better solution if the Authentication Service was located outside of the API Gateway?
Thanks in advance.
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.