JFrog OIDC is how a pipeline stops storing an Artifactory access token. The job already runs under an identity the CI provider can assert with a short-lived token. JFrog Access checks that token against an identity mapping and returns a short-lived JFrog access token. When every pull and publish job has exchanged successfully, the Artifactory access token leaves the pipeline. Rotating that token on a schedule was the previous control. Rotation keeps a long-lived secret in the runner. Exchange removes it.
Rutagon builds the cutover: provider, mapping, one job, the rest of the jobs, then revocation. The client owns the tenant. Rutagon builds the evidence pipeline and the pipeline change. A green job that still reads the old secret is not the cutover.
What has to be true before the first exchange
The platform feature has a license gate. JFrog documents OIDC integration on Enterprise X and Enterprise+. If the tenant does not include it, the cutover stops. Deleting the stored token anyway strands the pipeline. We confirm the integration is available, then we configure a provider under Administration, Security, OpenID Connect.
An identity mapping matches incoming claims to an authorization scope. JFrog's OpenID Connect integration describes that object. The mapping needs at least one claim. With no claims, anyone who knows the target can request a token. We put the repository, and the ref when the provider asserts it, on the mapping. Permissive configuration that skips organization restrictions is the setting we leave off. The organization on the provider is the organization that actually builds.
Priority matters when several mappings exist. Project-scoped mappings take precedence over global ones when the exchange supplies a project key. Inside a tier, a lower numeric priority wins. We write the priority down next to the mapping name so a later "why did this job get admin scope" question has an answer. Admin scope on a CI mapping is the mistake we reject. The scope should be the user or group the job needs, not a platform admin.
The CI provider has to be one the integration supports. The exchange command accepts GitHub, Azure, or a generic OIDC provider. A server that cannot issue an ID token inside the job cannot use this cutover. The token is minted in the job. JFrog's CLI docs say you cannot create it on a laptop and paste it in later.
JFrog OIDC exchange in the job
The job requests an ID token from the CI provider, which means the job permission to request that token is on. It then runs the exchange. The command is jf exchange-oidc-token, aliased as jf eot. The provider name configured in Artifactory is the first argument. The provider type flag is GitHub, Azure, or GenericOidc. The platform URL is the tenant you already use. The ID token can be the second argument, or the environment variable JFROG_CLI_OIDC_EXCHANGE_TOKEN_ID. JFrog documents the command in Exchange an OIDC token for JFrog access.
permissions:
id-token: write
contents: read
steps:
- name: Exchange a JFrog token
run: jf eot "$OIDC_PROVIDER" --oidc-provider-type=GitHub --url="$PLATFORM_URL"
The job sets JFROG_CLI_OIDC_EXCHANGE_TOKEN_ID from the ID token it just received. The command prints a JFrog access token and a username. That access token is the credential the following steps use to pull or publish. It is not written into the repository secrets. It lives for the job, then it expires. The old Artifactory access token is not read by this step.
We prove the negative. The job log must show the exchange, and the job must succeed with the stored token removed from that one workflow. A job that still has the secret in its environment can "succeed" while ignoring the exchange. We delete the secret from that workflow's inputs before we call the job done. The same pattern, for a container registry rather than Artifactory, is Docker Hub OIDC.
Order of revocation
One pipeline first, the one that both reads and writes if you have one. Then every other pipeline that used the same Artifactory access token. Shared libraries and reusable workflows count. A hidden caller that still injects the secret will fail on revocation day, or worse, will keep the secret alive because someone restores it during the incident.
During the overlap, the old token remains in a sealed admin path and is not mounted into jobs. That is the rollback: put it back on a single job if the exchange is denied. Once every job has a clean run, we revoke the Artifactory access token and delete it from the CI secret store. Rollback after revocation is a new mapping or another short-lived grant, not a copy of the revoked token from someone's laptop. We do not keep a spare in chat.
Evidence for the GRC you already run is small and specific. The provider name, the mapping name, the claims JSON with secrets redacted, the list of workflows that exchanged, and the revocation time of the old token. A screenshot of the OIDC settings page without the workflow list does not show the token left the pipeline. Standing keys elsewhere in the account are the wider pass in hardcoded credentials in CI. Workload identity for cloud APIs is the sibling pattern in workload identity federation.
Failures we treat as open
A 401 on the exchange is a provider-name mismatch or a token that expired before the call. The provider name has to match Artifactory exactly. A 404 is a wrong platform URL. An unsupported provider type means the flag was not one of the three documented values. We do not paper over those by putting the access token back and calling the migration complete.
A mapping that matches too widely is an open finding even when the job is green. Wildcard claims that cover every repository in the organization are a choice, and we record them as an exception with an owner. The default we ship is the repository that runs the workflow.
This cutover is security automation work on the pipeline you already have. We do not stand up a second artifact host to avoid the token. The host stays. The long-lived credential goes. Rutagon's own publish jobs exchange a short-lived token the same way. That practice is not an attestation you can borrow.
Frequently Asked Questions
Can a developer mint the OIDC token on a laptop to test JFrog OIDC?
The ID token has to be issued inside the CI job. The CLI documentation is explicit that these tokens are not created locally. A test is a branch workflow with the exchange step. A pasted token from a workstation is not a test of the mapping.
What scope should the identity mapping grant?
The user or group the job needs in Artifactory, not platform admin. Claims have to restrict which repository can exchange. An empty claim set is rejected in our cutover because the vendor documents that anyone who knows the target could then request a token.
When does the Artifactory access token get deleted?
After each consuming workflow has a successful run that does not read the secret. Revocation is the last step, not the first. The overlap period keeps the old token sealed and unmounted so a single failed exchange can be rolled back without hunting through chat history.
Which CI providers can exchange?
The exchange command documents GitHub, Azure, and a generic OIDC provider type. The job still has to be able to request an ID token. A runner with no identity token cannot complete this cutover, and we will not invent a flag that pretends it can.
What do you file for the audit?
The provider, the mapping and its claims, the workflows that exchanged, and the time the old access token was revoked. That pack goes into the GRC you already run. A settings screenshot without the workflow list does not show the secret left the pipeline.
Talk to us about your credential elimination pilot. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.