ACAO: * will prevent the browser from automatically sending any form of credentials, but that's only relevant for the kinds that the browser can actually send automatically (cookies and HTTP BASIC, DIGEST, and NTLM auth). HTTP auth does use the Authorization header, but not with a Bearer token. Because ACAH: Authorization is specified for both the pre-flight and the actual request, the caller is completely free to explicitly attach an Authorization header (with any value at all, including a Bearer token). The difference is that the caller needs to actually know the value to put in that header; it won't be automatically added by the browser.
Given that the attacker would already need to know the bearer token and that the browser isn't automatically including any secrets with the request, there is no security vulnerability here at all. Allowing the browser to make such authorized requests from arbitrary origins is fine; it's exactly equivalent to the browser making a same-origin callback to its own server, and having the server send the request (which would ignore CORS because most HTTP client libraries don't even have a concept of the same-origin policy) and relay the response back to the browser. In other words, this is no greater security risk than any other web service protected with a Bearer token.
Of course, this is all assuming that the web service is supposed to be reachable from arbitrary addresses. If it's not - if for example it's only supposed to be reachable by one company - then it would make a little sense to restrict the allowed origins more tightly. Only a little, though, because anybody with an HTTP client library (and the bearer token, without which the attacker cannot do anything if the auth is otherwise solid) can make requests all day, unless there's also something like an IP whitelist.
The primary and critical part of the security of the service, as you've described it, is the bearer token. To a first approximation, nothing else matters.
With that said, there are of course many other potential vulnerabilities to check for. Obviously, you should verify that the Bearer tokens are at least as secret as the information they authorize access to; it's no good to require authorization to access a web service and then push the required authorization data to a Git repo, for example. Similarly, make sure the valid Bearer tokens cannot be guessed, brute-forced, or found via timing attack. There are lots of ways to screw up auth, and even more to screw up web services in general (is it available over HTTP, or via weak HTTPS cipher suites? Does it have deserialization or XML DTD vulns? Standard web security stuff).
