How to allow users to authenticate with the Jira API easily

The time when technologies could provide value in isolation is over. Modern stacks rely more and more on quick automations and integrations that are possible because Application Programming Interfaces, or APIs, publish how external services can access the resources they gate. But without proper management, APIs are an open door from where attackers can access and leverage your digital assets. 

Jira and Confluence don’t have the functionality for API management or monitoring. To add insult to injury, your users might be using their Atlassian credentials to authenticate to the API without any protection. 

Let’s look at the three ways you can make basic authentication to the Jira REST API secure for your users.

Or keep reading on the alternatives to basic auth.

Alternative 1: Reverse Proxy

What does it do?

Placing a reverse proxy will forbid users to access the API. Although some customers have opted for this alternative, this is a very extreme measure where you lose all the business value that users can create autonomously through the Jira API.

How does it work?

The HTTP authorization header is replaced by the reverse proxy to an empty value, disabling basic auth for all users as a method to access the API.

Here’s an example of how to disable basic auth with an NGINX reverse proxy:

Pros

Extremely secure. You can also disable the reverse proxy when http requests come from the local IP… but that won’t make internal usage of the Jira API any more secure than it was before.

Cons

It’s all or nothing, and doesn’t really solve the problem of how to give users the tools to access the API securely. The experience of your users will be that there’s a bug somewhere, and unless you communicate in advance you can expect a lot of tickets with the subject “Jira REST API basic authentication not working”.

The analogy 

A reverse proxy is basically like a roadblock. 

Alternative 2: Web Application Firewalls

What does it do? 

A Web Application Firewall (WAF) intercepts web requests to Jira and Confluence and inspects them to prevent malicious behavior. Your users will be able to access the API normally via basic auth and seamlessly going through the WAF shield. 

How does it work?

A Web Application Firewall is a type of reverse-proxy server that inspects the incoming traffic at layer 7 to block attacks. WAFs can be based on whitelists, authorizing access to a previously defined list of clients; or on blacklists, in which case they identify the patterns of known attack types in order to block them; or often times a combination of both.

Pros

WAFs are very sophisticated and versatile technologies that can be trained to allow expected user interactions with your applications while blocking unexpected requests. For example, if posting a form is not expected in a url, the WAF can block it. But additional policies and rules will give you a lot of control.

Cons

Besides the fact that your budget for Jira will probably be in the range of a couple thousand dollars per month, Web Application Firewalls need to understand how an application works. You will have to train and retrain the tool in-house and keep a team of at least two experts. If you already maintain a WAF for your other applications then it might make sense to put the Jira API under the umbrella.

The analogy

A Web Application Firewall is like a bouncer that allows customers in depending on the club’s policies. Whitelist bouncers look at the list of guests, while blacklist bouncers will keep you out if you don’t follow the etiquette.

Alternative 3: API Tokens

What does it do? 

API Tokens, also called personal access tokens or API Keys, replace user credentials (username and password) so that basic auth happens without compromising them. The standard practice is to create one different personal access token for each specific third party or script.

How does it work? 

The application you want to access will have to generate a token issued only for a particular user, and that token will be passed in the third-party service or script instead of the password. In the case of Jira Server or Confluence Server, you will need to use resolution’s API Token Authentication app to generate the tokens.

Pros

API Tokens are the most common way to secure access to REST APIs by regular users without actually putting up insane barriers. The most important advantage is that they can be managed with a lot of granularity: administrators can use permission schemes to define who gets to create the tokens, who can use them, and what they can be used for (scoping). For example, ACME could decide that developers can use tokens that make changes into the database, while business users can only read information from Jira. Additionally, it could also set up an approval process by which tokens have to be requested to administrators, who grant them only for valid reasons.

Cons

API Tokens are sent along in the front communication between connection parties and can be found in the authorization header, body data, custom header, or the query string, for example.

The analogy

Personal access tokens are a bit like the card that opens the door of your hotel room: it’s only for you, it only opens the door to your room, and it’s not forever. Or like the number you’re given when you’re waiting in a line in a public administration office. That number is only for you, it’s not forever, and it authorizes you to interact with a resource in a certain way.

Conclusion

When the problem at hand is that your users need to access the Jira REST API securely, API Tokens will do the job simply and without major drawbacks. The fact that they are widely accepted by third parties and no-code automation platforms like Zapier or Microsoft Flow speaks tons about the practicality of this alternative. The minimum impact on the user is also easy to communicate: their Jira password will be protected, and they will get to use one personal access token for each API connection.

In comparison, neither reverse proxies nor web application firewalls seem like proportionate nor cost-effective responses to the problem.

Try API Token Authentication for Jira, for Confluence or for Bitbucket for free.