In Nginx plus configuration you have something like
# IP where the upstream API is hosted
# 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
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
- 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".