In the past year, the Aembit Workload IAM Platform has added support for multiple authentication methods. As the complexity of integrating these methods with third-party services increased, we initiated a project to outline the necessary steps for configuring these services alongside Aembit to enhance functionality.
As part of this project, we defined what type of workload-to-workload authentication we want to steer our customers toward – obviously with the preference of choosing more secure options.
How do we evaluate the security strength of different authentication methods? We devised a classification system, illustrated through a matrix below, to rank these methods based on their security effectiveness.
For the graph to make sense, however, it’s critical to understand the difference between identity credentials and access credentials. Identity credentials are credentials that identify and authenticate the client. Access credentials are credentials that authorize the client’s access to the service. Too often these two are conflated, while they are separate and unique.
Consider the distinction in a familiar context: Your driver’s license acts as an identity credential, confirming your identity but not granting access to specific resources. Contrastingly, a hotel room card serves as an access credential – iit allows entry to your room but doesn’t attest to your identity. Possession of the room card enables anyone to unlock the door, illustrating that while it provides access, it does not validate who you are.
Returning to the topic of workload-to-workload authentication methods, let’s start with a well-known example before expanding the discussion to other methods.
Seven Methods for Workload-to-Workload Authentication
1) Stateless Token Authentication (API Key Authentication)
This is the traditional and likely most common approach: You generate an API key on the server, provision it to a client workload, and the client uses it for authentication. It’s straightforward and easy to wrap your head around, yet it has significant drawbacks. First of all, there’s no separation between identity and access credentials. If the API token is compromised, the attacker gains access and can impersonate your client.
Moreover, the situation is exacerbated by the API token’s long lifespan and its compromised secrecy—requiring provisioning to your client workload and frequent transmission. Essentially, the token passes through too many human and software hands, undermining its security integrity. As a result, this method of authentication is inherently risky and there are a lot of negative implications if the token is leaked.
2) Credential-Based Authentication (Service Accounts)
Service account authentication mirrors API key usage, designed for workloads rather than individual users. Workloads use a username and password for authentication, analogous to the API key, with no clear distinction between identity and access credentials.
3) Cryptographic Signature Authentication (AWS API Request Signature)
In this method you transfer your credentials (access key ID, secret key, and, depending on the usage pattern, session token) to the client workload. These credentials are then used to sign your API request, with, in this example, AWS verifying the signature to confirm the request’s authenticity (indicating possession of the secret access key). Similar to the first two on the list, this authentication has a lack of clear separation between identity and access credentials. Nonetheless, access credentials are shared with the client workload just once during initial provisioning and subsequently used for signing purposes, rather than being included directly in each request.
4) Asymmetric Key Pair Authentication (Example: Snowflake)
In this method, the client workload generates a public/private keypair. The public key is uploaded to the server workload (specifically, Snowflake in this example of the method.). The client workload creates a short-lived JWT token, signing it with its private key for authentication, while the server uses the public key for JWT validation.
Determining whether the keypair serves as identity or access credentials is difficult. One can argue the keypair is for identity verification, with the JWT acting as the access credential. Alternatively, taking into account that there is no identity server verifying the identity and issuing access credentials, the keypair itself might be seen as an indirect form of access credential. This method keeps the private key secure and ensures JWT tokens are short-lived. The risk of JWT exposure is mitigated by their brief validity, much like OAuth access tokens. The private key, which is not shared at all, is far less susceptible to leakage.
5) Network Ticket-Based Authentication (Example: Kerberos)
This approach uses tickets to manage authentication requests within a network. In this approach, a client workload initiates an authentication request to a centralized authentication server. Upon successful verification of the client’s credentials, the server issues a time-limited ticket. This ticket, encrypted to ensure security, authorizes the client’s access to a specified server workload without the need to resend credentials.
This method distinguishes itself by clearly separating the authentication process from the access granting process. The initial authentication step securely establishes the client’s identity, while the issued ticket, serving as an access credential, allows for subsequent service interactions. These tickets are constrained by both their scope and lifespan, significantly reducing the risk of unauthorized access. Kerberos, as a widely recognized implementation of network ticket-based authentication, highlights the strengths of this approach, including encrypted ticket exchanges and the reduction of credential exposure across the network.
A notable weakness of the Kerberos system, aside from its inherent complexity, is the manner in which identity credentials are managed and shared through “keytabs.” These keytabs, while integral to the Kerberos authentication process, introduce vulnerabilities as they store sensitive information that must be securely managed and shared among the client workloads. This sharing of identity credentials underpins why Kerberos is not positioned in the top right corner of our classification graph (below), indicating areas for potential security enhancement.
6) OAuth 2.0 Client Credentials (OAuth 2.0 Client Credential Flow)
In this more modern setup, the server trusts an OAuth 2.0 server. You register your client app, receiving a Client ID and Client Secret, which are then copied to the client workload. This workload communicates these credentials to the OAuth 2.0 server, obtaining a short-lived token for authentication.
The positive side of this approach is the clear distinction between identity credentials (Client ID and Client Secret) and access credentials (short-lived OAuth 2.0 access token). However, the downside is that you still have to handle the client secret securely, including periodically transmitting it to get new access credentials. Should access credentials be exposed, their short lifespan limits the breach’s impact. Yet, a leak of the Client ID and Client Secret poses risks similar to those with API token authentication.
7) Private Key JWT Authentication (OAuth 2.0 Private Key JWT)
This overall scheme looks similar to OAuth 2.0 Client credentials flow. The main difference is the client workload authenticates to the OAuth server using a JWT token, rather than a client ID and secret. Here, the client workload generates a keypair, uploads the public key to the OAuth server, creates a JWT, signs it with the private key, and sends this signed JWT to the OAuth server. The server then validates the JWT using the public key and issues a short-lived access token back to the client, which uses this token for server authentication.
This method stands out for its robust security, establishing a clear delineation between identity credentials (the private key) and access credentials (access tokens). The client secures its identity with its private key, while the OAuth server grants the access token. Notably, the client cannot independently generate access credentials, ensuring that identity credentials remain confidential and unshared with external entities.
Putting It All Together, Illustrated
The matrix below presents a two-dimensional analysis of various authentication strategies, illustrating how each method measures up in terms of credential strength and the degree of separation between identity verification and access permission. It is categorized by two dimensions:
- Identity credentials strength
- Separation of identity credential and access credentials
- Do you have to share identity credentials?
- Access credentials strength
- Long-lived vs. short-lived
- Do you have to share access credentials?
A Note About This Matrix
Categorizing authentication methods isn’t a straightforward task. There are ambiguous areas, such as whether to classify a Snowflake key pair as identity or access credentials, among other nuanced questions.
Moreover, there’s a wide array of authentication techniques that often overlap user and workload-to-workload authentication. Take, for instance, the OAuth 2.0 Authorization Code Grant, which begins with user identity and transitions to workload identity (via a refresh token) and access credentials (through an access token).
Identity federation schemes add another layer of complexity, allowing for the conversion of one type of identity credential into another, often weaving together multiple authentication methods in the process.
In constructing this graph, it became apparent that there’s potential for developing even more secure methods. While OAuth 2.0 Private Key JWT scores highly for its identity and access credential strength, there’s scope for enhancing the security of access credentials. Currently, the OAuth 2.0 token must be presented with each call. However, security could be improved by adopting a method akin to the AWS API Request Signature, where access credentials are utilized to sign the request itself. This approach eliminates the need to transmit access credentials with each interaction. Instead, the server verifies the request’s integrity through the signature, thereby significantly mitigating the risk of access credentials being intercepted during transmission.
Enhancing Security with Workload Attestation and Credential Management
Every authentication strategy outlined previously necessitates that the client workload hold some form of secret – be it directly provisioned, like a Client ID and Client Secret, or internally generated, such as a keypair. The inherent challenge lies in securely maintaining this secret.
Our conviction is that the optimal solution ensures client workloads are not burdened with secrets whatsoever. This is achievable through third-party attestation, which authenticates the client workload’s identity. By shifting the responsibility of secret management to a trusted third-party, the direct handling of secrets by the client workload itself can be eliminated.
Furthermore, the issue of managing short-lived access credentials can be addressed using a proxy setup, where credential management is delegated to the proxy. This method externalizes the complexities of access credential management away from client workloads, enhancing security and reliability.
Want to secure access to sensitive resources by validating access rights in real-time using the native identity of the workload and an access policy, instead of a static identity secret? Visit aembit.io to try the Aembit Workload IAM Platform for free.
The Workload IAM Company
Manage Access, Not Secrets
Boost Productivity, Slash DevSecOps Time
No-Code, Centralized Access Management
