External Authentication in DynamicWeb 10
DynamicWeb 10 allows users to authenticate using external identity providers such as Microsoft Entra (Azure AD), Google, Okta, or Azure AD B2C, instead of managing usernames and passwords inside DynamicWeb. This ensures higher security, compliance with corporate SSO standards, and a smoother user experience.
When external authentication is enabled, the standard login flow is replaced by a redirect to the configured provider (e.g., Microsoft Entra or Google). The identity provider handles the login screen, validates the credentials, and issues an identity token back to DynamicWeb.
DynamicWeb then processes this token and signs the user into the system using a secure cookie (DynamicWeb.ExternalCookies). From this point, the user is authenticated inside DynamicWeb just as if they had logged in with a local account.
DynamicWeb 10 ships with built-in providers:
Each provider has configurable parameters such as Client ID, Client Secret, Tenant/Domain, and a unique Provider Scheme. The provider scheme is used to define the callback URL (e.g., /signin-msentra or /signin-google), which must also be registered in the provider’s admin console.
Login Flow
When a user logs in with an external authentication provider the following happens:
- Redirect to Provider: When a user chooses external login, they are redirected to the configured provider’s login page
- User Authentication: The provider validates the user credentials. DynamicWeb never handles the password.
- Token Issuance: The provider returns an ID Token (and sometimes additional claims like email and name) to DynamicWeb
- Mapping Claims: DynamicWeb extracts key identity claims from the external service:
- Email address (used to identify or match a user account)
- Name (added as a claim to the user’s session for display)
- Session Establishment: The user is signed in via the external cookie scheme and treated as an authenticated DynamicWeb user.
If authentication fails, users can be redirected to a custom error page defined in the provider configuration. If no error page is set DynamicWeb defaults to the backend login page with an error message. Failures are also logged in the Security log, categorized by the provider scheme.
Handling unknown users
For backend login a local user with a matching email must always exist on the solution for the login to succeed.
For frontend login there are several scenarios:
- If a local user with a matching email exists, the login succeeds and the local users is associated with the session
- If a local user with a matching email does not exist:
- If the Handle only external authentication setting on the provider is set to true the login fails
- If the Handle only external authentication setting on the provider is set to false the login succeeds and a user is created in the user group selected on the provider
Users flagged as invalid or placeholder accounts (like the reserved "angel" user) are not allowed to log in. This means external authentication does not bypass DynamicWeb’s user management—it simply replaces the password step with a secure external login.
Frontend Login
To render a Login with {Provider} button in frontend you can use the ExternalLogins-property on the UserAuthenticationViewModel.
@foreach (var provider in Model.ExternalLogins)
{
<form class="grid grid-1 gap-4 mb-4" method="post">
<button type="submit" name="DwExternalLoginProvider" value="@provider.Id" class="btn btn-outline-primary w-100">
<span class="hstack gap-2 justify-content-center align-items-center">
@if (provider.Icon != null)
{
if (provider.Icon.Contains(".svg"))
{
<span class="icon-3">
@ReadFile(provider.Icon)
</span>
}
else
{
<img src="/Admin/Public/GetImage.ashx?image=@(provider.Icon)&width=18&format=webp">
}
}
<span>Sign in with @provider.Name</span>
</span>
</button>
</form>
}