TeamCity adds OIDC JWT plugin to replace static CI/CD credentials with short-lived tokens

TeamCity’s new OIDC JWT plugin addresses a long-standing security gap in CI/CD pipelines: the reliance on static credentials. These credentials are often embedded in configuration files, logs, or artifacts, where they can be leaked or misused. By replacing them with short-lived OIDC tokens, the plugin eliminates a persistent attack surface. The tokens are cryptographically signed and bound to specific audiences and validity periods, reducing the blast radius of a compromise. This aligns with broader industry trends, where cloud providers and SaaS platforms increasingly support OIDC for workload authentication.

The plugin’s implementation balances flexibility with security. Signing keys can be rotated without immediately invalidating existing tokens, which prevents disruption to running builds. For publicly accessible TeamCity instances, the plugin automatically serves the required OIDC metadata and JWKS over HTTPS. Private instances can host these documents externally, ensuring secure validation without exposing the TeamCity server itself. The plugin also supports extensibility, allowing integration with external key management systems like hardware security modules (HSMs) or cloud KMS, which may be critical for compliance-sensitive environments.

Adopting the plugin requires careful configuration to avoid breaking existing integrations. The issuer URL, signing settings, and key rotation policies must be set before enabling OIDC for builds. The plugin provides a build feature to generate tokens at runtime, storing them in build parameters with configurable lifetimes. While this simplifies initial setup, teams must ensure their external services are configured to trust the TeamCity issuer and validate tokens correctly. The shift to OIDC may also require updates to monitoring and logging practices, as token-based authentication introduces new failure modes, such as expired or misconfigured tokens.

The plugin’s reliance on OIDC standards ensures compatibility with major cloud providers, but its effectiveness depends on proper implementation. For example, some services may require additional token exchange steps to obtain service-specific credentials. Teams must also consider the operational overhead of managing signing keys and monitoring token usage. While the plugin reduces the risk of credential leaks, it does not eliminate the need for secure key storage or access controls. The default behavior of not invalidating tokens during key rotation may also pose risks if a key is compromised, requiring teams to weigh convenience against security.