What is Service-to-Service Authorization?
A microservice application comprises small autonomous services that communicate with each other through application programming interfaces (APIs) — as standalone services or via a service mesh. These API calls or requests raise security and compliance concerns if not appropriately secured through authentication and authorization checks.
Service-to-service authorization is the process of determining what actions an authenticated service is allowed to perform based on pre-defined policies.
Although microservice authentication standards exist, authorization remains a security pain point. According to our 2022 Cloud Alignment Report, 65% of devs considered security the biggest challenge to adopting cloud-native tools.
This article discusses service-to-service authorization, the challenges of inter-service authorization and how to resolve them.
Service-to-service authorization challenges in microservices
Microservice architectures provide teams with several benefits, such as faster development and scalability, with the ability to update individual services continuously, which is why they’ve become a popular option with widespread adoption. According to the IMARC Group, the microservices market will grow to $6.84 billion by 2027, up from $2.76 billion in 2021. New software development techniques, however, bring with them new challenges.
Here are some obstacles developers encounter when implementing service-to-service authorization in microservices:
- A greater number of exposed APIs: Monolith applications usually have a few pieces, such as a frontend, a backend and a database. Developers could easily design an authorization solution within the application to handle internal and external access control requests. In contrast, microservice applications may have hundreds of parts and exposed APIs that need to be secured.
Hardcoding authorization logic within each service would be impractical and prevent scaling. Additionally, without effective service-to-service authorization, you risk exposing your application to unhindered lateral movement by malicious actors.
- Polyglot architecture: Teams working on individual services within a microservice application may use the technology stack they are most familiar with, resulting in an application made up of different programming languages. You would need an inter-service authorization solution agnostic to all languages and technologies.
- Latency concerns: Due to a large number of API calls within microservice applications, a centralized authorization solution can add too much latency. This high latency could lead to slow responses to requests and a poor user experience. At the same time, security and compliance teams still need a holistic view of all authorization policies and decisions.
- High release velocity: Thanks to continuous integration/continuous development (CI/CD) pipelines, new services are constantly added and updates are rolled out for existing services. According to a survey by Dzone, 71.2% of respondents reported a higher feature velocity after adopting a microservice strategy.
These additions and updates happen without affecting other services within the application. While this agility is one of the main benefits of the microservice approach, it also means each new service needs to be added to the authorization framework.
Interested in learning more about microservice authorization? Enroll in a free course at Styra Academy to learn everything you need to get started.
How to implement inter-service authorization
As microservice applications scale, developers often implement a service mesh to control all request traffic between services. A service mesh deploys sidecar proxies alongside services to externalize functionalities such as security and monitoring. A mutual transport layer security (mTLS) connection secures all communication channels between these proxies.
You can simplify a microservices strategy further by offloading authorization decisions to a policy engine like Open Policy Agent (OPA). As a powerful open-source policy engine, OPA can deploy next to each sidecar proxy in microservices to handle externalized access control decisions with minimal latency.
As an example, here is one hypothetical authorization flow for this framework:
- Service A and service B are connected using service mesh proxies and authenticate each other using access tokens generated by the mTLS connection.
- The sidecar proxy of service A sends a request to the sidecar proxy of service B, including identity information. For example, a payment microservice (service A) requests service B to add order history to the user’s profile.
- The service B proxy forwards the request to OPA.
- OPA evaluates the request against pre-defined policies and returns an allow or deny decision. Additional policy data may also be considered if necessary.
- If the request is denied, the proxy returns a 403 code and service B never even sees the request. On the other hand, if the request is allowed, the sidecar proxy transparently forwards it to its service.
Along with its Rego policy language, OPA was developed by Styra to provide a fine-grained domain-agnostic authorization solution for your entire cloud-native stack. Since OPA returns all decisions in JSON format, it allows integration with any programming language, making it ideal for polyglot configurations.
OPA can be deployed as a policy decision point (PDP) at all layers within the microservice application to secure request traffic to, from and between services. Thanks to decoupled policy as code, developers can also easily update policies without affecting the business functions of the service itself.
Centralized control over distributed systems with Styra DAS
Within large microservice applications, hundreds or thousands of OPA deployments may be running simultaneously. Fortunately, OPA exposes APIs that enable central management via a control plane. Styra Declarative Authorization Service (DAS) is the OPA control plane of choice for massive enterprises and small teams alike.
Styra DAS comes with built-in policy libraries and shareable policy packs, saving teams time and effort while increasing collaboration. Compliance violations are shown in real time within the dashboard, allowing administrators to act quickly.
Developers can also test the impact of policies before enforcing them, and historical data is archived for easy auditing of policies. As a ready-made authorization solution, Styra DAS and OPA enable dev teams to secure their applications and reach a faster time-to-market.
Try Styra DAS Free or request a demo to have one of our engineers guide you.
FAQs
What is service-to-service communication?
Service-to-service communication is how loosely coupled services in a microservice application interact with each other through API calls using protocols such as HTTPS. This interaction is also called east-west request traffic.
What is a sidecar proxy?
A sidecar proxy is a separate container used to decouple functions from the service instance, such as communication and security. Proxies are deployed adjacent to service instances and form the basis of service meshes.