General information
A primary use case for API tokens is to allow scripts to access REST APIs for Confluence applications using Basic Auth or Bearer Token with extended filtering/blocking capabilities.
If you define a token for a user, only that user can use it (if you use Basic Auth or Bearer Token), but if you do not specify a user, any user will be able to use this token (only if you use Basic Auth)
If an external system is compromised, you can revoke the token instead of changing the password and consequently changing it in all scripts and integrations.
For security reasons, we recommend generating token for specific user.
Editing the token after creation is not possible, create a new token if necessary.
You should treat API tokens as securely as any other password.
You can mix Tokens with Run REST API on behalf of another user
Supported endpoints
JIRA_URL/rest/*
Token Authentication
You can change the supported authorization methods for all generated tokens between Basic Auth and Bearer Token, or be compatible with both. The default type is Basic Auth.
Basic Auth
Basic authentication is a simple and widely supported authentication method that uses the HTTP header to send the username and password of the client. The client encodes the credentials in base64 and sends them with every request. The server decodes the credentials and checks if they are valid. Basic authentication is easy to implement and compatible with most clients, but it has some drawbacks. The credentials are not encrypted, so they can be intercepted by malicious actors. The client has to store the credentials securely and send them repeatedly, which can affect the performance and security of the API. Basic authentication is suitable for simple and low-risk scenarios, such as testing or prototyping.
Bearer Token authentication
Bearer authentication is a more advanced and secure authentication method that uses tokens instead of credentials. A token is a string of characters that represents the identity and permissions of the client. The client obtains a token from an authentication server by providing valid credentials or other information. The client then sends the token with every request using the HTTP header or the query string. The server validates the token and grants access to the API. Bearer authentication has several advantages over basic authentication. The token is encrypted, so it cannot be tampered with or stolen. The client does not have to store or send the credentials, which reduces the risk of exposure and improves the performance of the API. The token can also have an expiration date, which limits the duration of the access. Bearer authentication is suitable for complex and high-risk scenarios, such as production or public APIs.
How to choose?
When choosing between basic and bearer authentication for an API, there is no one-size-fits-all answer. It depends on the API's requirements, design, and security level. When making a decision, consider factors such as compatibility, complexity, and security. For example, if the API needs to support a wide range of clients, basic authentication may be more convenient. However, if the API needs to integrate with third-party services or platforms, bearer authentication may be more compatible. Additionally, if the API is simple and has few endpoints and resources, basic authentication may be sufficient. On the other hand, if the API is complex and has many endpoints and resources, bearer authentication may be more scalable. Moreover, if the API is low-risk and does not handle sensitive or personal data, basic authentication may be acceptable with HTTPS encryption. Lastly, if the API is high-risk and handles sensitive or personal data, bearer authentication may be mandatory for better security and control over access and data protection.
Source - How do you choose between basic and bearer authentication for your API?
Code snippet
You can generate the code snippet (JavaScript/curl) and authentication data for calls by clicking the icon
If you want to check who used the token and when, all calls are added to the audit log
How does it work
Depending on the details of the HTTP library you use, simply replace your password with the token. For example, when using curl, you could do something like this:
curl -v https://my-jira.com --user USER:TOKEN
Note that:
USER
here is the email address or username.TOKEN
here is token generated in Extender REST API Tokens page
CURL Example
Basic Auth curl -s -u ansible@ansible.jira.pl:token0987654321 JIRA_URL/rest/api/2/issue/AAA-1 curl -s -u ansible@confluence.pl:token0987654321 CONFLUENCE_URL/rest/extender/1.0/user/getUserDetails/admin curl -H 'Authorization: Basic YWRtaW46cGhuN2dkNHY2cWcyNGZ2aGZwNnFwZ2psa3VwMDFnMGxn' CONFLUENCE_URL/localhost:1990/confluence/rest/api/content curl -u admin:token0987654321 -H "Content-Type: application/json" --data '{"body":"Comment text"}' -X JIRA_URL/rest/api/2/issue/ISSUE-1/comment |
Bearer Token curl -H 'Authorization: Bearer qt3sumg4gd8r47n98tcnmuarnfufviog' 'http://localhost:2990/jira/rest/api/2/issuetype' |
Postman Example
Basic Auth
Note that :
Basic Auth
use this type in Authorization typeUsername
here is the email address or username.Password
here is token generated in Extender REST API Tokens page
Bearer Token
Note that :
Bearer Token
use this type in Authorization typeToken
here is the unique token
Specify limits for tokens
You can restrict the token to specific methods (GET, POST, PUT, DELETE, etc.), URL's, URL parameters, and JSON data in the body.
Token restrictions for URLs, URL parameters, and JSON data in the body handling definition with regular expressions.
You can define as many token constraints as you want, each of which should be on a new line.
You can freely combine all available restriction options, URL's, URL parameters, and JSON data in the body.
[method].*/rest/api/.*[QueryParam::paramName==Regexp][JsonData::nodeName==Regexp]
URL without any other restrictions
Example:
Restriction to JRA project issues
.*/rest/api/2/issue/JRA.*
URL with a POST method restriction
Example:
Restriction to 'comment' endpoint on KANBAN-100 issue (only POST method)
[post].*/rest/api/2/issue/KANBAN-100/comment.*
URL with parameters
Add a definition to the end of the “Limit to” definition, as shown in the example
[QueryParam::URL_PARAM_NAME==REGEXP]
where URL_PARAM NAME is the name of the URL parameter
where REGEXP is the definition of a regular expression, what can value the URL parameter take
Example:
Restriction to all filters for all users (only with permission)
.*/rest/extender/1.0/filter/user/.*[QueryParam::permissions==true]
Restriction to worklogs for all users (only in the date range 2018-01-01 - 2018-12-01)
.*rest/extender/1.0/worklog/user/.*[QueryParam::dateFrom==2018-01-01][QueryParam::dateTo==2018-12-01]
URL with JSON data in the body
Add a additional definition to the end of the “Limit to” definition, as shown in the example
[JsonData::JSON_NODE_NAME==REGEXP]
where JSON_NODE_NAME NAME is the name of the JSON node name
where REGEXP is the definition of a regular expression, what value can the JSON node name take
Example:
Restriction to create new filter (limited to uneditable only)
.*/rest/api/2/filter[JsonData::editable==false]
Restriction to create new filter (limited to uneditable only without adding to favorites)
.*/rest/api/2/filter[JsonData::editable==false][JsonData::favourite==false]
Secure mode
We created this mode to add another layer of security to your tokens and allow you to better protect them.
In this mode, you will notice several differences from the standard mode:
you will only see the token once, you will not be able to see it again
you will not be able to view the code snippet, change the expiration date, edit restrictions or any other Token data
Standard mode | Secure mode |
---|---|
|
How to turn on Secure mode
⚠ Keep in mind that this setting is universal across Jira and will require shutting down the instance. As always, we recommend testing changes in a lower environment before attempting them in production.
Shutdown Jira. Even on Jira Data Center, it is necessary to shutdown all nodes. A rolling restart of the nodes won't suffice.
Edit the jira-config.properties file in your JIRA application home directory.
See Making changes to the jira-config.properties file for more information.
Change the value of the ops.bar.group.size.opsbar-classic-transitions-view property within this file to be the number of transition buttons required before the Workflow menu.
If this property does not appear in the jira-config.properties file, add it
extender.token.secure.mode = true
Save the updated jira-config.properties file.
Restart JIRA.
Troubleshooting
Problem | Resolution |
---|---|
curl request (POST, PUT) return error code 3XX and response { "statusCode": 500, "message": "", "reason": "Internal Server Error" } | Server reports that the requested page has moved to a different location. When curl follows a redirect and if the request is a POST, it sends the following request with a GET if the HTTP response was 301, 302, or 303. If the response code was any other 3xx code, curl resends the following request using the same unmodified method. Please check -L, --location documentation and add extra options to your request like --post301, --post302 or --post303. |
Changes
REST API Tokens is available since v. 1.39.*
Since v. 1.40.*.1
added JIRA_URL/rest/keplerrominfo/* to supported endpoints
Since v. 1.61.*
changes in supported endpoint URLs - JIRA_URL/rest/*
added tokens expiration functionality
added the ability to specify token restrictions for URLs/methods
Since v. 2.6.*
all token calls will now be added to audit log
Since v. 2.8.*
added Code snippet
Since v. 2.14.*
added the ability to edit token name and limits
Since v. 4.29.*
Specify limits for tokens - added the ability to define restrictions on URL parameters and JSON data in the body
Since v. 4.30.*
Added Secure mode - additional security layer for Tokens