The Trivy Compromise: The Fallacy of Secrets Management and the Case for Workload Identity

JWT and OAuth show up together in nearly every authentication system, which is why engineers often treat them as interchangeable. They are not. OAuth is an authorization framework that defines how to grant access. JWT is a token format that defines how to package and transmit claims. They solve different problems, and most production systems use both. The confusion between them leads to real security gaps, especially in machine-to-machine communication, where workloads cannot use browser logins or MFA prompts. Understanding where JWT ends and OAuth begins is the first step toward implementing workload authentication correctly. OAuth 2.0 governs how applications obtain limited access to resources without exposing credentials. It specifies multiple authorization flows for different scenarios and manages the lifecycle of access tokens: issuance, scoping, refresh and revocation. OAuth determines what a requester can access, not who they are. The authorization code flow is designed for web applications where server-side code can securely store secrets and handle user consent. The client credentials flow is built for machine-to-machine communication where no user interaction occurs: services authenticate directly to the authorization server using their client ID and secret to receive access tokens. Token exchange (RFC 8693) enables workloads to swap one token type for another across trust boundaries, such as exchanging an AWS IAM token for an Azure access token. JSON Web Token (JWT) is a compact, URL-safe token format for transmitting information between parties as a signed JSON object. Every JWT contains a header declaring the signing algorithm, a payload carrying claims (issuer, subject, audience, expiration, permissions) and a cryptographic signature that proves the token has not been tampered with. Because all necessary information is embedded in the token itself, receiving services can validate JWTs locally without calling back to a central server. The core distinction is that OAuth is a protocol defining a process, while JWT is a format defining a data structure. In practice, OAuth often issues JWTs as its access tokens, which is why the two appear together so frequently. In most production systems, OAuth and JWT complement each other rather than competing. OAuth 2.0 defines the authorization flow and token lifecycle. OpenID Connect (OIDC), an identity layer built on top of OAuth 2.0, adds authentication by issuing ID tokens as JWTs that contain verified claims about the authenticated entity. A typical workload authentication flow using both protocols: This pairing works because OAuth handles the complexity of token issuance and lifecycle management while JWT enables the resource server to validate tokens locally without calling back to the authorization server on every request. In distributed systems with hundreds of microservices, that local validation eliminates a network round trip on every API call. The confusion between JWT and OAuth often stems from their overlapping presence in this flow. When engineers refer to "OAuth authentication," they are usually describing OAuth authorization combined with token-based identity verification using JWTs issued through OIDC. Recognizing that distinction prevents architectural mistakes like using raw JWTs for authorization decisions without an OAuth framework to manage their lifecycle. OAuth 2.1 consolidates years of security lessons into a single specification (currently in late-stage IETF draft, not yet published as a final RFC, but widely adopted by major authorization servers). It deprecates the implicit flow and resource owner password credentials flow, requires PKCE for all authorization code flows, requires refresh tokens for public clients to be either sender-constrained or one-time use (making rotation the standard implementation in practice) and recommends sender-constrained tokens through mutual TLS. For workload and machine-to-machine use cases, OAuth 2.1 standardizes how client credentials are exchanged, how access tokens are scoped and how token exchange (RFC 8693) works across environments. Emerging frameworks for AI agent interoperability, including the Model Context Protocol (MCP), depend on these principles. OAuth 2.1 enables standardized authorization between agents, services and APIs using short-lived, verifiable JWTs without persistent secrets. Applying OAuth and JWT to workloads introduces challenges that do not exist in human authentication. Humans can use MFA, push notifications and browser logins. Workloads cannot. They rely on certificates, attestation or tokens, which means the traditional OAuth client credentials approach of storing a client secret in a container image or environment variable creates a persistent attack vector. Attestation-based authentication addresses this by eliminating long-lived secrets entirely. Instead of managing stored credentials, workloads authenticate using cryptographically verifiable identity claims about their runtime environment: the cloud instance they run on, the Kubernetes namespace they belong to, the security posture of their host. The authorization server validates these claims and issues short-lived JWTs scoped to the specific resources the workload needs. The workload never handles a persistent secret, and the JWT expires after a brief window, limiting exposure if intercepted. For multicloud and hybrid environments, workload identity federation extends this model across cloud boundaries. A workload in one cloud presents its cryptographically signed identity token, which the target authorization server validates and exchanges for a new JWT scoped to local resources. This eliminates the need to provision duplicate service accounts across clouds while maintaining the same secretless security model. The right implementation depends on how many clouds you operate in, whether you can modify application code and how much credential management overhead you can absorb. Each pattern below applies OAuth and JWT differently based on those constraints. Use cloud-native managed identities. AWS IAM roles, Azure Managed Identities and GCP Service Accounts implement OAuth and JWT internally while eliminating credential storage. Your application authenticates through the cloud's metadata service and receives JWT access tokens without managing secrets. Kubernetes ServiceAccounts provide pod-level identity within a cluster and can be projected as OIDC tokens for federation with cloud IAM. This approach works well within a single cloud but requires federation for cross-cloud access. Implement workload identity federation with centralized policy. Use OAuth 2.0 token exchange (RFC 8693) to enable workloads in one cloud to access resources in another. A workload presents its home-cloud JWT, which the target authorization server validates and exchanges for a new JWT scoped to local resources. This requires a federation platform that can validate tokens from multiple issuers and enforce consistent policy across clouds. The benefit is that you avoid provisioning duplicate service accounts and managing separate credential stores in each cloud. A single identity assertion, verified cryptographically, grants access across trust boundaries. Use a broker or proxy pattern. A proxy intercepts outgoing requests from a microservice, handles OAuth flows, JWT validation, token refresh and credential injection transparently. The application makes standard HTTP requests without any awareness that the proxy is managing authentication. This pattern is particularly useful for AI agent and MCP integrations where modifying the application code is not practical. If you are evaluating JWT vs. OAuth for a new project, start by clarifying what problem you are solving. If you need to package signed claims for stateless validation, JWT is the format. If you need to delegate and control access across services, OAuth is the framework. Most production systems need both: OAuth to manage the authorization lifecycle and JWT to carry the resulting access information. For workload authentication, the priority is eliminating static credentials. Every client secret stored in an environment variable or config file is a credential that can be leaked, stolen or reused. Moving to attestation-based authentication with short-lived JWTs issued through OAuth flows removes that attack vector entirely. Start by auditing which workloads still rely on long-lived client secrets and identify which can be migrated to identity federation or managed identities. Aembit implements this model at scale. The platform uses environment attestation to prove workload identity through the OAuth 2.0 client credentials flow with cryptographic verification rather than traditional client secrets, then issues short-lived JWT access tokens with automatic refresh. The platform handles cross-cloud federation, conditional access policies and transparent credential injection so that developers never write authentication code.