Use cases
This section outlines use cases in which applications have to support for secure and instant communication between services/machines.
Table of contents
API Key Management
The first scenario involves API Key Management, it behaves differently than Service-to-Service Tokens. When SaaS applications have their own set of APIs that need to communicate with their customer machines without using the user's identity.
A set of API keys are generated from the SaaS application which can then be sent from the customer's API request via a HTTP header.
Service-To-Service Tokens
Service-to-service tokens are often used in more distributed systems, where microservices need to communicate with each other. It's about both authentication and authorization.
In this case, we don't have a user identity that initiates the process by generating a set of API keys on an application side.
The generated tokens are often JWTs, containing claims that can specify the identity of the service, the scope of access and the token's expiration time. For more details regarding the JWT structure, refer to Credentials
Services like HashiCorp vault are often used to manage tokens for each service in a cluster.
Authenticating services within CI/CD Pipelines
This use case involves creating a service designed for integration within CI/CD workflows. There are two options here:
- [Recommended] OpenID Connect can be used to replace CI/CD credentials
- [Alternative] CI/CD credentials with static API keys generated from each service
OpenID Connect
OpenID Connect can be used to replace CI/CD credentials. As a reference, AWS allows GitHub actions to access resources without needing to store credentials as secrets, through the usage of OpenID Connect.
The client is a cloud provider such as AWS. The end user is a job running in a CI/CD pipeline. The benefits are:
- Infrastructure as Code (IaC) compatibility
- Short-lived credentials
- No need for manual credential management