Follow one token. The server signs a JWT carrying information about the build, a validity period, an intended audience, and an issuer URL [3]. The build presents it to AWS or Google Cloud. From there the consumer does four things:
1. Reads the issuer URL and fetches `{issuer_url}/.well-known/openid-configuration` [4]. 2. Follows that document to the issuer's JWKS and pulls the public keys [4]. 3. Verifies the token signature against those keys [5]. 4. Checks that the audience is one it expects and that the token has not expired [5].
Then the token is either accepted as it stands or exchanged for service-specific temporary credentials [7].
Step one is the constraint that shapes the rest of the design. The party doing the fetching sits outside your network, and OIDC requires the `https` scheme for issuer URLs, so the metadata document can only be served over HTTPS [6]. Something of yours has to answer that request. JetBrains' way out is the configurable issuer URL [14], which means the internet-facing thing can be a directory with two JSON files in it while the build server stays where it is. I will take that trade. JetBrains also advises getting the plugin configured before you wire OIDC into builds, since configuration changes can disrupt existing integrations [18].
Here is the default worth reading twice: rotating a signing key is tuned to protect work in flight rather than to cut off tokens already handed out [12]. So rotation and revocation are separate operations here. A token that leaked into a build log survives the retirement of the key that signed it and stays usable until its own validity period runs out, because expiry is the only liveness test the consumer applies [20]. That is the right default for uptime, and it means containment depends on token lifetime, since rotating the key in the UI leaves already-issued tokens live [11].
Trust also relocates, and that is the deeper change here. A consumer authenticates the workload on a valid signature plus the audience and expiry checks [5], so every cloud role configured to trust your issuer is reachable by anything that can get that key to sign for the right audience [21]. Which is why the extension API matters more than it looks: the plugin lets other plugins add signing backends, including external HSMs or key management services such as Google Cloud KMS, through a simple interface [15]. Out of the box, though, the private key lives with the TeamCity server acting as identity provider [9], signing with RSA- or ECDSA-based algorithms [10].
JetBrains' case is that static credentials leak through logs and artifacts and need regular rotation to satisfy policy [2], and that the major providers already accept short-lived OIDC tokens in their place [22]. Both are fair. The saving transfers to your shop only if your token consumers support workload OIDC [22], your server is on 2025.11 or later [16], and your role trust policies can condition on claims specific enough that a build from an untrusted branch cannot mint production credentials. The post describes claims generically as information about the workload and does not enumerate what TeamCity emits [23], and the published text breaks off while naming the build feature that supplies the token [19]. So that third condition is the one you cannot check from the announcement. If audience is the only thing you can pin a role to, your role trust now rests on a single shared signer in place of the shared secrets it replaced.
