Introduction
IntroductionAuthenticate without an API key (OIDC)Autheticate GitHub Actions with OIDCAuthenticate Jenkins and other providers with OIDCUse the CLI with Docker image
IntroductionChoose a value for build nameRecord builds from multiple repositoriesRecord builds for microservicesRecord builds for multistage buildRun under restricted networksDeal with shallow clones
Record sessions
IntroductionRequest and run a subset of testsSubset with the CloudBees Smart Tests CLIChoose a subset optimization targetObserve subset behaviorSmart subset optimization targetsZero Input SubsettingReplace static parallel suites with a dynamic parallel subsetUse groups to split subsetsCombine with rule-based test selectionCloudBees Smart Tests extension for VS code
IntroductionConvert test reports to JUnit formatEnsure record tests always runsManage complex test session layoutsUse 'flavors' to run the best tests for an environmentSeparate out test suitesAttach log files

Authenticate without an API key (OIDC)

2 minute read

Authentication between the CloudBees Smart Tests CLI and CloudBees Smart Tests API normally requires a static API key. As an alternative, CloudBees Smart Tests supports tokenless authentication using OpenID Connect (OIDC). Instead of a shared secret, the CI system issues a short-lived, signed OIDC id-token for each pipeline run, and CloudBees Smart Tests verifies it cryptographically. There is no key to rotate or leak.

Two provider paths exist, depending on where the pipeline runs.

CI provider Path Enrollment

GitHub Actions

GitHub Actions is recognized automatically by its well-known, global issuer. The workflow presents its GitHub-issued token and CloudBees Smart Tests matches the repository claim.

Handled by CloudBees Support, which associates the repository with the workspace.

Jenkins or any other OIDC provider

Every non-GitHub issuer is handled by the generic flow. The CI mints an id-token for the pipeline, and CloudBees Smart Tests verifies it against that issuer and matches the sub claim.

Self-service in the CloudBees Smart Tests web app, under Trusted OIDC subjects.

To choose a path:

How OIDC verification works

Both paths rely on the same underlying mechanism.

An OIDC id-token is a signed JWT that the CI mints for a pipeline run. It carries three claims that matter here:

  • iss (issuer) - who minted the token, for example https://token.actions.githubusercontent.com (GitHub) or https://jenkins.example.com/oidc (Jenkins).

  • sub (subject) - the identity of the specific pipeline or job. GitHub Actions matches on the repository claim instead; the generic flow matches on sub.

  • aud (audience) - who the token is intended for. CloudBees Smart Tests expects https://app.cloudbees.io/smart-tests.

To verify a token, CloudBees Smart Tests needs the issuer’s public keys, published as a JSON Web Key Set (JWKS). A JWKS contains only public keys: it allows CloudBees Smart Tests to verify a signature but cannot be used to mint tokens.

The issuer signs each token with a private key, and CloudBees Smart Tests checks the signature with the matching public key from the issuer’s JWKS. This proves the token genuinely came from that issuer and was not tampered with, without any shared secret.

The /.well-known/openid-configuration and /.well-known/jwks paths are an OIDC Discovery convention: a standard location where any compliant issuer advertises its configuration and public keys.
Introduction
Autheticate GitHub Actions with OIDC