Consumers

In this document, you will learn the basic concepts of consumers in APISIX and why you need them. You will be introduced to a few relevant concepts, including how to pass consumer information to upstream, consumer access restriction, as well as consumer authentication and authorization.

Explore additional resources at the end of the document for more information on related topics.

Overview

In APISIX, a consumer object represents a user, application, or host that sends requests to the API gateway and consumes backend services. It is used in conjunction with the authentication system; that is, every consumer is associated with at least one authentication plugin.

Consumer objects come in handy if you have different consumers sending requests to your system, and you need APISIX to perform certain functions, such as rate limiting, based on consumers. These functionalities are provided by APISIX plugins configured in consumers.

The following diagram illustrates an example of APISIX with one key-auth enabled route and two consumers, John and Jane. John and Jane each authenticates to the route with their credentials. Only authenticated requests are then allowed to access the upstream resource:

The configuration above ensures if a request is sent to APISIX:

• without any key or with a wrong key, the request is rejected.
• with john-key, the request is authenticated and forwarded to the upstream service.
• with jane-key, the request is authenticated and forwarded to the upstream service. The rate limiting plugin limit-count on the consumer also takes effect, limiting the number of requests to a maximum of 2 within any 5-second window. If the rate limit threshold is exceeded, the request will be rejected.

Note that when a consumer is successfully authenticated, APISIX adds additional headers, such as X-Consumer-Username, X-Credential-Indentifier, X-Consumer-Custom-ID, to the request, before proxying it to the upstream service. The upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.

Passing Consumer Information to Upstream

For certain use cases, such as logging, analytics, and auditing, you might want to pass consumer information to upstream services. Consumer information, by default, is not exposed to upstream; however, you can use proxy-rewrite plugin to include the needed information in the header:

{
  "plugins":{
    ...,
    "proxy-rewrite":{
      "headers":{
        "set":{
          "X-Consumer-Name":"$consumer_name"
        }
      }
    }
  }
}

Consumer Access Restriction

You can control request access to your API by imposing restrictions based on consumer name, HTTP methods, or other parameters in the consumer-restriction plugin.

For example, if you want to blacklist Jane from accessing your upstream service without changing any consumers configuration in the example from overview, you can update the plugin's configuration in route to the following:

{
  "plugins":{
    "key-auth":{},
    "consumer-restriction":{
      "blacklist":["Jane"]
    }
  }
}

Or, if you want to strictly allow FetchBot's access by HTTP GET method, you can update the plugin's configuration (in either the route or the consumer) to the following:

{
  "plugins":{
    ...,
    "consumer-restriction":{
      "allowed_by_methods":[
        {
          "user":"FetchBot",
          "methods":["GET"]
        }
      ]
    }
  }
}

The consumer-restriction plugin can also be used with routes, services, and consumer groups.

Authentication & Authorization

There are two main design patterns for building authentication and authorization in an APISIX-based architecture.

The first and most commonly adopted approach is to authenticate and authorize requests through a third-party identity provider (IdP), such as Keycloak:

In some environments, a request might need to go through more than one IdP before it can be forwarded to the upstream service. In such cases, you can configure multiple authentication plugins, each corresponding to an IdP, on one consumer; only when all IdPs have granted access to a request will APISIX show success response.

With multiple authentication plugins in place, the plugins order of execution is determined by the plugin's priority, which can be overridden with _meta.priority.

The second and a more basic approach is to perform authentication and authorization on the API gateway itself, using key-auth, basic-auth, jwt-auth, hmac-auth plugins:

For details about how to configure authentication and authorization for your specific needs, please refer to the authentication chapter in How-To Guides (coming soon).

Additional Resource(s)

• Getting Started - Configure Key Authentication
• Admin API - Consumer
• consumer-restriction plugin
• Key Concepts - Credentials