In enterprise environments where automated processes and integrations need to interact securely with Microsoft Dataverse or Dynamics 365, it is crucial to use Server-to-Server (S2S) authentication. This method allows applications to securely communicate with Dataverse without user context, leveraging application identities instead.
Instead of using user credentials, which can be insecure and difficult to manage at scale, S2S authentication relies on App Registrations in Azure Active Directory (now Microsoft Entra ID) and special Application Users in Dataverse.
This article provides a complete guide to understanding, setting up, and securing Application Users for S2S authentication in Power Platform and Dynamics 365 environments.
What is Server-to-Server (S2S) Authentication?
Server-to-Server authentication is a way for applications, services, or background jobs to connect to Dataverse securely without user interaction. It is commonly used for:
- Integrating external systems (e.g., Azure Functions, custom APIs)
- Scheduled jobs or background services
- Power Automate custom connectors
- Azure Logic Apps or DevOps pipelines
S2S authentication is achieved using an Application User, which is mapped to an Azure AD app registration.
Key Concepts and Components
1. Application Registration in Azure AD
An app registration creates a unique identity (client ID and secret/certificate) that your app uses to authenticate with Azure services, including Dataverse.
2. Application User in Dataverse
This special user type represents the Azure-registered app within Dataverse. It cannot log in interactively and is designed only for automated access.
3. Security Role
Even though it’s not a person, the application user still needs security roles to define what it can access or do in Dataverse.
Benefits of Using S2S Authentication
- No dependency on user credentials or licenses
- Improved security through app-only access
- Supports secret or certificate-based authentication
- Reduces the risk of credential exposure
- Scalable and automatable
Step-by-Step: Setting Up an Application User
Let’s walk through the full process of enabling S2S access using an Application User.
✅ Step 1: Register an Application in Azure AD
- Sign in to the Azure portal: https://portal.azure.com
- Navigate to Microsoft Entra ID (Azure AD) > App registrations
- Click New registration
- Name: Something descriptive (e.g.,
Contoso-D365-Integration) - Supported account types: Choose “Accounts in this organizational directory only”
- Redirect URI: Not required for S2S, so you can leave it blank
- Name: Something descriptive (e.g.,
- Click Register
After registration, make a note of:
- Application (client) ID
- Directory (tenant) ID
✅ Step 2: Create a Client Secret or Certificate
- In the Certificates & secrets section, choose:
- New client secret: Add a description and expiration (recommend 6–12 months)
- OR upload a certificate (preferred for production environments)
Copy and securely store the client secret value — it is shown only once.
✅ Step 3: Add API Permissions
- Go to the API permissions section of your app
- Click Add a permission > Dynamics 365
- Select Application permissions
- Choose:
user_impersonation(full access to Dataverse as an app) - Click Add permissions
- Click Grant admin consent for the tenant
This allows the app to use S2S authentication to access Dataverse data.
✅ Step 4: Create an Application User in Dataverse
- Go to Power Platform Admin Center: https://admin.powerplatform.microsoft.com
- Choose the appropriate environment
- Click Settings > Users + permissions > Application users
- Click + New app user
- In the Add an app screen:
- Select the Azure AD app you registered
- Assign a Business Unit
- Choose appropriate Security Roles
- You can use existing roles or create custom ones for least privilege access
- Save
Once created, the application user is available in your environment and can authenticate with the assigned roles.
Testing the S2S Authentication
You can test S2S authentication using tools like Postman or your integration code.
OAuth Token Request (example via client credentials flow):
POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
client_id={client-id}
client_secret={client-secret}
grant_type=client_credentials
scope=https://your-org.crm.dynamics.com/.default
Replace {tenant-id}, {client-id}, and {client-secret} with your actual values. Use your Dynamics 365 environment URL in the scope.
Use the Access Token:
Include the token in your request header when calling the Dataverse Web API.
Authorization: Bearer {access-token}
Best Practices for Application Users
| Best Practice | Why It Matters |
|---|---|
| Use least privilege roles | Prevent overexposure of data |
| Rotate secrets/certificates regularly | Maintain security hygiene |
| Use Azure Key Vault to store secrets | Centralized and secure secret management |
| Monitor application user access via audit logs | Detect abnormal or unauthorized usage |
| Prefer certificates over secrets | Higher security and longer validity |
| Separate app users by function (e.g., integration, reporting) | Easier to control and audit access |
Security Considerations
- Avoid using personal credentials for app integrations.
- Restrict app permissions in Azure AD to the specific APIs needed.
- Monitor all Application User activity via Dataverse Audit Logs and Azure AD Sign-in logs.
- Revoke or disable old app registrations that are no longer in use.
For enhanced security, combine with Conditional Access Policies and App Governance in Microsoft Entra.
Application Lifecycle and Automation
Managing Application Users in ALM or DevOps processes is key for consistency across environments.
Recommendations:
- Use Power Platform CLI or PowerShell to automate application user creation.
- Store secrets in Azure DevOps variable groups or Key Vaults for secure deployment pipelines.
- Apply environment variables to point your integrations to the correct environment URLs during deployment.
Real-World Scenario: Integration with Azure Function
Use Case: A scheduled Azure Function pulls invoice data from an ERP system and inserts it into Dataverse daily.
How It Uses S2S:
- Uses App Registration to authenticate
- Calls Dataverse Web API using client credentials flow
- App user has custom security role limited to the Invoices table
- Secret stored securely in Azure Key Vault
This setup ensures a secure, scalable, and credential-free way of integrating systems.
Common Mistakes to Avoid
| Mistake | Solution |
|---|---|
| Using personal user accounts for background jobs | Use App Users instead |
| Forgetting to grant API permissions in Azure | Add Dynamics 365 > Application > user_impersonation |
| Assigning excessive roles to the app | Create minimal custom roles |
| Not rotating secrets | Set calendar reminders or use automation |
| Hardcoding secrets in code | Use Key Vault or environment variables |