What is Service-to-Service Authorization? - By Styra
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…
The Cyber Hut Comment: Styra, the organisation behind OPA (open policy agent) providing an interesting base article to describe the concept of service to service authorization. As organisations move away from monolithic applications (either breaking them down into smaller chunks, or just redesigning into a micro-service model) there comes a need for a further set of security, access and monitoring services.
In the old says, having a single application was relatively simple to manage from an IAM perspective - the exposed entry point to the system was often small (say one or two APIs and a UI), allowing a gatekeeper style model to be used. The gateway was often either a small piece of software like an agent or perhaps even hard-coded checks for both authentication data (tokens and assertions) as well as access control logic. This worked pretty well, if the number of apps was small and the number of access control changes relatively static.
In the API world of course, the number of instances is large, the speed of deployment is important and change is nearly constant. In this approach, a new way to both authenticate each service to each other and authorize those requests becomes more critical.
A central approach to access decision making introduces too much latency, so something more distributed and local (to where the action happens) seems more sensible.
Here Styra are promoting the model where an instance of OPA is housed local to each independent service - allowing it to be queried for access control questions - as it contains the rules and data logic necessary to make such decisions. This allows the API or or service, to focus more on what it does best - deliver the functionality it was designed for - and off load authentication (typically via MTLS certs) and access control to a separately deployable component.
Why is this better? Well it helps decouple, but also allows a set of re-usable components to be created that can accelerate future deployments, but also provide a more consistent and iterative way of developing identity and access management components.
Clearly those components (the logic, deployment model, integration, instance identification, credential issuance, credential verification tools…) all now need to be managed too - which may well require a centralised UI for visibility and governance.
IAM Vendor Intelligence Radar by The Cyber Hut is a reader-supported publication. To receive new posts and support our work, consider becoming a free or paid subscriber.