/rest/api/2/user/search REST calls return 200 with no body using wrong API token causing confusions

Issue Summary

/rest/api/2/user/search REST calls return 200 with no body using the wrong API token causing confusion. Currently, it returns []

The developer guide for /rest/api/2/user/search does provide as :

This operation can be accessed anonymously

even with the ‘anonymous access’ situation, we are still getting blocked from retrieving data due to an authentication failure:

If it is an authentication failure, this MUST return a 401 or 403 code.

Use case which keeps affecting our customers: using automation rules  Send web request using Jira REST API even with the API token is correct, but the <EMAIL>:<API_TOKEN>" with base64 is not, they still get the misleading 200 status code in the audit log and after a lot of investigation and ruling out other possibilities, we end up figuring out the token must be wrong.

We are opening this as a new bug as the original cloud issue (JRACLOUD-41559) is closed for some reason.

Problems:

• 200 means success and should never have an empty body. Empty body success responses are supposed to use code 204 – http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
• An empty body is an invalid JSON response, this not being allowed.
• If it is an authentication failure, this MUST return a 401 or 403 code.

As stated above this bug uncovers several serious HTTP standard deviations, probably caused by several broken pieces of code.

Steps to Reproduce

Run the rest api request against a cloud site with either a wrong token, or with absolutely no access to a Atlassian Cloud site. https://xxxx.atlassian.net/rest/api/2/user/search

It returns an empty body only showing [] with 200 success code. 

Here are the response headers with valid authentication (Response = 200)

Date: Tue, 21 Nov 2023 21:24:29 GMT

Content-Type: application/json;charset=UTF-8

Server: AtlassianEdge

Timing-Allow-Origin: *

X-Arequestid: abcdefg

Set-Cookie: atlassian.xsrf.token=ba6648e0ceea51573252835a4ea3b3a589eab842_lin; Path=/; SameSite=None; Secure

X-Aaccountid: xxxxxx

Cache-Control: no-cache, no-store, no-transform

Vary: Accept-Encoding

X-Content-Type-Options: nosniff

X-Xss-Protection: 1; mode=block

Atl-Traceid: dxxxxxx26

Report-To: {"endpoints": [{"url": "https://xxxxxxs.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}

Nel: {"failure_fraction": 0.001, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Transfer-Encoding: chunked

Here are the response headers with INVALID authentication (Response = 200)

Date: Tue, 21 Nov 2023 21:26:31 GMT

Content-Type: application/json;charset=UTF-8

Server: AtlassianEdge

Timing-Allow-Origin: *

X-Arequestid: xxxxxx

Set-Cookie: atlassian.xsrf.token=d3xxxxxx2c7d_lout; Path=/; SameSite=None; Secure

Cache-Control: no-cache, no-store, no-transform

Vary: Accept-Encoding

X-Content-Type-Options: nosniff

X-Xss-Protection: 1; mode=block

Atl-Traceid: bcxxxxx

Report-To: {"endpoints": [{"url": "https://dz8xxxxxv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}

Nel: {"failure_fraction": 0.001, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Transfer-Encoding: chunked

The only differences are the timestamp, requestID, traceID, and the addition of another header on the CORRECT auth request, reflecting the account that is being used to authenticate.

X-Arequestid: abcdefg

Otherwise these responses are identical.

Expected Results

Even with the ‘anonymous access’ situation, we are still getting blocked from retrieving data due to an authentication failure.  If it is an authentication failure, this MUST return a 401 or 403 code.

Actual Results

Getting a 200 success code. 

Workaround

Currently there is no known workaround for this behavior. 

Customer would need to try calling an endpoint that is not for anonymous access for example:  /rest/api/3/mypermissions endpoint where they will be able to determine whether the authentication credentials are not working/correct or if if the user does not have browse users permission.