Paid Partnership with Resolution

Imagine this. You are trying to integrate a service into Jira, which requires the use of Jira’s API. You could provide your password, but it’s tied to AD, which means you would be trusting access to everything with an otherwise unknown service. Well, what are you to do? The service has to authenticate to Jira, right? So you have to give it something!

Well, there is a way you can do just that! With API Token Authentication for Jira, you can replace your password with a one-time use token. Not only that, for the first time, we are taking an App beyond Jira and discussing the Versions also available for Confluence and Bitbucket. So let’s see when we would need this API and what it can do for us.

Features

Create Tokens per User AND Service

So, this is pretty well the main point of this App. It lets you create a string of characters that you can use in place of your password when making API calls. Doing so makes you more secure. If someone compromises a service and gets your API key, yes, they can get to your API, but they don’t have your password to pivot that access to other systems. 

It also allows users to set up an individual key per service. This arrangement is a boon for them as if they need to change their key for that service, they can do so without updating every service they also use. 

Another feature with these keys is you, as an Admin, can set a maximum lifetime for keys. That way, you don’t have services that users aren’t using hanging out with access to your instance. If it’s still being used, users will update the key. If they aren’t, they expire, thus closing that access.  

Revoke API Tokens at any time

So, I’m not particularly eager to talk about it, but security incidents happen. Even when they don’t, it’s entirely possible to have an API integration misbehave. For example, under unmodified Jira, to cut off API Access to such integrations was to cut off the user’s access altogether, which is no bueno. 

With API Tokens, you can revoke an individual token to remove an API integration’s access without shutting down the entire user account. Now that is a handy feature.  

Token Manager to filter & Create tokens for all users

Let’s say you have thousands of users who have one or two integrations a piece. Now you need to find a specific one to revoke. How do you do that? Well, this has already been thought of! API Token gives you a Token Manager that lets you sort through and create tokens for your users. That way, you’re not stuck going through a hundred pages of tokens to find the one you are interested in. 

Permissions Management

It’s entirely reasonable that you might want to limit which users can create API Tokens. Otherwise, you can have anyone opening up holes into your instance on a whim.  

 

To be specific, you can set groups that can use Tokens, groups that can create tokens for themselves, and groups that can create tokens for other people. You can also limit tokens only to allow Read-only operations as a way to defend your instance against unwanted changes.

For example, let’s say you have an integration that does some advanced reporting. As part of it’s normal operation, it should only ever read data, and not write. But as things stand, if you store your API Credentials with this tool, they have full read/write access.  If that service ever gets compromised, you just gave the attackers the tools to start modifying your instance. 

This is where having read-only access could be preferable.  Read-only access would allow the tool to work while limiting what can go wrong. Definitely an excellent way to define how people use this App in your instance.

Audit Logging

Allowing users to log in via a token is one thing. But how do you go back and make sure it’s being used appropriately? Well, API Token includes audit logging in it. So that means you can do exactly that, go back and see who is using their tokens, where you are getting failed logins from, and figure out who is misbehaving.  

Restrict API Requests

On top of limiting who can create and use API Tokens, you can also limit where requests can come from, down to the IP Range. This is great for ensuring that only the integrations you are aware of are allowed to connect to your instance. Of course, it means you have more work in approving such requests, but it would be well worth it to ensure no surprises will happen. 

Disallow Username/Pass Authentication for API Calls

This feature is one of the main points of the App. Now that you have this alternate method for API Authentication, you can choose to entirely disable logging into the API with your Username and Password. If I haven’t been clear, this App puts all the options and choices in your hands, helping you manage who, how, where, and when people interact with your Instances via API.

What about Bitbucket Data Center’s Personal Access Token?

Yes, this is a thing. So you might be wondering why you should bother with the Bitbucket version of this App when the Personal Access Token already exists, no? 

Well, from a user perspective, they are very much similar. So your users might not care one way or another. However, from the admin’s perspective, API Tokens shines through as the more polished product. Let me explain. For the Personal Access Tokens, the only thing you can do is set an expiry date policy on Tokens. That’s it. Need to revoke a particular Token? Better get that user on the phone.  

Compare that to the permissions, policies, searching, and revoking you can do as the admin with the API Token App, and it’s clear what makes it the better option. For example, you can search for that user, see the logs about how their token was used, and then revoke that specific token without getting the user involved.  

My Analysis

What this App does well

So, I’ve said this plenty so far, but the idea behind this App is to give you control while making your application more secure. And to that extent, it does its job. It prevents your users from reusing their passwords while giving you easy controls to manage your users’ integration using the API. 

The thing that impresses me is how thoroughly they thought about this problem. It seems Resolution went through every single pain point associated with using APIs in Atlassian products and revamped it to work smoother. “I can’t see who is using APIs.” Bam, audit logging. “I can’t control who can and can’t use APIs.” Boom, controls and permissions. And it’s like that every step of the way.  Well done!

What this App could work on

This part was the most challenging part of this review. You see, I’ve been talking with Resolution about this App since before my SAML SSO App Review came out. And in those talks, I mentioned a particular pain point I was having.

You see, I was trying to get a client to adopt the App for their Jira instance. The problem? This client’s devs didn’t naturally understand how to use this App. So I had to spend cycles to explain (and in some cases re-explain) what they needed to do. It all boiled down to the fact they had to dig for the documentation. Given that, I gave an early recommendation that Resolution includes a link to the documentation on the User’s Interface. And well…they went and did it.

However, no App is perfect, and I feel that if I don’t put something down here, I haven’t adequately done a review. But I both love and hate it when a Developer makes this more complicated than it needs to be. 

However, there is one thing that my use of it over the past years I have always wanted, so we can call this a new challenge for Resolution. Right now, when you set an expiration policy on an instance, it applies to everyone. Do you, as the admin, need to make a permanent integration? You must disable the policy, create the integration, then re-enable it. Then you have to hope that no user decided to also create a token at that time. What I would love to see is a tiered approach. Are you able to create tokens for other users? Then your maximum expiry is this long. Can you only use tokens? Then your expiry is this long. Trust the Admins that already have control of the instance to be able to do more than users. 

Would I recommend this App?

Would I, though? I’ll go one better. In July of last year, I bought this App for my personal Jira server instance with my own money. I mean, yeah, it was only $10, but that’s not the point. The point is, that’s how much I believe in what API Token can do: I put it on the instance I use to test and write articles with. I honestly think that’s about the best endorsement I can give it.  

User Map’s Tier Rank

So, where would I rank this App? Well, as I said, I think very highly of it. It’s an App that when I think of what it can do, I have a hard time thinking of how to improve it. Like SAML SSO, it does what it does better than anything else in the marketplace, but it still gives you the control and flexibility to configure it to work how your teams need it to. That’s why I gave it a very strong A. It’s not a game-changer, but it’s definitely on my “Must have” list. 

What do you think?

Is this something your instances could use? What other use cases would it solve for you? I want to hear your opinions!

Don’t forget you can also find me on Facebook, Twitter, LinkedIn, and Instagram! I’d love to hear your thoughts and ideas there! And don’t forget you can also subscribe to the blog directly to get new posts delivered to your inbox. As always, the signup box will be below. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”