Jira API - "Client must be authenticated to access this resource."

[Shea Prewett]

Hi, I'm a developer working on a Jira API integration for my organization that uses the cloud version of Jira. The eventual goal is to be able to occasionally create issues through the API but for now I'm just trying to get basic authentication working. (I really would prefer to avoid having to implement OAauth 2.0 if possible because the scope of necessary work there seems well beyond the basic need here)

I've been starting off by building some basic API calls in Postman, but I'm having a hard time getting Basic Auth working. Basically every call I've tried making has given me its version of an Auth error. 

I've had this issue with other calls like creating issues and viewing issues, but to narrow the scope let's take this basic "myself" API call, and assume that the usual namespace for our org is jira.cloud.xxxx.com:

https://jira.cloud.xxxx.com/rest/api/3/myself

If I'm already logged into Jira in my browser, I can go to this link and it will work perfectly fine, giving me JSON about my current user. So I know this path works, and now I want to make the same call through postman. 

I know that for Basic Auth, I need to have it send a combination of my email and my API token which I got from https://id.atlassian.com/manage-profile/security/api-tokens. I've tried going to the Authorization tab, picking Basic Auth, entering my email for the Username, and my API key for the password. When I make the GET API call to that same path, but from Postman with my Basic Auth, I get the following error message:

Client must be authenticated to access this resource.

I know I can also BASE64 encode the combination of my email + semicolon + apikey and put it after the word "Basic" as the value for an "Authorization" header, but it seems like doing it through the Postman UI does the exact same thing; I confirmed the value it's building is the same as if I built the header manually, and tried manually doing it a few times instead instead of doing it through the UI for good measure, no difference.

I tried both with regular and scoped API tokens (for the scoped one, I just gave it every granular permission for editing or inserting issues), and tried both the UI and manual encoding ways for sending the Basic Auth header, and had no difference.

I've also tried changing the 3 in the URL to a 2 just in case, no difference there either.

I thought well, I'm not an admin at my Org, maybe I need to be an Admin? So I was given admin permissions, recreated both my regular and scoped API tokens, no dice. I also had our Jira admin try generating an API token and tried with their email + token, no dice. I had another developer doing the same thing on their end, no dice.

I've tried searching for this error online, but the only things I can find are just people not sending the API Tokens properly. I tried following a step-by-step youtube tutorial for this stuff and they just breeze past this part with no issues in their environment. Either I'm missing something obvious, or there's something about my org that isn't playing nice with the API calls, but I really wouldn't know where to start in that case.

Any advice or ideas would be greatly appreciated!

[Shea Prewett · Accepted solution]

I finally figured it out!

I was trying to make the API call using our custom URL branding. (jira.cloud.xxxx.com)

I tried instead making the same calls but without the branding (xxxx.atlassian.net) and my Auth was accepted!

i.e. https://jira.cloud.xxxx.com/rest/api/3/myself > https://xxxx.atlassian.net/rest/api/3/myself

[Evgenii]

Hi, @Shea Prewett 

Try sending hashed email:password in headers. It will help. 

Like this:

In my scripts in Python I use such code snippets for ordinary and admin API:

# Atlassian REST API headers
base64_credentials = base64.b64encode(
    f"{cloud_api_email}:{cloud_api_token}".encode()
).decode()
headers = {
    "Authorization": f"Basic {base64_credentials}",
    "Content-Type": "application/json",
}

admin_headers = {
    "Authorization": f"Bearer {cloud_admin_api_token}",
    "Content-Type": "application/json",
}

[Shea Prewett]

Yep, I've confirmed that the Base64 hashed email:APIkey string is being sent after the word Basic for the Authorization header (you can see this in the second screenshot from my original post, though if something looks incorrect about that please let me know). I've tried doing this both manually, and by having Postman do it for me by going to the Authorization tab, selecting Basic Auth for the Auth Type, and entering my email for my username and the API key for the password. When I do so, I can look at the Authorization header being generated, and see that the result is the same as if I manually create it using the following powershell script recommended by the Jira documentation:

$Text = 'shea.prewett@xxxx.com:APIKeyHere'
$Bytes = [System.Text.Encoding]::UTF8.GetBytes($Text)
$EncodedText = [Convert]::ToBase64String($Bytes)
$EncodedText

I did also try creating it using my Jira password (instead of the API key) in case that's what you were suggesting, but I got the same result.

[Evgenii]

Hi, @Shea Prewett 

It's strange — I tried the request in Postman, and it worked. The result is shown in the screenshot above. However, I added the authorization details in the Headers tab, not the Authorization tab.

When I switched to using the Authorization tab (as typically expected), it didn't work — same as in your first attempt.

Try setting the Authorization header under the Headers tab for this integration.

[Shea Prewett]

Here's a screenshot with the Authorization tab set to "No Auth" (does not generate any headers automatically) and me instead adding the encoded credentials manually through the Headers tab using the method I described previously, by running my email:APIKey through that powershell script and using the encoded value it gives me. No luck, unfortunately.

---

[Sunny Ape]

Hello @Shea Prewett 

If you provide the real URL to your Jira instance, not the fake domain 'jira.cloud.xxxx.com', I will test the connection and advise if the REST API is working as expected.

If you really are using Jira CLOUD not Jira DATA CENTER, then the Postman request you have shown should work.

PS. You've posted your question in the Bitbucket section of the community, not the Jira section.

PPS. If not a single developer at your company or even the Jira admin themselves can successfully make a Basic Auth request to any the REST API endpoints of your company's Jira instance, you may have bigger problems!!

[Shea Prewett]

Thanks for the offer to personally test, but since this is a production environment with live data in it, I'm not currently at liberty to share that, apologies.

We are indeed using cloud. For what it's worth, the only part I have obscured from the endpoint is the xxxx section.

Good catch with the Bitbucket part! I was looking at another ticket for a similar issue when I created this and didn't even notice it was in the wrong section. I'll have to see about getting this moved or recreated in the correct section. Thanks!

[Sunny Ape]

Ok, I understand.

When I see a URL like 'jira.cloud.xxxx.com' I always start with the assumption the person asking the question is NOT on cloud, even if they cite they are accessing a v3 API endpoint, since 99% of the time, Jira Cloud URLs are in the 'xxxx.atlassian.net', domain, but the introduction of custom domain URLs for organisations has made that difficult to be certain.

From the discussion you've been having with @Evgenii it seems that you're doing everything 'by the book' and there's no obvious reason why a simple Basic Auth'd request using Postman and letting it Base64 encode the email:token combo into the request header isn't working. However, some companies simply don't want their users to access the REST API of their Jira Cloud instance, and since there is no native way to achieve that, they use tricks like Firewall / Proxy based path redirection or request header content blocking to negate the requests. You did say your Jira Admin hadn't been able to perform a request, so I assumed if anyone would know about the configuration of the org's Jira Cloud instance, they would be the person who knows if such network shenanigans were in effect.

I'd recommend that you try an unauthenticated request to one of the endpoints that doesn't need authentication by default. A classic one is the Search for issues using JQL enhanced search endpoint. If you perform a simple JQL search for issueType=Story the request will be processed, return a 200 OK response, but no results:

If that works, you at least know the request path is allowed and routing correctly, and the REST API server can at least 'hear' the request and respond, it just couldn't perform the JQL search without authority.

Next, if all is OK, change that request to basic Auth with the email:token combo (Don't even use a variable; type your actual email address and paste in your actual Basic API token!) and try again:

If the request works and returns a set of Work Items that are Stories, then you know the email:token combination is valid and works.

If the request still does not return any Work Items, then you know the email:token combination is invalid and can mean only three things:

1. That token doesn't belong to that user with that email address;
2. The user to whom that token belongs doesn't have Browse projects permissions;
3. The token itself is invalid. (IE, incomplete, expired, not Basic type but scoped / OAuth type etc).

Once you isolate your problem down to where the fault is occurring, you are most of the way to resolving it.

[Shea Prewett]

The issue ended up being something else but I do want to thank you for such a detailed comment! It gave me a lot of things to try and helped narrow down the issue.