In the world of microservices, secure communication between services is paramount. While user authentication is well-understood, a unique challenge arises when services need to talk to each other without an active user context.

This article delves into the intricacies of service-to-service authentication, focusing on scenarios where traditional user tokens are unavailable.

The Challenge: Authentication Without User Context

Microservice architectures often require services to communicate with each other, even in the absence of an active user session. This situation creates a significant challenge: how can we implement robust authentication and authorization between services when user tokens are not available?

Example Scenario

Imagine two services in a financial system:

• Service A: Handles nightly account settlements
• Service B: Manages user wallets

During nightly batch processing, Service A needs to update credit card information in user wallets by sending requests to Service B. As this process occurs without user interaction, we can’t rely on user tokens for authentication.

The Dilemma of User Tokens

In user-initiated requests, authentication is straightforward. User tokens are propagated across services, with each service validating the token and using it for authorization decisions. However, in scenarios like batch processes or system-initiated actions, there’s no active user context, rendering user tokens ineffective. This absence of user tokens necessitates alternative approaches to ensure secure service-to-service communication. Let’s explore some of the most effective solutions to this challenge.

💡 Service-to-Service Authentication Solutions

1. API Keys

API keys offer a simple, lightweight method of authentication. They serve as both an identifier and a secret, acting as a token for authentication. However, they require careful management to maintain security, particularly in key rotation and revocation.

How it works:

1. Service A is issued a unique API key.
2. Service A includes this key in the header or parameters of each request to Service B.
3. Service B validates the API key before processing the request.

Pros:

• Simple to implement and use.
• Low overhead.

Cons:

• Less secure if not transmitted over HTTPS.
• Typically doesn’t support fine-grained permissions without additional logic.
• Key rotation and revocation can be challenging.

---

2. JSON Web Tokens (JWTs) with Service-specific Claims

JWTs (JSON Web Tokens) provide a flexible way to represent claims securely between services. These tokens can contain custom claims specifying a service’s identity, permissions, and other metadata, making them ideal for fine-grained access control.

How it works:

1. A central authority issues JWTs to services with service-specific claims.
2. Service A includes the JWT in its requests to Service B.
3. Service B validates the JWT and checks the claims to ensure Service A has the necessary permissions.

Pros:

• Can include service-specific metadata and permissions in the token.
• Stateless authentication.
• Can be used with existing JWT libraries and infrastructure.

Cons:

• Requires secure signing key management.
• Proper token validation and claim checking are necessary.

---

3. Service Mesh Authentication

A service mesh (like Istio or Linkerd) is an infrastructure layer for microservices-based applications that handles service-to-service communication. It provides capabilities like traffic management, security, and observability without requiring changes to the application code. Key aspects include:

• Proxy sidecar: Typically implemented using lightweight network proxies deployed alongside each service instance.
• Traffic management: Load balancing, routing, and traffic control between services.
• Security: Encryption, authentication, and authorization between services.
• Observability: Metrics, logging, and tracing for monitoring and troubleshooting.
• Policy enforcement: Implementing rules for service interactions.
• Service discovery: Automatically detecting and registering new service instances.

How it works:

1. A service mesh (e.g., Istio or Linkerd) manages inter-service communication.
2. The mesh handles authentication and authorization between services.

Pros:

• Centralized management of security policies.
• Handles complex authentication scenarios.
• Provides additional features like traffic management and observability.

Cons:

• Adds complexity to the overall architecture.
• May introduce performance overhead.
• Requires expertise to set up and maintain.

---

4. Mutual TLS (mTLS)

Mutual TLS (mTLS) strengthens the standard TLS protocol by requiring both services to present certificates during the TLS handshake. This ensures that both the client (Service A) and the server (Service B) are who they claim to be. mTLS is particularly useful in zero-trust environments.

How it works:

1. Both Service A and Service B have their own TLS certificates.
2. During the TLS handshake, both services present and verify each other’s certificates.

Pros:

• Strong security, as it works at the transport layer.
• No need for additional tokens or credentials.
• Can be combined with other authentication methods for additional security.

Cons:

• Certificate management can be complex, especially at scale.
• Requires proper infrastructure for certificate issuance and rotation.

---

5. Our Way: Client Credentials Grant (OpenID Connect)

In our organization, we implemented the Client Credentials Grant based on the OpenID Connect standard to solve this problem. We already had an identity service that supports OpenID Connect, so we made the following adjustments to facilitate service-to-service communication.

How it works:

1. Registers a user for Service A with the authorization server once. This registration process is performed by the maintainers of Service A and is required only one time for long-term use. Here’s how the registration can be done:

    curl -X 'POST' \
      'https://identity.address/api/v1/account/register/service' \
      -H 'accept: text/plain' \
      -H 'Content-Type: application/json-patch+json' \
      -d '{
      "password": "YourPassw0rd",
      "serviceName": "ServiceName"
    }'
   

2. Service B’s maintainers can then assign the necessary roles and permissions to Service A, just as they would for regular users.
3. In the startup flow, Service A authenticates itself and receives an access token by calling:

    curl -X 'POST' \
      'https://identity.address/api/v1/account/service-token' \
      -H 'accept: */*' \
      -H 'Content-Type: application/json-patch+json' \
      -d '{
      "password": "YourPassw0rd",
      "serviceName": "ServiceName"
    }'
   

   This token is updated regularly in the background. We’ve implemented a library that handles token retrieval at application startup and refreshes the token periodically based on its expiration time, ensuring that Service A always has a valid token.

4. Service A includes this token in requests to Service B.
5. Service B validates the token with the authorization server—this step requires no changes to Service B’s code since it operates like other OAuth tokens.

Note: With this approach, Service A can call multiple external services using the same token, provided that the necessary claims have been assigned to it by the maintainers of those services. There’s no need for Service A to acquire separate tokens for each service; one token suffices, simplifying the process while maintaining security.

Why We Chose This Approach:

We already had an identity service that implements OpenID Connect, so we added a new user type called Service to it. This allowed us to handle inter-service communication securely using our existing infrastructure.

Pros:

• Well-established standard (part of OAuth 2.0).
• Supports fine-grained scopes for authorization.
• It uses our existing identity service and infrastructure.
• No changes required in Service B.
• A single token can be used across multiple services, streamlining inter-service calls.

Cons:

• Requires careful management of client secrets.

---

Conclusion

When user tokens are not available, service-to-service authentication becomes critical to ensure secure communication between services. Depending on the security needs, infrastructure, and scale, you can choose from multiple solutions such as OAuth 2.0 Client Credentials, Mutual TLS, API Keys, JWTs, or even a Service Mesh. Each method has its strengths and trade-offs, and in many cases, you might combine multiple approaches for enhanced security through defense in depth.