When you set up a virtual entity data provider using the built in Odata provider you can only use basic authentication with a hard coded url or header Authentication parameter.

This token is visible to all crm admins, making access to basic administration capabilities within the CRM equivalent to having unauditable access to any connected odata sources.

Microsoft (sensibly) requires a service or user principle when making API calls to the common data service.

This is a feature request that the a virtual entity odata connector have authentication capability, perhaps using a service principle bearer token for authentication instead, so that remote API's can verify that it is the CRM making the api call.

A Microsoft support ticket (TrackingID#120110623000942) came to the conclusion that the only partial mitigation would be an IP address white-list, and i would need to white list most IP addresses within azure in Australia. Requiring that a malicious user (who already has some access to the CRM) host his requests from an azure IP is not a security measure, it only protects against the most cursorily of drive-by attackers.

I would like to be able to grant API call capabilities to the CRM without granting CRM developers those same capabilities.