In this post, we’ll cover Authentication when using API Gateways.
Authentication for API Gateways
API Gateways act as a control point for the outside world to access the various application services running in your environment — whether they are monolith workloads in a datacenter, microservices in the cloud, or serverless like Lambda or Google Functions. With the migration to microservices architecture, your application is likely a collection of any number of these workloads that either talk to each other or are accessible by end users (clients).
Depending on the service, you may want to establish who the caller is, what service(s) they’re requesting, and define a level of access control for that service. Incoming requests can be either treated as either anonymous or authenticated. While not all services will require authentication, the rules need to be defined at the per service level so that each incoming request is authenticated before routing to its destination. Traffic-control capabilities like rate limiting can be defined for both authenticated or anonymous clients. Both authentication and rate limiting equip the system to proactively handle misbehaving clients, whether malicious or simply mis-configured.
Example of an authentication scenario
An example of a scenario requiring auth is an API exposing details about a customer’s order. This “order status” API will allow other parts of the system to retrieve information about a customer’s order but will only allow access for certain services. At some point in the future, you may want to expose this service directly to customers as well. Whether internal access or direct from customers, we want to limit customers to view only their orders. For this, we will want to establish who the calling service or user is by authenticating them. There may be many such examples as the order status API throughout the microservice architecture, and an API Gateway can securely and consistently implement this authentication functionality without burdening the applications themselves.
Authentication in Gloo API Gateway
Gloo is a next-generation API Gateway available in open source and enterprise editions. Built on Envoy Proxy, Gloo is lightweight, highly performant with a pluggable architecture that makes it easy to add features or integrate it to any system. Authentication is a feature available in Gloo Enterprise and supports a variety of authentication options to meet the needs of your environment. They range from supporting basic use cases to the complex and fine grained secure access control.
Gloo provides a few different options for authentication:
- OpenID Connect (OIDC)
- Custom Auth to use your own auth service and custom auth logic
- Basic Auth
- Mutual TLS
- JSON Web Tokens (JWT)
Architecturally, Gloo uses an auth server to verify the user and their access. Gloo provides an auth server that can support OpenID Connect and basic use cases but also allows you to use your own auth server to implement custom logic.
OpenID Connect (OIDC)
Gloo supports authentication with external OpenID Connect (OIDC) identity providers with the included external auth server. This is a good way to provide end-user identity and authentication to your applications within the cluster through the API Gateway. Once validated, a token can be used to represent the identity and scopes of the end user.
Custom Auth
If you already have an authentication server and specific rules for user auth to services defined, then Gloo can support a configuration where it uses your auth server to implement the custom logic for authenticating and routing the incoming user requests.
Basic Auth
For simple use cases or testing purposes, we can enable basic authentication through the Gloo API Gateway. Recall, basic authentication is performed on the Authorization: Basic <credentials> header in the request and validates it with a backend credential store.
Mutual TLS
Mutual TLS is a mechanism that requires the client to send its certificate and for the server to verify the certificate using its trust store. In this approach, using public key infrastructure such as Certificate Authorities and Public Certificates, we can assert that the client making the call to the server is indeed that client.
JSON Web Token (JWT)
For organizations interested in using or already using JSON Web Tokens (JWT), Gloo supports JWT validation for authentication in the API Gateway using the JWT extension and can support the use of multiple providers.
API Gateways can act as an aggregate control point to manage client access to many backend services in the migration to a microservices architecture. The ability to secure and control that access at a per service level becomes increasingly important as the number of services grows. Understand the options and flexibly architect secure access to support the needs of your application.
To Try Authentication in Gloo Enterprise
- Register for a trial of Gloo Gateway Enterprise
- Read the documentation and try a tutorial
- Join the community to start a discussion and ask questions
