Using Jira User Server With API Token Authentication

If you are running a Jira user server and have our app configured so that it doesn't allow Basic Authentication with regular passwords, please make sure you don't assign it an application name that is also the name of a user in Jira. Instead, use a name that reflects its purpose and update your connections to it when using it, i.e., in Confluence. Otherwise, the directory synchronization will fail.

Microsoft Power Automate & API Tokens

Unfortunately, Microsoft's Jira connector from Power Automate no longer works with Jira on-premises or self-hosted instances.
Neither regular passwords nor API Tokens will work for authentication from the Power Automate suite against your Jira.
The Microsoft support has confirmed this in July 2020.

Zapier & API Tokens

If you want to connect Zapier and Jira using API Tokens, make sure that you choose Basic Auth
and enter a valid REST endpoint in Jira, such as https://<your-jira-base-url>/rest/api/2/myself:

Zapier allows to manage accounts via the Edit Accounts link as depicted in the screenshot above.


By default, the Jira ones are labeled "Jira (1.0.0)".
As you can't change an existing account (i.e. to edit the username and token), you need to disconnect it and create a new one.


We recommend providing a meaningful label on that screen so that you can assign the correct account to your Jira/ Zapier integration:


I'm using Bob Swift's CLI for Jira but can't use API Tokens with it

The Bob Swift CLI has a password- and a token parameter for passing credentials.
The token parameter doesn't work if you use API Tokens created with our app. Use the password parameter instead.

An example call would look like this:

./acli.sh --server https://your-jira.com --user someuser --password <your-api-token> --action getProjectList
BASH

You can also use the short version of the parameters -s, -u and -p to send server name, user name and password/ token.

Please note that the connection test part of the new installer for the CLI won't work with API tokens, at least not with Jira 8.14.
It would be best to skip it, but you can still use tokens, as in the example above.



API Tokens & Captcha Challenge

When a user provides a wrong token or one already expired, the authentication attempt will count towards the failed login count in Jira/ Confluence.

Depending on the settings for "Maximum Authentication Attempts Allowed" in Jira (https://your-jira.com/secure/admin/ViewApplicationProperties.jspa)

or Confluence (https://your-confluence.com/admin/editsecurityconfig.action)


Solving a captcha challenge might be required next time the user logs in to the UI.

Providing a valid token again for authentication on the REST API will reset the failed login counter automatically so that solving the capture challenge is not required anymore. This only applies to doing that with a valid API token on the REST API. If the user tries to log in with a valid and local password via the UI, he/ she will still see the capture challenge. The behaviour is the same as with our SAML SSO app, where trying to authenticate with a user and without SSO, using a local password would also increase the failed login count and create a captcha challenge when trying to log in without SSO or REST,
but is reset again, once the user successfully authenticates via SSO.

Summary of behaviour after causing a Captcha Challenge due to using an invalid API Token

  1. Should the user login to Jira/ Confluence Web interface via the Resolution SAML SSO app, the failed login counter is reset/ no captcha challenge is displayed anymore.
  2. Should the user login to Jira/ Confluence Web interface without SSO, he/ she will need to solve the captcha and also need to provide a valid password (API Tokens are REST only)
  3. Should the user provide another valid token on the REST API again, the failed login counter is also reset/ no captcha challenge is displayed on the Jira/ Confluence Web interface