As was mentioned in a comment, this is actually an extremely common pattern for web services. Specifically, using
Authorization: Bearer <token goes here> is a secure way for a client to authenticate to a service, which incidentally happens to be secure against CSRF. It's slightly inconvenient for browser-oriented web apps, as it requires requests to be made using JS rather that via HTML forms or similar, but there are frameworks where JS-initiated requests are the default way of communicating with the server anyhow.
Note that if it instead uses
Authorization: Basic ... or
Authorization: Digest ..., those are actually not secure against CSRF. Those authorization headers are based on a password the browser prompts the user for, and the browser subsequently sends them on every request to the server (including forged / cross-origin requests). Look up "HTTP Basic Auth" (or Digest auth) to learn more. They're not commonly used on consumer-facing web apps, but are reasonably common on routers and other networking hardware, IoT devices, and so on.
Assuming the web service is using bearer tokens, and that the tokens are securely generated, used, and stored (like any authentication token, bearer tokens are not inherently secure; if not implemented correctly it might be possible to steal them, predict them, forge them, guess/brute-force them, bypass them, edit low-privilege ones for more access, or so on), CSRF is not possible. XSS could still expose the bearer token (it has to be stored in the client's memory somewhere, usually in a JS variable or local storage if the client is a browser) but XSS strictly dominates CSRF anyhow in terms of possible exploits.
Another advantage of this type of auth scheme is that it can be used with services that have different origins, without requiring setting cookies for multiple sites, via CORS requests. This requires that the cross-origin endpoints be configured to allow the relevant header in requests from the origin of the site.
This limitation of cross-site requests can also be used to implement CSRF protection even when using cookies or similar; if you require the client to both submit a session token in a cookie (or other location) and any custom header, then web browsers will refuse to send the request unless the target site confirms that it's OK with the custom header being sent from the attacker's origin (the process of obtaining this confirmation is a "CORS Pre-flight request" and is sent automatically by the browser when a cross-origin request with a custom header is attempted). In that case, the value of the header doesn't even matter; the simple ability to include it is proof the request isn't a CSRF, and the authentication/session token is sent in some other way (such as a cookie).