I am developing an ASP.NET Core web api project whose only client will be a mobile app developed in Xamarin. There will be no web frontend for the application.
Can CSRF attacks be executed if the user can only login and consume the api from the mobile app?
EDIT
The api performs authentication by username and password by calling an endpoint configured with allow anonymous access. If the authentication process is successful, it returns a JWT that is used to authorize future calls.
A CSRF attack can only be done with requests with those three http request content types: application/x-www-form-urlencoded, multipart/form-data and text/plain. If your end point checks the request content type and makes sure it is not one of those three, that end point is protected from CSRF. So if you make the request content type be something like application/json, and you check that in the code (not just parse http request body using a json parser but actually verify the http request content type header), then you're safe. For existing deployed APIs with clients you do not control, maybe you won't be able to do this.
Another good protection, if you need to allow cookie authentication, use SameSite: Strict cookies if you don't need to allow cross origin requests.
If the end point you wish to protect doesn't do anything without authentication and only accepts authentication using a token, not a cookie and not http basic auth, then a browser doing an AJAX request from code on a malicious site won't be able to perform an authenticated request, and that is also a complete defense against CSRF. This seems to be your case.
A CSRF attack works by making the browser submit a request to another website. Because the browser automatically adds cookies to outgoing requests, the website will see that you have a valid session (assuming you're logged in at the time) and process the request, even if it came from evil.example.com. To protect from this, you verify the referrer, or add and verify some token that is not a cookie (commonly called an anti-CSRF token).
By understanding the attack and being an app developer (knowing how apps work), you might already see that CSRF attacks do not apply to apps in the same way.
If you have broadcast events that trigger an action in your app, then of course you should check with the user if they really want to do that, because any other app can trigger it (unless you require a custom permission to trigger the broadcast receiver). It's different from websites because it's intentional: you need to explicitly put in your manifest that "yes, I want others to be able to call this function". On websites, even the "delete user" feature in the admin panel is always exposed, you can't mark that as not being callable externally (anyone can browse to that URL), so to protect a website you need SameSite/anti-CSRF/referrer-checking.
In Android, you can open socket connections and do whatever. It's a proper programming language, not a browser. There is no concept of "same origin", "forbidden content types" or "forbidden headers" because you are the HTTP client, you're not asking the browser to send an HTTP request. And so it doesn't help to set things like SameSite or do referrer checking. But also, your code won't automatically add a security token to outgoing requests triggered by other apps. The only way would be if you explicitly add a broadcast event listener that lets other trigger actions in your app, but even then, the attacker can't specify the HTTP request, they can only trigger your listener to run.
An attacker can't simply (by default) make your app perform a malicious request. Anti-CSRF tokens or referer checking is not needed. You just need regular user authentication. Because the user is logged in on your app and not on the website, the attacker can't target the app's API from an unrelated webpage. An attacker can't make use of the session token (e.g. JWT) that your app obtained for the logged-in user, because the attacker can't specify a request for your app to add a session token to (unless you program it that way manually).
