Three best practice approaches to authentication

Summary

This article describes three distinct architectures for implementing application user authentication:

1. Service-level authentication
2. API-gateway authentication
3. Service-mesh authentication

In the sections below, we have outlined the pros and cons associated with each along with our recommendations for implementation.

1. Service-level authentication

With this architecture, services are responsible for implementing authentication. In most cases, this is done using a library or SDK which handles the actual authentication flow, such as Spring Security.

Pros

• Avoids “Death Star security” model by requiring each service to authenticate requests.
• Many off-the-shelf tools available to implement authentication, such as Spring Security, so in practice this shouldn’t be a heavy lift.
• Since authentication is controlled by the service, it can control which endpoints are authenticated and which aren’t, obviating the need for coordinating with a central API gateway.

Cons

• Authentication could be implemented incorrectly or missed altogether by development teams. There should be security review processes to manage this risk.
• Must be implemented for different programming languages if services are not standardized on a single language.

Implementation Recommendations

Avoid stateful user sessions. Instead, rely on stateless token authentication. In this case, once the user has authenticated, there are no further calls necessary to the authentication service since tokens can be validated using asymmetric signatures (private/public key pair) and expiry dates. This method works with both OAuth2 JWTs and SAML 2.0 assertions. Revocation is harder with this approach since services are not calling into an authentication service to check if a token is valid. This is solved using aggressive token expirations and relying on token refreshes or, if real-time revocation is a requirement, using a distributed blacklist.

2. API-gateway authentication

With this architecture, an API gateway handles the responsibility of authenticating requests before routing them to downstream services. This gateway may also handle other “edge” responsibilities such as load balancing, dynamic routing, rate limiting, traffic monitoring, etc. All ingress traffic must flow through the API gateway as the network is firewalled.

Pros

• Downstream services do not need to implement authentication. Instead, they assume requests were authenticated upstream.
• An API gateway or proxy is already likely to be a part of any microservice architecture, so authentication dovetails nicely.

Cons

• Promotes “Death Star” security. If an adversary gains access to the network, they can start making requests to services without authenticating. For defense in depth, a combination of architectures #1 and #2 would provide layered security. In this case, the gateway would enforce authentication and services would also perform authentication, rejecting any unauthenticated requests. Additionally, ingress to the downstream service could be restricted to the upstream proxy.
• In order to support unauthenticated endpoints, the API gateway must have knowledge of service APIs and which are authenticated and which aren’t. This would probably come in the form of a configuration file for each service. This might become a process bottleneck for configuration changes and a misconfiguration could cause availability issues.

Implementation Recommendations

There are many off-the-shelf API gateway services and proxies available. For example, Kong is an open source API gateway which provides dynamic routing, monitoring, authentication, and other capabilities using a plugin-based architecture. Apigee is a managed API gateway service that provides similar capabilities.

As mentioned in the first architecture described above, this should rely on stateless token authentication. For modern services, this is typically done using OAuth2/OpenID Connect.

3. Service-mesh authentication

A service mesh is an architectural pattern by which a sidecar proxy is deployed alongside service containers. This proxy can provide capabilities like authentication, authorization, load balancing, TLS termination, resiliency, and monitoring transparently to services since all traffic flows through the proxy.

Pros

• Downstream services do not need to implement authentication. Instead, they assume requests were authenticated upstream.
• Avoids “Death Star security” since containers are locked down and all traffic must go through the sidecar proxy.
• There are many other benefits to this pattern — such as mutual TLS, load balancing, resiliency, observability, and authorization — all handled transparently to services.
• The Kubernetes community is quickly coalescing around service mesh as a standard pattern.

Cons

• Most solutions do not yet fully support end-user authentication but rather are focusing on authentication for service-to-service communication.
• While the community is coalescing around service mesh, it is still maturing and quickly evolving.
• Service meshes can add significant performance overhead and operational complexity to Kubernetes environments and can introduce significant blast radius due to their cross-cutting scope.

Implementation Recommendations

There are off-the-shelf service mesh solutions available. The most commonly used are Istio and Linkerd.

Combining architectures #2 and #3 would work well since the gateway would handle ingress end-user authentication and the service mesh would handle mutual authentication between services, i.e. handling mutual TLS authentication transparently to development teams.

Want to know more?

We have extensive experience with the design and implementation of each of the authentication architectures outlined here.

If you have questions or would like to discuss any of these patterns a bit more, we’d love to hear from you. These emails come directly to us, and we respond to every one.