Authentik/Atlassian Access destination URL error

Published on

If you don’t already know, I’m an avid Atlassian Confluence/Jira user and Atlassian has issued an ultimatum stating that support for all Server applications will end in February 2024.

So, I’ve been working on moving some of the data from my self-hosted Jira instance to Jira Cloud. Part of this was migrating my authentication solution. On Server and Data Center, SSO is provided either by Atlassian’s own plugin (in Data Center) or a variety of third party plugins (I was using Kantega K-SSO). However, in Cloud, Atlassian has monopolized the SSO market, and paying for Atlassian Access is the only way to get SSO functionality.

In my case, the cost of Access doesn’t matter since I have free licenses for OSS projects 😉

The problem

Atlassian Access’s setup flow is much less slick than K-SSO’s, requiring a lot of manual copy and pasting. It wasn’t terribly hard, however, to get all the appropriate bits set up in my IDP (Authentik) and on Atlassian’s end.

When I tried logging in after validating my configs is when I got a big, fat error:

Error: Hmm… we’re having trouble logging you in. You’ll need to talk to your organization admin – tell them we sent you, and that there appears to be an issue with the destination URL used for your SAML single sign-on configuration.

Destination URL? WTF? I thought my IDP was supposed to handle this on its own!

I used the SAML Inspector Chrome extension to validate the destination URL in my SAML request. It was the same as my SAML ACS URL, which is how it’s supposed to be. There weren’t any errors in my Cloud instance’s logs either. Ah, time to open another support ticket!

The solution

After sending some debugging data and waiting a few days (due to the holidays, not support slowness), I got a shocker: Atlassian’s error message had absolutely nothing to do with the actual problem! In reality, the real problem was the lack of an Audience attribute in my SAML request. The real error message was buried in a single HTTP request to and isn’t displayed in the browser at all.

After correctly configuring the Audience parameter in my IDP (to be equal to the SP Entity ID displayed in the Atlassian Admin console), everything worked smoothly.

Atlassian Support opened a feature request ACCESS-1187 to improve the error message in cases like this, but given their track record on fulfilling feature requests (read: they don’t), I doubt this issue will be solved soon. So, in the meantime, if you ever get a destination URL error, check your destination URL but also the Audience parameter in your IDP!

Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments