1. As in the case of other access to F&O, Entra ID is used for authentication and role-based security in F&O for defining permissions. And as with other access, the risk is that admins fail to configure permissions correctly or credentials leak.
2. You need some application that will call the API. You can write, say, a web application in C#, but it's easier in logic apps. Also, logic apps have plenty of connectors to other systems (e.g. you may want to work with data on SharePoint or OneDrive, compose emails etc.), which you would otherwise implement by yourself.
3. No necessarily. But you typically don't want to expose the API directly. Maybe you don't want synchronous calls at all - there is a risk of throttling (and failed requests), failures when F&O is down for maintentance etc. An alternative is using a message queue, which allows re-sending of failed message, better load distribution and so on. Even if you want synchronous calls, you may want to route calls through a custom endpoint (e.g. using Azure API Management). That allows you to use a different authentication mechanism (you don't have to give third parties access to F&O at all), add logging and so on.
4. As mentioned above, then you don't need to give them access to F&O.
