Azure AD, now called Microsoft Entra ID, lets your applications hand sign-in to one central identity provider through OpenID Connect or SAML 2.0, so users authenticate once with work credentials and admins control access from a single place. For ASP.NET Core and Xperience by Kentico projects, the working pattern is an Entra app registration with a redirect URI, a certificate or client secret, and optional ID token claims (email, given_name, family_name, preferred_username), connected with Microsoft.Identity.Web using the authorization code flow. This guide explains that setup step by step, how roles and user synchronization behave after the first sign-in, and the trade-offs to plan for, including the single-provider limit, secret handling, and license-dependent Conditional Access.
This guide covers: why app-by-app sign-in becomes a liability, the core ideas behind a clean Azure AD (Microsoft Entra ID) SSO integration, a side-by-side look at local accounts versus Entra ID sign-in, a non-obvious detail about roles and user synchronization, comparison tables for SSO methods and sync settings, what works well, honest trade-offs, a few surprising specifics, and a closing FAQ.
1. Let the identity provider authenticate, and let the app consume the result. In Entra-based SSO, the user opens the app, the app redirects to Microsoft Entra ID, Entra ID verifies the credentials, and the app grants access. The app never handles the password.
2. Default to OpenID Connect for modern .NET apps. OpenID Connect (OIDC) is built on OAuth 2.0 and uses JSON-based tokens. Microsoft says it is usually simpler to build with modern frameworks, while SAML offers broader enterprise compatibility.
3. Register one Entra application per physical application. Kentico's guidance is to create a separate registration for each project. That isolates access if a secret leaks, supports least privilege, and makes auditing and revocation easier.
4. Use a certificate, not a client secret, in production. Microsoft recommends certificates for production applications. A client secret is quicker to set up, but it is shared and can be leaked.
5. Request only the claims the app needs. Add optional claims to the ID token, such as email, given_name, family_name, and preferred_username, so the app can build a user record from the token.
6. Map access with Entra app roles. Define app roles in Entra ID and create matching roles in the application. In Xperience by Kentico, the role code name must match the Value of the Entra app role.
7. Choose a user synchronization policy on purpose. Decide whether profile data and roles refresh only at the first sign-in or on every sign-in. The default does not sync roles at all.
8. Enforce MFA and access rules at the provider. Configure two-factor authentication in Entra ID instead of in each app. Conditional Access policies require at least a Microsoft Entra ID P1 license, according to Microsoft's licensing documentation.
Step 1: Create a local account in every application. Each app stores its own user records and credentials, so one person has several logins.
Step 2: Hand out credentials and handle resets. Password resets and lockouts go to the help desk, one application at a time.
Step 3: Turn on MFA app by app. Only applications with built-in MFA support get it, so coverage is uneven across the estate.
Step 4: Assign roles manually in each app. Someone configures permissions separately in every system and has to keep them aligned by hand.
Step 5: Offboard by hand. When a person leaves, an admin disables each account individually, and any account that gets missed stays active.
Step 1: Register the application in Entra ID. In the Microsoft Entra admin center, open Applications, then App registrations, and register the app. Use one registration per physical application.
Step 2: Add an HTTPS redirect URI. The callback route must be a free route in the app, for example /admin-oidc for the Xperience by Kentico admin interface. Kentico advises using HTTPS for every redirect and callback URI.
Step 3: Add credentials and optional claims. Upload a certificate or add a client secret, then add email, family_name, given_name, and preferred_username as optional claims on the ID token.
Step 4: Connect the app with Microsoft.Identity.Web. In Xperience by Kentico, call AddAdminExternalAuthenticationProvider with AddMicrosoftIdentityWebApp, and set the tenant ID, client ID, callback path, and response type. With certificate credentials, also call EnableTokenAcquisitionToCallDownstreamApi and AddInMemoryTokenCaches.
Step 5: Map roles, test, and choose the sign-in mode. Create app roles in Entra ID, create matching Xperience roles, set the synchronization frequency, and test with a non-admin account. Teams that prefer not to own this work often use a partner's Xperience by Kentico development services for the setup and testing.
In Xperience by Kentico, the first Entra ID sign-in creates a user object from the token claims. By default, the system runs that mapping only once. New users also arrive with no roles, so they can authenticate but cannot open any application in the admin UI.
Role synchronization only happens when you set the UserSynchronizationFrequency option to FirstLogin or Always. Even then, only roles that already exist in Xperience are synchronized, and each role's code name must match the Value of the Entra app role. Xperience never creates roles from Entra data. If you add role synchronization after users already have accounts, set the frequency to Always so their roles are granted at the next sign-in, as described in Kentico's external authentication documentation.

| Method | How It Works | Best Fit | Watch Out For |
|---|---|---|---|
| SAML 2.0 | XML-based federation standard. Entra ID sends identity information to the app in assertions. | Traditional enterprise web apps and cases that need detailed user attributes. | Usually more work to build with modern frameworks than OIDC. |
| OpenID Connect (OIDC) | Identity layer on OAuth 2.0 that uses JSON-based tokens. | Modern web apps, mobile apps, and APIs that need authentication and authorization. | Some enterprise systems only support SAML. |
| Password-based SSO | Entra ID stores the credentials and replays them to the app. | Apps without federation support, especially on-premises apps published through Application Proxy. | Application Proxy requires Entra ID P1 or P2 licensing. |
| Linked SSO | Adds an app link in the user portal without true single sign-on. | Phased migrations where full SSO comes later. | Users still sign in to the app separately. |
| Disabled SSO | Users sign in to each app on its own. | Testing, or apps that need no integrated sign-in. | No central sign-in benefits. |
| Setting | Account Data | Role Assignments |
|---|---|---|
| Never (default) | Used once to create the account at first sign-in, never updated. | Not synchronized. |
| FirstLogin | Used once to create the account at first sign-in, never updated. | Synchronized once, during account creation. |
| Always | Account created at first sign-in, then synchronized at every sign-in. | Synchronized at every sign-in. |
One place to control access. Users sign in once with work credentials, and admins manage access and policy centrally. Applications stop storing their own passwords.
Documented Entra ID support in Xperience by Kentico. The admin interface supports external identity providers through OpenID Connect. Entra ID, Auth0, and Okta have documented setups, and any OAuth/OIDC-compliant provider can be used.
Role synchronization through Entra app roles. User and group assignments in Entra ID can drive Xperience admin permissions, including the Administrator role, without manual assignment in each project.
Clear secret-handling paths. Kentico documents the .NET Secrets Manager for local development, Azure Key Vault for production, and environment-specific settings files for SaaS deployments.
Only one external provider at a time. The Xperience by Kentico admin interface supports a single enabled external authentication provider. Combining multiple providers is not supported.
External sign-in can limit user management. With the default PrioritizeExternal mode, you cannot invite new users directly from the Users application. MaintainForms keeps both sign-in options, but you have to opt in.
Claim mapping is narrow. Xperience maps a fixed set of properties: username, first name, last name, email, and roles. Mapping claims to other properties of the user object is not supported.
Some controls depend on licensing. Conditional Access needs at least Entra ID P1, and risk-based policies need Entra ID Protection, which is part of P2. Confirm your tenant's licenses before promising specific policies to a client.
Certificate sign-in fails without two extra calls. With certificate credentials, leaving out EnableTokenAcquisitionToCallDownstreamApi and AddInMemoryTokenCaches makes sign-in fail with error AADSTS7000218. Client secret credentials do not need those calls.
Forms sign-in disappears once a provider is registered. In the default mode, the admin sign-in page shows the external provider as the only option. Plan a fallback, such as MaintainForms during rollout, before you lock everyone into SSO.
The Administrator role cannot be removed. Xperience requires at least one user with the Administrator role at all times. To retire the default administrator account, create an Entra app role with the value administrator and assign users to it first.
The username claim is mandatory. Xperience reads the username from the preferred_username claim by default. If the claim is missing from the token, the system cannot create the account and logs an exception.
SSO with Azure AD, now Microsoft Entra ID, moves authentication out of every application and into one identity provider that already holds your users, MFA rules, and access policies. For ASP.NET Core and Xperience by Kentico projects, the integration is mostly configuration: one app registration per project, an HTTPS redirect URI, a certificate for production, the right ID token claims, and Microsoft.Identity.Web wiring. The parts that catch teams are not the sign-in itself. They are roles that never sync, a default that hides forms authentication, secrets stored in the wrong place, and license limits on Conditional Access. Teams that plan role mapping, synchronization frequency, and a fallback sign-in path before go-live end up with a setup that is easier to secure, easier to audit, and easier to hand over than a collection of local accounts. Identity is usually just one piece of a larger Azure footprint, and teams running this alongside broader Azure migration, Azure DevOps, or Azure architecture work typically fold it into the same Microsoft Azure cloud services engagement rather than treating it as a one-off task.
Yes. Microsoft renamed Azure Active Directory (Azure AD) to Microsoft Entra ID in July 2023. It is the same cloud identity and access management service, so an Azure AD SSO integration and a Microsoft Entra ID SSO integration are the same thing. Older tutorials and code samples still use the Azure AD name, but you register applications today in the Microsoft Entra admin center.
Use OpenID Connect for most modern web apps, mobile apps, and APIs. It is built on OAuth 2.0, uses JSON-based tokens, and Microsoft says it is usually simpler to build with modern frameworks. Choose SAML 2.0 for traditional enterprise web apps or vendors that require it, because it offers broader enterprise compatibility and suits cases that need detailed user attributes. The Xperience by Kentico admin integration uses OpenID Connect.
Yes. Xperience by Kentico supports Microsoft Entra ID for admin interface sign-in through OpenID Connect and the authorization code flow. You register the app in Entra ID, add a redirect URI such as /admin-oidc, add credentials, and configure Microsoft.Identity.Web in Program.cs. Only one external provider can be enabled at a time. DotStark's Kentico team can set up and test this integration, including role mapping, for your project.
New users created at first sign-in have no roles, so they lack permission to use admin applications. Assign roles manually or synchronize them from Entra app roles. For synchronization, create app roles in Entra ID, create Xperience roles whose code names match the app role values, and set UserSynchronizationFrequency to FirstLogin or Always. Roles that do not already exist in Xperience are not created automatically.
Use a certificate in production. Microsoft recommends certificates for production applications, and Kentico's guidance says a client secret is simpler to set up but less secure because it is shared and can be leaked. If you use a secret, keep it out of source control: use the .NET Secrets Manager locally and Azure Key Vault in production, or environment-specific settings for Xperience by Kentico SaaS deployments.
If your team is planning Azure AD (Microsoft Entra ID) sign-in for the Xperience by Kentico admin interface, the right starting point is a short review of your app registration, role mapping, and secret storage before anything reaches production. DotStark's Kentico development team can handle the configuration and testing, and our Kentico support and maintenance services can keep certificates, roles, and access rules current after launch.
If the SSO rollout is part of a wider move to the cloud, our Microsoft Azure cloud services team covers the broader Azure migration, DevOps, and security work around it, including Azure architecture and Azure consulting for the rest of your infrastructure.