It does protect against CSRF.
Logging in proves the user knows his credentials. You can embed those CSRF tokens in the result of logging in.
The only way that could be fooled would be a service that asks for the password of the user, and behind the scenes logs in and uses the API in the name of the user. That's no longer a CSRF attack but rather a man-in-the-middle attack.
But you don't necessarily need a separate CSRF token -- usually that's required only when using cookies for authentication.
CSRF attacks work by the user being logged in in a web browser and the cookies being the proof that the user has been logged in. Then a dangerous web site could embed:
<script src="http://your.api/get/request?id=1" />
...which forges a GET request that includes authentication cookies. It's even possible to create a form to forge a POST request without the user's knowledge (the user isn't going to look at the source code of the site, the user thinks the POST is to the attacker's site not to the attacked site). If those requests have side-effects, the side-effects will be executed, like deleting something of value.
<img> tag or
<form> doesn't cause inclusion of those bearer tokens automatically in the request.