While I am going to talk about eConnect, I would like to disclaim that the explanations are JUST out of my understanding of the concepts of eConnect and the structure. Please do refer to some more articles from Microsoft, Consultants worldwide and others to know more about this and also correct my own understanding in case you find it irrelevant.
eConnect use Windows Authentication to converse with GP Databases instead of the traditional SQL Authentication (which GP uses). There could be various reasons why it is designed in such a way. I am listing some of the important reasons:
1. eConnect does not require GP Application, or precisely, it does not depend on an Instance of GP Application to be running (which is the case with Integration Manager for most of its Integrations). This would mean that, the login credentials for an eConnect integration cannot be inherited from anywhere. We still have to establish a Connection String (ODBC) to the GP Databases to access the data and manipulate it.
2. eConnect is designed to run in the background and access/manipulate the GP databases without anyone’s idea of what’s going on with the records and database. Apparently, there should be a kind of authentication which is much more stronger than the basic SQL Authentication, which the Windows Authentication provides us.
3. eConnect is the base for almost all the web based features we have for Dynamics GP, such as Webservices, Business Portal, etc. We cannot have a compartively weaker Authentication level when we allow anyone to access GP Databases from anywhere.
4. eConnect can utilize MSMQ (Microsoft Message Queuing), to queue the integrations from anywhere to the Dynamics GP server. In such cases, it has to have a Windows Authentication to pass the MSMQueuing validations.
I am still learning more concepts on these two Authentications and its scope with respect to GP and related products. I will update more points with references, so it does not just go in as a theory.