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?

  • To ensure that the api big_red_and_dangerous_button is only used by applications/users who are allowed to use it, instead of also allowing 2 week old intern to use it too.
    – Kain0_0
    Dec 1, 2020 at 3:57
  • @Kain0_0 Interesting explanation - reminds me movie scenes when someone need to fire a nuke ;) So then both ways should be implemented then not just authentication on API Gateway? Dec 1, 2020 at 4:01
  • 1
    You would have nginx authenticate and pass on the identity to the back end servers that then map that identity to a set of authorisations. Those authorisations determine what a user can and can't do. Now if you don't want that sort of integrated authority then use a token service. As for API keys someone else might be able to point you on the right path, but they run counter to nginx being your authenticator.
    – Kain0_0
    Dec 1, 2020 at 4:16

1 Answer 1



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


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.


(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".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.