nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Azure DevOps for Jira - using a service principal

James Noble

We've just implemented Azure DevOps for Jira (the official Atlassian integration), and all is working fine.

However, I found it odd that auth to ADO was done just using a single user account (and personal access token). This means we need to give that account admin across all the ADO projects we want to integrate into Jira.

Obviously, we can create a service account (which is what we've done currently)... but that still feels a bit behind the times when you consider that Azure supports service principals.

Has anyone been able to work out how to get this integration using a service principal? Or is aware whether that is a roadmap item for this integration?

Accepted answers

Benjamin_tmh9yg

HI James,

Although, I haven't use service principal myself. It maybe logically possible from the Azure DevOps side. Don't think you can get past the single user setup for the initial connection because that part of the configuration to get integration working. However, you might be able to provision a service principal and use the account to do the underlying operations. Then again, this might just overcomplicate things and it just might be simpler just to have a service account which you have already created.

As for roadmap, I didn't see anything related to azure Dev Ops on the Atlassian roadmap.

https://www.atlassian.com/roadmap/cloud

All comments

Benjamin_tmh9yg

HI James,

As for roadmap, I didn't see anything related to azure Dev Ops on the Atlassian roadmap.

https://www.atlassian.com/roadmap/cloud

Dr_ Ankita Mehta-OpsHub_ Inc

Hi @James Noble

If you're looking to commits, pull requests, and defects between Jira and ADO, here are a few things to keep in mind:

What exactly are you linking? If you're just looking to link commits and PRs, that's straightforward. But if you need defects created automatically during code reviews, you’ll need something that can handle that automatically, instead of doing it manually each time.
Deeper Sync: Are you looking for a surface-level sync (like commit IDs) or do you need something deeper—like comments, attachments, and full change history? The more context you need, the more complex the sync gets.
Bi-directional Sync: Don’t forget about syncing both ways. You’ll want the linked commits, PRs, and defects to be visible and updated in both Jira and ADO, which requires a solid integration that handles that.
Plugins: A lot of plugins offer basic functionality, but they can have some downsides—like limited customization, possible conflicts with other tools, or issues with syncing more complex data (like comments or attachments). Plus, they often require constant updates and maintenance.

If you’re looking for something more automated and with less maintenance, you may consider an enterprise-grade integration solution and an Atlassian Solutions partner, OpsHub Integration Manager (OIM). It helps sync commits, PRs, defects, and even does deeper sync (comments, attachments, mentions, preserves context, hierarchies etc.). All this without writing a single line of code

Here is a YouTube video to watch the bidirectional integration via OIM in action

Drop us a line if you want to request a free demo or have any other questions!

Javier Pozuelo -Exalate-

Hi @James Noble I'm the community manger at Exalate.

The official Azure DevOps for Jira app currently relies on a single user’s PAT for authentication, which usually leads teams to create a dedicated service account with broad access. As you mentioned, it does feel a bit limited compared to modern approaches like Azure AD service principals, but at the moment the connector doesn’t support that method. And as Benjamin mentioned, I also don't see this on the roadmap, so the PAT is still the recommended approach.

If your concern is around security and long-term maintainability, one way teams address it is by scoping the service account down as tightly as possible and monitoring its usage. Alternatively, if you want more flexibility in how authentication and permissions are handled, you might also look at Marketplace integration solutions like Exalate.
Because it’s decentralized, each side authenticates against its own environment (so Jira users authenticate with Jira, ADO users with ADO), and you avoid having a single shared account bridging the two. That can reduce both the security overhead and the risk of a “single point of failure."

Good luck with the integration!

Move Work Forward

Hi all,

And don't forget about Azure DevOps for Jira from Move Work Forward (Fortified popular app).

Happy to jump on a video call to discuss your need @James Noble

Cheers,

Leo

Diana_Architect_ZigiWave

@James Noble hi there. As already mentioned - the official Azure DevOps for Jira connector only supports Personal Access Token (PAT) authentication. That’s why you’re forced to use a single user (usually a dedicated service account) with project permissions. Service principals / Entra ID app registrations aren’t supported, and there’s no public roadmap item for it.

Best you can do today is:

Use a dedicated service account instead of a personal user.
Restrict the PAT scope to the minimum required (Work Items, Read/Write).
Rotate the PAT regularly.
Monitor usage through ADO audit logs.

If service principal auth is a must-have for your org, I’d suggest raising a feature request with Atlassian.

If you need more flexibility now, ZigiOps is another option (you can find it on the Atlassian marketplace) — it connects Jira and ADO without writing code and gives you more control over permissions, data handling, and security. We do have a free trial, or you can schedule a quick demo call - just to explore what ZigiOps offers.

Regards, Diana

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud