[JENKINS-32442] Disable Jenkins API tokens by default

[jenkins-infra-bot]

Submitting as delegate for a Cisco pen-testing team
This is an enhancement to improve the security posture of the default Jenkins install.

Headline: Disable Jenkins API tokens by default
Platforms:Jenkins
Versions: 1.622
CWE Tags: CWE-671, CWE-424

Jenkins allows users to authenticate via multiple mechanisms, including an
automatically generated API token. Despite the name, the API token provides
users with a fully authenticated session (the same as if the user had logged in
using a password).

In many common usage scenarios, a user may never require an API token. For
example, a user who exclusively accesses Jenkins via the web-based UI will never
use an API token. Although probably less common, a user who exclusively
utilizes the SSH-based Jenkins CLI will also never use an API token.

In scenarios such as these, the existence of an active API token serves no
purpose to the user and represents a weakness in that it broadens the overall
attack surface. For this reason, API tokens should not be generated for users
unless they explicitly request a token. Furthermore, individual users should
have the ability to remove/disable existing API tokens. Lastly, Jenkins
administrators should be able to remove a user's API token (e.g. if the token
has been compromised) and disable the usage of API tokens system-wide.

References:
http://cwe.mitre.org/data/definitions/424.html
http://cwe.mitre.org/data/definitions/671.html

---

Originally reported by crlorent, imported from: Disable Jenkins API tokens by default

• assignee: wfollonier
• status: Resolved
• priority: Minor
• component(s): core
• label(s): security, split-plugins-from-core
• resolution: Fixed
• resolved: 2018-06-26T11:09:39+00:00
• votes: 2
• watchers: 4
• imported: 2025-11-24

Raw content of original issue

Submitting as delegate for a Cisco pen-testing team
This is an enhancement to improve the security posture of the default Jenkins install.

Headline:         Disable Jenkins API tokens by default
Platforms:        Jenkins
Versions:         1.622
CWE Tags:         CWE-671, CWE-424


Jenkins allows users to authenticate via multiple mechanisms, including an
automatically generated API token.  Despite the name, the API token provides
users with a fully authenticated session (the same as if the user had logged in
using a password).

In many common usage scenarios, a user may never require an API token.  For
example, a user who exclusively accesses Jenkins via the web-based UI will never
use an API token.  Although probably less common, a user who exclusively
utilizes the SSH-based Jenkins CLI will also never use an API token.  

In scenarios such as these, the existence of an active API token serves no
purpose to the user and represents a weakness in that it broadens the overall
attack surface.  For this reason, API tokens should not be generated for users
unless they explicitly request a token.  Furthermore, individual users should
have the ability to remove/disable existing API tokens.  Lastly, Jenkins
administrators should be able to remove a user's API token (e.g. if the token
has been compromised) and disable the usage of API tokens system-wide.

References:
http://cwe.mitre.org/data/definitions/424.html
http://cwe.mitre.org/data/definitions/671.html

environment

Platforms:        Jenkins<br/>
Versions:         1.622

[jenkins-infra-bot]

• Remote link associated with this issue:

  • #​3271 core

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  This is a good suggestion. Thank you.
  
  While security related, this is not a vulnerability, so I'll move it to the public JENKINS tracker unless someone objects.
  

This is a good suggestion. Thank you.

While security related, this is not a vulnerability, so I'll move it to the public JENKINS tracker unless someone objects.

[jenkins-infra-bot]

crlorent:

• Original comment link
• Raw content of original comment:

  Moving to public is fine by me.
  

Moving to public is fine by me.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Jenkins administrators should be able to remove a user's API token (e.g. if the token has been compromised)
  
  This at least is already possible—at least, you can force it to be updated to a new random value.
  
  I suspect the whole token system could be moved into a plugin, which paranoid administrators could simply uninstall. TBD if the core API for registering a custom servlet filter is sufficiently powerful for this case.
  

Jenkins administrators should be able to remove a user's API token (e.g. if the token has been compromised)

This at least is already possible—at least, you can force it to be updated to a new random value.

I suspect the whole token system could be moved into a plugin, which paranoid administrators could simply uninstall. TBD if the core API for registering a custom servlet filter is sufficiently powerful for this case.

[jenkins-infra-bot]

oleg_nenashev:

• Original comment link
• Raw content of original comment:

  +1 for moving.
  It's a good proposal for security hardening
  

+1 for moving.
It's a good proposal for security hardening

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  It would be handy to have a method in JenkinsRule.WebClient to logInViaApiToken(String username) which could be used for testing permission checks on API requests. (Plenty of tests already use login(String) for this purpose but it is slow as it needs to open the login HTML page and submit the form, when we could simply addRequestHeader to use token authentication without any actual login request.) However such a test utility would be broken by turning off tokens by default (or moving them to an optional plugin) unless some care was taken to ensure that Java-level calls to User.get(…).getProperty(ApiTokenProperty.class).getApiToken() continued to generate a token on demand.
  

It would be handy to have a method in JenkinsRule.WebClient to logInViaApiToken(String username) which could be used for testing permission checks on API requests. (Plenty of tests already use login(String) for this purpose but it is slow as it needs to open the login HTML page and submit the form, when we could simply addRequestHeader to use token authentication without any actual login request.) However such a test utility would be broken by turning off tokens by default (or moving them to an optional plugin) unless some care was taken to ensure that Java-level calls to User.get(…).getProperty(ApiTokenProperty.class).getApiToken() continued to generate a token on demand.

[jenkins-infra-bot]

wfollonier:

• Original comment link
• Raw content of original comment:

  Correction released in 2.129.
  

Correction released in 2.129.