Check out the latest Sales updates!Learn about the key capabilities and features of Dynamics 365 Sales and experience some of the new features.
Download overview guide | Watch Sales video
2020 release wave 1 Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
I understand the difference between a non-interactive user and an application user but I don't understand when using the S2S authentication.
I know that many ISV Apps have S2S auth to Dynamics, but I don't know the pros and cons of this S2S architecture compared to the more famous small business Non-Interactive user Web Services connection.
In detail, I ask myself the questions:
(It would be nice if an MVP architect or developer wrote his experience on these two ways, I don't find any post about these authentication modality)
I thank you in advance hoping to have kindly tips and opinions.
from license prospective, currently application user doesn't need to be assigned a license
with Non-Interactive user I need at first one more license in order to create the new service user in CRM while with application user I never don't need licenses; but I think it isn't the only advantage of using S2S authentication with the application user....
Someone Can help me, please?
The application user gives your one important addition as you said S2S ability.
To give you a bit of background:
1) Sometimes, you need access Dynamics 365 from a program. In this case the non interactive user is great option. It has a username and password (think of it as service account) and you can use these username and password to authenticate your calls to Dynamics 365.
2) Now, the case where interactive users is not a good option is when you want for example, your SharePoint server to work with your Dynamics instance seamlessly. This is where S2S comes into play. If you worked with Azure AD applications before, you can create an application that "behaves" as a user but it is not a real user. So you create an application in your Azure AD that takes on the responsibility of authenticating with SharePoint (that also may use the same Azure AD). Now the way you tell Azure AD what type of applications it is representing is by creating an "application user" in Dynamics and giving it the Client ID (which is the Azure AD Application ID). This way Azure AD knows that Dynamics (represented by the application user) wants to S2S with SharePoint.
thank you for your reply, but could you explain to me in detail what do you mean about: "If you worked with Azure AD applications before, you can create an application that "behaves" as a user but it is not a real user.", please? Precisely, How does the non-interactive user behave with respect to the new application user?
Both users must have a security role,
both users can work on behalf of another user,
both users must have login credentials (not interactive user username/password, application user the token key).
I don't understand how they behave differently in CRM, The official documentation is not clear for me.
You just said both users can work on behalf of another user. This is not accurate per my understanding. Interactive-user works on behalf of another user yes, but application user works on behalf of an "application". In a sense and in many cases, these users will do the same job and the difference is in how you authenticate with Dynamics.
Consider this scenario: You develop a custom web application and you need to call Dynamics Web API. You have two options:
1) You use an interactive user, this means you need to send this user Username/Pswd over the network to Dynamics to authenticate and use the API. This is not the best way to do things anymore as you may need to take extra precautions in saving this sensitive data in a key vault or some other mechanism.
2) Option 2: You register an application in Azure AD for example, you give this application the permission to talk to the Dynamics instance and in turn use that Azure AD Application in your custom web application. You custom web application will try to authenticate with Azure AD by providing the Application Key and Secret, Azure AD will respond OK because that application is configured to allow access to Dynamics.
This short article also lists some other differences between the two that may or may not be of interest to you
In summary, the main difference you are getting from these two users is how they authenticate when used from an external system.
thank you for your time.
D365 Non-Interactive user account
D365 Application user account
Service User with programmatic access. No Interface interaction.
Service User that perform the application access. No Interface interaction.
max 5 Non-interactive account users per Organization
unlimited Application users per Organization
Does not require a license. Free per user
Does not require a license. Free per user.
Dynamics licensing-based registering user (at least one Dynamics license available to assign to the user at beginning).
AD Azure App register (no dynamics license available needed).
Standard Security Role(s) needed.
Custom Security Role(s) needed.
Only One Non-Interactive user per connector; it can reach the API requests limits and stop to run.
Segment your application(s) and handle load (further testing required) without reaching API user limitation.
User-based authentication: username/password with not expired policy and other security precautions.
S2S authentication: it requires client Id and a client secret. Securely and seamlessly communication with CDS.
Used for programmatic access to and from Dynamics 365 between applications (Application Consoles, SSIS packages or ERP connectors etc.)
Encourage two-factor authentication (2FA) or certificate-based authentication for server-to-server application scenarios. S2S Auth is the common way that apps registered on Microsoft AppSource use to access the Dynamics 365 data of their subscribers.
Requires user names and passwords management.
No administration requirements, easy way to manage ISV services and ISV licensing.
Run on behalf of another user
Run on behalf of an "application”
Impersonation another user available
I think the discussion is exhaustive, If there were other relvant differences, you are welcome to add them!
Thanks David, your last post is a good reference.
Business Applications communities