Security at the Edge: Authentication and Authorization for APIs
I was watching a developer give a demo recently, and part of it included a look at a dashboard of incoming requests and the response codes. I asked the developer how she was generating the request traffic. “Oh I’m not,” she replied. “I’ve just had a public IP up for more than 10 minutes, and people are hitting it looking for vulnerabilities.”
I’m used to protecting an active website but not a random IP address. That is the reality of today’s web development environment. If you have an API that operates over a network, you have to secure it because someone is going to attack it, guaranteed.
Ideally, you can immediately enact a zero-trust model, where even traffic inside your network is checked at all stages. But implementing systems, whether they are security, deployment, continuous integration or otherwise, is often done in steps. A great place to start with network security is at the edge of your network, where it interacts with users and attackers.
Often an API gateway will be the first part of your system to receive a request, making it a good tool to be your first line of defense. In general, in a cloud native architecture, we try to remove as much burden from application developers as possible by extracting functions like observability to sidecar services.
The same is true of authorization, and handling authorization in your API gateway is like having a sidecar for your larger system. There are two major domains of security an API gateway should be able to handle itself or have integrations for:
- Authentication (Authn)
- Authorization (Authz)
We’ll focus here on these topics as they relate to API gateways, but if you need a primer on either, Auth0 has great guides to both authentication and authorization.
Authentication and Authorization
In brief, a system uses authentication and authorization processes to answer two questions for a given request:
- Who made this request? (authentication)
- Are they allowed to do what they are trying to do? (authorization)
This is true whether the request comes from outside or inside the system, as in a request from another service or in an identity and access management (IAM) system. Some tools overlap both functions. For example, a JSON Web Token (JWT) can be used to identify a user and to contain a list of authorized permissions in its payload.
Authentication for APIs
The core of authentication is checking a user’s credentials against a known entity and sending back a credential of some kind for the user to send in subsequent requests, whether that’s a JWT, a session cookie, etc. What you are looking for in an API gateway is built-in compatibility with as many of the standard authentication methods as possible and extensibility, so that you can use other methods the gateway doesn’t have built-in.
Some common methods of authentication to look for in an API gateway are:
- Basic authentication — also known as “username and password.”
- OpenID Connect (OIDC) — this is the tool used for single sign-on (SSO) by most major providers like Azure Active Directory, Google, Github, Okta, etc.
- JWT — to receive a JWT, a user will need to have authenticated in some other way but will send the JWT for future requests for as long as the token is valid. Quickly validating the JWT at the point of entry is highly convenient.
Extensibility
It is common for large business systems to end up with a custom or uncommon authentication system for an older or highly bespoke service. You may not need to be able to extend your API gateway’s authentication system when you first start using it, but it’s always nice to know that you can. Typically, this will look like a feature allowing you to configure the API gateway to send a request out to an external service that you create and receive back a response approving or denying the request.
Authorization for APIs
Authorization is a trickier subject because it is often business- and domain-specific. Even when there are common types of authorization systems like role-based access control (RBAC), the roles and what each role can do would be specific to your system. That said, there are a few capabilities to look for in an API gateway that can be considered authorization, and you can look for the ability to integrate it with your systems, the same as with authentication.
Authorization Capabilities of API Gateways
If authorization is trying to answer the question, “What are you allowed to do?,” then there are some permissions at the edge of your network that your gateway should be able to validate:
- Are you allowed to make this request at all? Your API gateway should be capable of returning an immediate 403 or equivalent “Not authorized” response if a user attempts to make a request they should not.
- How fast are you allowed to make requests? Rate limiting is a form of permission and is within an API gateway’s wheelhouse. Ideally, you should be able to configure your gateway to rate limit globally, by IP address and user ID.
- To where should you be allowed to make requests? The systems that should handle your requests can be a part of authorization. For example, in a multiregional architecture, you might require that EU customers can only make requests to EU servers as Monday.com does. Your API gateway should be able to do dynamic routing to support that.
- Work with OAuth2, which is often found where you use OIDC. Where OIDC verifies your identity, the OAuth2 protocol provides access authorizations with the same systems.
Integration
The multiregional architecture example is the beginning of a larger pattern. Your API gateway should be able to send requests out to your authorization service and receive back instructions on what to do with them. Should they be forwarded? Redirected? Dropped? Because authorization tends to be bespoke, but you want to protect your network at its edge, your edge needs to be able to integrate with your bespoke systems.
Start at the Edge
API security is a requirement now when an attacker is always probing your network, looking for a way in. Without it, you are one bad day away from a breach and very unhappy customers.
Just as you might start with implementing TLS at the edge of your network with an API gateway and then add in mutual-TLS between internal services using a service mesh, you can implement security measures at the edge while working toward a full zero-trust system.
If you want to learn more, the latest edition of the online KubeCrash event, March 22 – 23 will dive deeper into the topic of zero trust, covering topics from the ingress to service mesh to certification generation and policy enforcement.
