Does bearer token authentication work with Access-Control-Allow-Credentials: false?

My client sends requests authenticated via the following header:

Authorization: Bearer some-token

Will including the following header in responses make things not work?

Access-Control-Allow-Credentials: false

Be aware that false isn't a valid value for the Access-Control-Allow-Credentials header. According to the Fetch standard, the only valid value is true (lowercase). Including one Access-Control-Allow-Credentials header in a response with a value other than true is functionally equivalent to altogether omitting that header from the response.

The question then becomes:

Does Access-Control-Allow-Credentials: true need to be present in responses to CORS requests for things to work?

Access-Control-Allow-Credentials: true is only required in responses to credentialed cross-origin requests, e.g. requests initiated from a different Web origin with

• withCredentials = true with the XmlHttpRequest API, or
• credentials: 'include' with the Fetch API, or
• the crossorigin HTML attribute with value "use-credentials".

The term credentials, in this context, refers to browser-managed credentials or ambient authority, i.e. things that the browser automatically attaches to requests (when applicable): cookies, client-side TLS certs, regular Basic auth, etc.

If your client includes an Authorization header (regardless of the authentication scheme used: Basic, Bearer, etc.) to an otherwise non-credentialed request, the presence of Access-Control-Allow-Credentials: true in the corresponding response is irrelevant. This instance of Jake Archibald's CORS playground may be sufficient to convince you. However, a necessary condition for things to work is that the response to the preflight request include an Access-Control-Allow-Headers header that lists, possibly among other request-header names, Authorization (case-insensitive), e.g.

Access-Control-Allow-Headers: Authorization

Addendum

According to the Fetch standard, the Authorization request-header name is special insofar as it is not covered by the wildcard. For example, if you must allow request-header name Authorization, the following won't work in a compliant browser:

Access-Control-Allow-Headers: *

Most browsers still do contravene the Fetch standard in this respect, but Chrome and Firefox have plans to remedy the situation.