API AuthN/AuthZ and API Gateway

Question

I have implemented authentication on an API Gateway level using NGINX+ and now I have concern if APIs behind it should still to authenticate using API Keys or JWT? What are best practices?

My point is that somebody may get to the internal network, intentionally or not, and then use those APIs which are wide open (no authentication). But then I have question on another hand what is the purpose to having that authentication on an API Gateway level?

Answer 1

Authentication

In Nginx plus configuration you have something like

upstream servername{
   # IP where the upstream API is hosted
}
server {
  listen xxx;
  location /endpoint/{
     # authentication related settings
     ...
     proxy_pass # The IP defined in upstream block
  }
}

The location block specifies that any requests to URLs beginning with your defined /endpoint/ must be authenticated. After authentication succeeds, Nginx forwards the request to the backend server.

what is the purpose to having that authentication on an API Gateway level?

The API Gateway centralizes external access to the backend services, it provides functionalities which do not require deep knowledge of the internal domains:

• Routing to different versions of internal API (in Nginx it is set by something like location ^~ /1.0/)
• Authentication by validating the token (in Nginx if you are using JWT you define auth_jwt_key_file to tell Nginx how to validate the signature element)
• API Rate limiting per API client (in Nginx it is set by limit_req_zone and limit_req)
• Proxy the token to API endpoint without the necessity to implement token processing and authentication process in the API itself

Authorization

I have concern if APIs behind it should still to authenticate using API Keys or JWT?

Internal access to the API is managed with authorization. The API Gateway forwards the token in authentication step to the API endpoint, and the token includes both information about the requester and the customer as a claim (in those cases where a person is logged in the client application).

The simplest way to implement authorization then is to create internal policy config, in which it specifies the client name and allowed methods (e.g., identity: client1, permissions: PUT/GET), so API is just validating the user access by checking if the token forwarded from API gateway matches the policy. For the internal service or an internal user, they need to be added to the policy config in order to send request to specific API endpoints.

Another way to apply access policy is using Authorization server. Refer to here for more details on the Authentication and authorization workflow.

Note

(1) Nginx also supports access control with map (example showing here) to simplify the processing for the API endpoint, however, the internal authorization is still needed.

(2) You may be interested in other API gateway use cases, take a look at Google Cloud and AWS. They support Identity and Access Management (IAM) to control access to API, and it includes authentication, authorization and access control (AAA) in the gateway. The policy apply and enforce process is similar with what I describe above on "internal policy config".