[JENKINS-57484] Improve API Token "API" capability, esp. for scripting

[jenkins-infra-bot]

The idea is to provide ways for a script to create more easily API Tokens, revoke them. Also, to provide a default API Token for the admin user.

We need to have such capability for Jenkins X in order to reduce the dependence on the crumb issuer and thus, reduce the code complexity around the authentication they are required to use.

---

Originally reported by wfollonier, imported from: Improve API Token "API" capability, esp. for scripting

• assignee: wfollonier
• status: Resolved
• priority: Major
• component(s): core
• resolution: Fixed
• resolved: 2020-10-22T16:25:46+00:00
• votes: 0
• watchers: 3
• imported: 2025-11-24

Raw content of original issue

The idea is to provide ways for a script to create more easily API Tokens, revoke them. Also, to provide a default API Token for the admin user.

We need to have such capability for Jenkins X in order to reduce the dependence on the crumb issuer and thus, reduce the code complexity around the authentication they are required to use.

[jenkins-infra-bot]

• Remote links associated with this issue:

  • #​13868 in helm/chargs for stable/jenkins
  • #​4027 in core

[jenkins-infra-bot]

blastik:

• Original comment link
• Raw content of original comment:

  as requested in [JENKINS-57484] Improving the scripting capacity for the API Tokens #4027 (comment)
  
   
  I'm deploying a new Jenkins from scratch on a single host using Docker all on top of AWS. Its authentication mode is set to SAML (using Okta) and we configure it using JCasC (Configuration as code). The deployment strategy we decided is to deploy a new instance each time a configuration change is made. However, in order to give a good experience to our end users, we want to make 2 steps before swapping between old and new release:
  
  	
  Put the old instance in Quiet mode.
  	
  Query running builds
  	
  When running query builds = 0 then swap the instance. We have no problem on doing that with the API but... the problem is that we depend on one single thing: the API token!
  
  
  
  Ideally we would like to add a fix token into JCasC file to be able to connect to the API once Jenkins the host has been configured.
  jenkins saml
  

as requested in #4027 (comment)

 
I'm deploying a new Jenkins from scratch on a single host using Docker all on top of AWS. Its authentication mode is set to SAML (using Okta) and we configure it using JCasC (Configuration as code). The deployment strategy we decided is to deploy a new instance each time a configuration change is made. However, in order to give a good experience to our end users, we want to make 2 steps before swapping between old and new release:

1. Put the old instance in Quiet mode.
2. Query running builds
3. When running query builds = 0 then swap the instance. We have no problem on doing that with the API but... the problem is that we depend on one single thing: the API token!

Ideally we would like to add a fix token into JCasC file to be able to connect to the API once Jenkins the host has been configured.
jenkins saml

[jenkins-infra-bot]

timblaktu:

• Original comment link
• Raw content of original comment:

  blastik I'm trying to achieve essentially the same thing essentially, and months ago came to learn of the new Djenkins.install.SetupWizard.adminInitialApiToken }}option. I'm on 2.289.1 and {{Djenkins.install.SetupWizard.adminInitialApiToken=<my-pre-determined-34-char-token> simply has never worked.  The docs for this option indicate that it:
  determines the behavior during the SetupWizard install phase concerning the API Token creation for the initial admin account.
  So, it would seem for automated installs like ours which must disable the setup wizard, this option is innefectual, by design. No? 
  
  On Gitter, timja pointed me to the PR that introduced this feature by wfollonier, whose description seems to indicate this is by design:
  No impact once an instance is configured.
  I can't understand the usefulness of this feature for automated installs, which inherently will be setting `jenkins.install.runSetupWizard = false`. 
  
  Any advice? I tried it with and without running the setupwizard, and I've never been able to use the token to authenticate as my admin user in a new Jenkins instance.
  

blastik I'm trying to achieve essentially the same thing essentially, and months ago came to learn of the new Djenkins.install.SetupWizard.adminInitialApiToken }}option. I'm on 2.289.1 and {{Djenkins.install.SetupWizard.adminInitialApiToken= simply has never worked.  The docs for this option indicate that it:

determines the behavior during the SetupWizard install phase concerning the API Token creation for the initial admin account.

So, it would seem for automated installs like ours which must disable the setup wizard, this option is innefectual, by design. No? 

On Gitter, timja pointed me to the PR that introduced this feature by wfollonier, whose description seems to indicate this is by design:

No impact once an instance is configured.

I can't understand the usefulness of this feature for automated installs, which inherently will be setting `jenkins.install.runSetupWizard = false`. 

Any advice? I tried it with and without running the setupwizard, and I've never been able to use the token to authenticate as my admin user in a new Jenkins instance.