Issue Summary

Incorrect Response codes when using expired or invalid bearer tokens for REST API
This is reproducible on Data Center: yes

Steps to Reproduce

1. Use an invalid or expired token in the following REST API call

   curl --header "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJpZCI6ImRjOGVmZjM3Njk4MmZhYWRkZmVmYjEzNTQ0MjQzZGMxIn0.-P7rIZCDFIP1cxtbIauYFw7Uzt8M6afB0_d-jlQUxFM" "http://127.0.0.1:8090/rest/api/content?spaceKey=MOLA&title=test
   

   The response we get is a 404

   {"statusCode":404,"data":{"authorized":false,"valid":true,"allowedInReadOnlyMode":true,"errors":[],"successful":false},"message":"No space with key : MOLA","reason":"Not Found"}%
   

   Example 2:

   curl --header "Authorization: Bearer Njk1MTY0MDc5NTExOiUf5UZgrTb+1oUqO/26dtl83m" "http://127.0.0.1:8090/rest/api/content/10879049/history" 
   

   {"statusCode":404,"data":{"authorized":false,"valid":true,"allowedInReadOnlyMode":true,"errors":[],"successful":false},"message":"No content with id : ContentId{id=10879049}","reason":"Not Found"}%  
   

2. On testing with the base content API endpoint, we see the 200 OK with empty data

   curl --header "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJpZCI6IjAxMWRlYWEwY2Q0ZmY3MDJkYjhiYjk5MjA3MGIxMTI1In0.avatUgZyGp-axjxXg2Fk4lXd6YGlNmOyFkY4FC67LUA" "http://127.0.0.1:8090/rest/api/content"
   

   {"results":[],"start":0,"limit":25,"size":0,"_links":{"self":"http://127.0.0.1:8090/rest/api/content","base":"http://127.0.0.1:8090","context":""}}%  
   

Expected Results

Since the token is invalid or expired, we expect either a 401 or 403 response code

Actual Results

Confluence is sending a 404 response code. As per RFC 6750(The OAuth 2.0 Authorization Framework: Bearer Token Usage), we should be sending a 401 code. Although the problem seems to be happening since the introduction of PAT

 invalid_token
         The access token provided is expired, revoked, malformed, or
         invalid for other reasons.  The resource SHOULD respond with
         the HTTP 401 (Unauthorized) status code.  The client MAY
         request a new access token and retry the protected resource
         request.

Workaround

Currently, there is no known workaround for this behavior. A workaround will be added here when available