Hi Community
Hoping you can help guide me with something I am stumped on.
We have a user that created a Java (JAR) application that runs a login/authentication in a generated HTML page asking the user for email and an API TOKEN. Once authenticated, it presents the user with some custom worklog reporting by projects, versions, sprints, etc
The issue is that one user got the below error when he brought it to my attention:
After some troubleshooting, I asked the user to uninstall and reinstall Java. He now gets this:
{"errorMessages":["You are not authenticated. Authentication required to perform this operation."],"errors":{}}
He gets the above with his own (scoped and unscoped) token as well as with my token (which works for me when I run the application for the reports)
The application also works for the 2 other users (incl the user that created the Java application)
What also stumps me is that the user reporting the error and the 2 other users all have the same permissions on the various projects that the reports pull from.
I am not 100% familiar with Java so hopefully this community could help guide me on how further I can troubleshoot.
Thanks in advance
Yatish
Hi Yatish,
Good instinct to question the token — there are two recent Atlassian token
changes that matter here, though one clue still narrows it down.
The clue that rules most of it out: your own token — the one that works for
you
— also 401s for this user. A valid classic (unscoped) token works from any
machine against the site URL, so it failing only for this one person points at
their machine/network, not the credentials.
But the "scoped vs unscoped" detail you mentioned is important, because scoped
(granular) tokens behave differently:
• A scoped API token does NOT work against the site URL
(https://your-site.atlassian.net/rest/...) — it returns 401 there by design.
Scoped tokens must go through the gateway:
https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/...
So if this user generated a scoped token and the app calls the site URL
(almost all do), it will 401 every time. The classic/unscoped token is the
one to use with that app — or the app has to be rewritten for the gateway
URL.
• Timing: Atlassian forced API-token expiry between 14 Mar and 12 May 2026.
We're just past that window, so an older classic token can have silently
expired → 401. (Yours still works, so yours is fine — but make sure this
user
created a fresh classic token, not a scoped or an expired one.)
To bisect it cleanly, have the user run this from their own machine with a
known-good classic token:
curl -D- -u "email:CLASSIC_TOKEN" -H "Accept: application/json" \
"https://YOUR-SITE.atlassian.net/rest/api/3/myself"
• 401 with a known-good classic token → it's their environment: a corporate
proxy, VPN or security/AV product intercepting HTTPS and stripping the
Authorization header (the classic cause of "works for everyone but one
person").
• 200 with their account → creds and network are fine, and the issue is in how
the Java app sends the request on their JDK.
Best,
Artem
Votazz
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.