JetBrains has announced the new OIDC JWT plugin for the TeamCity platform, enabling build processes to authenticate with AWS, Google Cloud, and other services that support OpenID Connect without relying on static keys or passwords within the CI/CD environment. The plugin addresses one source of operational and security risks in build pipelines, as static credentials can leak through logs or build files and typically require periodic rotation to meet security requirements.
How does authentication work?
The flow relies on TeamCity issuing a cryptographically signed JSON Web Token on behalf of the build process. The token includes claims identifying the workload, its validity period, the intended audience, and the issuer’s address. Upon receiving the token, the external service verifies the signature using the public keys associated with the issuer, then checks the intended audience and validity period before using the claims to authenticate the build process.
Some services accept the identity provider’s token directly, while others perform token exchanges to issue their own temporary credentials. JetBrains leaves the details of configuring this flow to each service, directing users to the AWS or Google Cloud documentation when setting the audience and verification requirements.
What does the plugin add to TeamCity?
OIDC JWT adds the identity-provider capabilities required to issue tokens to the TeamCity server. The plugin supports signing tokens with RSA- or ECDSA-based algorithms, with the ability to rotate signing keys through the web interface or via an HTTP endpoint dedicated to authorized requests. According to JetBrains, rotating keys does not, by default, disrupt running builds or invalidate tokens that were previously issued.
For publicly accessible TeamCity servers, the plugin provides the .well-known/openid-configuration document and a set of public JWKS keys. For servers not exposed to the internet, a custom issuer URL can be configured and the discovery documents can be hosted on a public host using HTTPS, without making the TeamCity server itself public. The plugin also provides an API that allows other plugins to add new signing methods, including integration with hardware security modules (HSMs) or key-management services such as Google Cloud KMS.
Token issuance options and usage requirements
After installing and enabling the plugin from JetBrains Marketplace, it can be managed from Admin | Integrations | OIDC Tokens. It requires Java 17 and supports TeamCity 2025.11 and later. Administrators can specify the issuer URL, signing settings, and signing-key management.
The plugin provides two build features for issuing tokens. The first, OIDC Token (in build parameters), creates the token when the build starts and stores it in a specified build parameter. The validity period is configurable and defaults to the build timeout or 10 minutes when no timeout is specified. A token can also be issued for one or multiple audiences, with the option to add a separate feature when services require independent tokens for a single audience.
The OIDC Token (on demand via HTTP request) feature is suited to long-running builds, allowing scripts to request a short-lived token over HTTP during execution. These tokens are always valid for 5 minutes, and this duration cannot be changed.
Why does this matter?
The practical change is the shift from long-lived secrets to tokens tied to the build process and limited by duration and audience. This reduces the value of a token if it leaks, but it does not eliminate the need to configure permissions and carefully verify the issuer URL and audience. JetBrains warns that changes to the plugin’s settings may disrupt existing integrations, so it recommends configuring it before connecting builds to OIDC-based authentication. The solution’s effectiveness also depends on the target service supporting OIDC and on its official settings, points that must be verified separately for each integration.