Estimated reading time: 18 minutes

Microsoft Power Pages supports five authentication methods — local credentials, OpenID Connect (OIDC), SAML 2.0, OAuth 2.0 social login, and open/invitation-code registration. This guide explains how each one works, when to use it, how to configure it, and what security risks to watch out for before you go live.

Introduction — Why Authentication Matters in Power Pages

Building a portal on Microsoft Power Pages is fast and powerful. But the moment you add user-restricted content — customer dashboards, partner portals, employee self-service pages — you need to make a critical decision: **how will your users prove who they are?**

Get this right and you get a seamless, secure experience that fits your existing identity infrastructure. Get it wrong and you open the door to account takeover, data leaks, regulatory non-compliance, and a painful re-architecture down the road.

Power Pages ships with five distinct authentication approaches, each with its own protocol, trust model, configuration overhead, and risk profile. In this guide we walk through all five — what they are, how they work step by step, when they are the right tool, and what you need to do to configure them securely.

Whether you are a developer wiring up your first portal, an architect designing an enterprise solution, or a security reviewer preparing for a go-live audit, this article has the depth you need.

What Is Power Pages?

Microsoft Power Pages is a low-code platform for building externally facing business websites and portals. It sits within the Microsoft Power Platform ecosystem and is built on top of Microsoft Dataverse as its data layer.

Key characteristics relevant to authentication:

• All authenticated portal users are stored as Dataverse contact records
• Access to pages and data is controlled by web roles assigned to those contact records
• The portal runtime is ASP.NET-based and uses ASP.NET Identity and OWIN middleware under the hood
• Authentication state is maintained via a session cookie named AspNet.Cookies
• Power Pages supports multiple identity providers simultaneously — users can be offered a choice at sign-in

Because everything flows through Dataverse contact records, the security of your authentication layer has a direct impact on the integrity of your CRM data. A compromised user account does not just grant portal access — it may also expose or corrupt Dataverse records tied to that contact.

How Power Pages Handles Identity

Regardless of which authentication method you use, the end result is the same:

[User authenticates] → [Identity verified] → [Contact record matched/created in Dataverse]
       → [Web roles retrieved] → [.AspNet.Cookies session issued] → [Portal access granted]

[User authenticates] → [Identity verified] → [Contact record matched/created in Dataverse]
       → [Web roles retrieved] → [.AspNet.Cookies session issued] → [Portal access granted]

Power Pages uses a claims-based identity model. Once authentication succeeds, the identity provider (local or external) emits a set of claims — name, email, group memberships — that Power Pages maps to fields on the Dataverse contact record. This mapping is configurable through registration claims mapping and login claims mapping site settings.

Important: Every user must have a unique email address in Dataverse. If two contact records share the same email — including deactivated records — neither account can authenticate. This is a known denial-of-service vector that must be managed proactively.

Authentication Methods

Power Pages supports five distinct approaches to user authentication. Each method uses a different protocol, trust model, and configuration approach. Understanding the differences is critical to choosing the right solution for your requirements.

The Five Authentication Approaches

Method 1: Local Authentication (ASP.NET Identity)
Built-in username and password authentication stored directly in Dataverse contact records. No external identity provider required. Microsoft recommends migrating away from this approach for production enterprise portals.

Method 2: OpenID Connect (OIDC)
Modern federated authentication protocol. Integrates with Azure AD B2C, Azure Entra ID (formerly Azure AD), and other OIDC-compliant providers. Recommended for customer-facing portals and B2C scenarios.

Method 3: SAML 2.0
Enterprise-grade federated authentication. Used for integration with corporate identity systems like ADFS, Okta, Ping Identity, and other SAML 2.0-compliant providers. Best option for partner portals and B2B scenarios.

Method 4: OAuth 2.0 Social Login
Allows users to sign in with their existing social media accounts (Microsoft personal, Google, LinkedIn, Facebook, Twitter/X). Suitable for consumer-facing portals and community sites where convenience is prioritized.

Method 5: Open Registration and Invitation Codes
Self-service account creation with optional invitation codes. Not an authentication protocol itself, but a registration workflow that pairs with any of the above methods. Used for controlled onboarding scenarios.

Method 1 — Local Authentication (ASP.NET Identity

Local authentication is the built-in, username-and-password credential store provided by ASP.NET Identity. Credentials are stored directly in Dataverse contact records. There is no external identity provider involved.

Microsoft recommends migrating away from local authentication to Azure AD B2C. Consider this method legacy. Use it only for low-risk, non-production, or transitional scenarios.

How It Works

1. The user submits their email and password on the portal sign-in page.
2. Power Pages retrieves the matching Dataverse contact record.
3. ASP.NET Identity compares the submitted password against the stored PBKDF2 hash.
4. If the account lockout threshold has not been exceeded (default: 5 failed attempts, 24-hour lockout), the login proceeds.
5. If two-factor authentication is enabled for the account, an OTP is emailed to the user’s confirmed address.
6. Upon successful authentication, Power Pages issues the .AspNet.Cookies session cookie.

When to Use It

• Rapid prototyping and internal demos
• Very low-sensitivity portals with no regulated data
• Transitional phase while migrating to a federated identity provider

When Not to Use It

• Any portal handling personal data, financial information, or health records
• Any portal subject to regulatory requirements (GDPR, PSD2, HIPAA, ISO 27001)
• Any scenario where phishing-resistant authentication is required

Key Configuration Settings

Top Security Risks

• Email-only 2FA is not phishing-resistant and is vulnerable to email account compromise
• IsDemoMode = True exposes OTP codes and password reset tokens directly in the UI — catastrophic if enabled in production
• Weak password policy defaults — digit, uppercase, and special character requirements are all False out of the box
• CookieSecure = SameAsRequest allows session cookies over HTTP on misconfigured infrastructure

Method 2 — OpenID Connect (OIDC)

OpenID Connect is a modern identity layer built on top of OAuth 2.0. Power Pages supports OIDC for enterprise providers (Microsoft Entra ID, Entra External ID, Azure AD B2C) as well as any standards-compliant OIDC provider.

When properly configured, OIDC allows Power Pages to delegate all authentication — including MFA and Conditional Access enforcement — to a trusted external identity provider.

How It Works

1. The user selects their OIDC identity provider on the sign-in page.
2. Power Pages fetches the provider’s discovery document to obtain endpoints.
3. Power Pages builds an authorization request and redirects the browser to the IdP’s authorize endpoint.
4. The IdP authenticates the user (enforcing MFA, Conditional Access policies, etc.).
5. The IdP issues an authorization code and redirects the browser back to the Power Pages reply URL.
6. Power Pages exchanges the code for an id_token back-channel (server-to-server, not via the browser).
7. Power Pages validates the id_token — checking signature, issuer, audience, nonce, and expiry.
8. Claims from the token are mapped to a Dataverse contact record.
9. Power Pages issues the .AspNet.Cookies session cookie.

Supported Identity Providers

• Microsoft Entra ID (single tenant and multi-tenant)
• Microsoft Entra External ID
• Azure AD B2C (with custom policies)
• Any OIDC-compliant provider (Okta, Auth0, Ping Identity, etc.)

Critical Configuration Warning

Power Pages defaults to the implicit grant flow (response_type = code id_token). This flow is deprecated under OAuth 2.0 Security Best Current Practice (RFC 9700) because it exposes tokens in the browser URL and history. You must explicitly override this to use the authorization code flow:

response_type = code
response_mode = query

response_type = code
response_mode = query

Additionally, PKCE is not supported in Power Pages OIDC as of 2026 — a known platform gap that should be formally noted in your security documentation.

Key Configuration Settings

Top Security Risks

• Implicit grant as default — tokens exposed in URL fragment and browser history
• No PKCE support — authorization code interception is possible
• Audience/issuer validation not enforced by default — accepts tokens from other apps or tenants
• Wildcard issuer filter — accepts tokens from any Entra ID tenant unless scoped
• Claims mapping can overwrite sensitive contact fields — audit your mapping configuration carefully

Method 3 — SAML 2.0

SAML 2.0 (Security Assertion Markup Language) is a mature XML-based federation protocol widely used in enterprise environments. Power Pages acts as the Service Provider (SP); Entra ID or AD FS acts as the Identity Provider (IdP). SAML assertions are XML documents signed with the IdP’s private key — they never appear as readable tokens in the browser URL.

How It Works

1. The user selects the SAML provider on the sign-in page.
2. Power Pages (SP) builds a signed XML AuthnRequest and redirects the browser to the IdP’s SSO endpoint (the request is base64-encoded in the URL).
3. The IdP validates the AuthnRequest signature and authenticates the user (with MFA and Conditional Access).
4. The IdP issues a signed XML SAMLResponse containing the assertion with user attributes.
5. The IdP sends the SAMLResponse back through the browser via an auto-submitting HTML form (HTTP POST binding).
6. Power Pages receives the SAMLResponse and validates:
   • Assertion signature (using IdP’s public certificate)
   • Issuer (must match configured IdP entityID)
   • Audience (must match SP entityID)
   • NotBefore and NotOnOrAfter time conditions
   • InResponseTo field (replay attack prevention)
7. Attributes from the assertion are mapped to a Dataverse contact record.
8. Power Pages issues the .AspNet.Cookies session cookie.
9. Single Logout (SLO): When the user signs out, Power Pages can send a LogoutRequest to the IdP, ensuring the IdP session is also terminated.

Supported Identity Providers

• Microsoft Entra ID
• Microsoft AD FS (Active Directory Federation Services)
• Any SAML 2.0-compliant IdP

Why SAML 2.0 Is the Recommended Choice for Enterprise

SAML 2.0 offers several advantages over OIDC for regulated enterprise portals:

• No tokens in the browser URL — the SAMLResponse is POST-bound, not URL-bound
• Signed assertions — every attribute claim is cryptographically bound to the IdP
• Mature SLO support — federated sign-out is well-defined in the SAML spec
• Wide enterprise IdP support — Entra ID and AD FS both have first-class SAML support
• No implicit grant problem — the SAML protocol does not have an equivalent of OAuth’s implicit flow

Key Configuration Settings

Top Security Risks

• Contact mapping by email (default On) — if the IdP can issue arbitrary email attributes, an attacker could hijack existing contact records
• SLO not enforced by default — users may remain authenticated at the IdP after signing out of the portal

Method 4 — OAuth 2.0 Social Login

Power Pages supports OAuth 2.0 social login with five consumer identity providers: Microsoft personal accounts, LinkedIn, Facebook, Google, and Twitter/X. Users authenticate with their existing social account — no separate portal password is needed.

Not recommended for enterprise, regulated, or sensitive portals. Social providers offer no enterprise MFA enforcement, no group/role claims for automatic web role assignment, and no compliance guarantees suitable for regulated industries.

How It Works

1. The user selects a social provider (e.g. Google) on the sign-in page.
2. Power Pages builds an OAuth 2.0 authorize URL and redirects the browser to the social provider.
3. The user authenticates with their social account credentials.
4. The social provider issues an authorization code and redirects back to the portal callback URL.
5. Power Pages exchanges the code for an access token back-channel.
6. Power Pages reads the minimal profile claims from the token (email, display name only — no groups or roles).
7. Power Pages matches or creates a Dataverse contact record based on the email claim.
8. Web roles must be assigned manually — there is no automatic provisioning from social token attributes.
9. Power Pages issues the .AspNet.Cookies session cookie.

Supported Social Providers

When to Use Social Login

• Low-sensitivity public community portals
• Consumer-facing portals where social identity is the primary user identifier
• Portals where users are unlikely to have a corporate identity

When Not to Use Social Login

• Any portal with regulated data (financial, health, legal)
• Enterprise or partner portals requiring MFA enforcement
• Any scenario where automatic web role provisioning from group membership is required

Top Security Risks

• No enterprise MFA enforcement — social account security is entirely controlled by the end user
• Account takeover risk — a compromised social account grants immediate portal access with no secondary check
• No group/role claims — web roles must be assigned manually; there is no attribute-based access control

Method 5 — Open Registration and Invitation Codes

Open registration is not a separate authentication protocol — it is a user provisioning mode that controls whether users can create their own Dataverse contact records. It works in combination with any of the authentication methods above.

Power Pages offers two registration modes:

Open Sign-Up (OpenRegistrationEnabled = True, default) Any anonymous internet user can register for an account. A Dataverse contact record is created immediately on registration. This is the least restrictive option and is unsuitable for most enterprise use cases.

Invitation Code Registration (InvitationEnabled = True) Administrators pre-provision contact records in Dataverse and distribute invitation codes by email. Users can only register by redeeming a valid code. This is the recommended registration path for any portal where user access must be controlled.

How Open Sign-Up Works

1. The anonymous user visits /register and submits an email address and password.
2. Power Pages validates input (password policy, CAPTCHA if enabled).
3. A new Dataverse contact record is created with the email marked as unconfirmed.
4. A confirmation email is sent with a verification link.
5. The user clicks the link, confirms their email, and the account is activated.
6. The user is signed in with a session cookie and any default web roles.

How Invitation Code Registration Works

1. An administrator creates an invitation record in Dataverse linked to a pre-provisioned contact.
2. The “Send Invitation” workflow emails the code and redemption link to the user.
3. The user opens the link and submits the invitation code.
4. Power Pages validates the code and activates the linked contact record.
5. The user completes registration (sets a password or links an external identity).
6. The user is signed in with the web roles pre-assigned to the contact.

Key Configuration Settings

Top Security Risks

• OpenRegistrationEnabled = True by default — any internet user creates a Dataverse contact record and potentially gains portal access if web roles are misconfigured
• Duplicate email denial-of-service — pre-registering an email address can block a legitimate user from ever authenticating
• Invitation code leakage — codes distributed by email can be forwarded or leaked; no documented platform-level expiry enforcement

Side-by-Side Comparison of All Methods

Security Best Practices for Power Pages Authentication

Regardless of which authentication method you choose, the following hardening steps apply to every Power Pages deployment:

1. Always enforce HTTPS for session cookies

Set Authentication/ApplicationCookie/CookieSecure = Always. The default value SameAsRequest allows session cookies to transmit over HTTP on misconfigured or split-traffic infrastructure.

2. Disable local authentication unless explicitly required

Set Authentication/Registration/LocalLoginEnabled = False. Microsoft itself recommends against local auth. If you must keep it, enforce strong passwords, enable 2FA, and require email confirmation for password resets.

3. Override the implicit grant default in OIDC

Explicitly set response_type = code and response_mode = query. Never leave the default code id_token hybrid/implicit configuration in production.

4. Always validate audience and issuer in OIDC

Enable ValidateAudience and ValidateIssuers with explicit, non-wildcard values. Replace https://sts.windows.net/*/ with your specific tenant ID.

5. Disable open registration for any non-public portal

Set OpenRegistrationEnabled = False. Use invitation codes or pre-provisioned contact records for controlled user onboarding.

6. Audit claims mapping configuration

Review every registration and login claims mapping. Ensure no sensitive Dataverse contact fields (account numbers, role attributes, financial data fields) are writable from external token claims.

7. Never enable demo mode in production

IsDemoMode = True exposes one-time codes and password reset tokens directly in the browser. Verify this setting is False in every environment, including staging.

8. Configure and test Single Logout

Enable federated sign-out for OIDC and SAML 2.0. Test that signing out of the portal also terminates the IdP session — especially important for shared workstations in financial or healthcare environments.

9. Avoid social providers for enterprise or regulated portals

Social login (Google, Facebook, LinkedIn, Twitter/X) provides no enterprise MFA enforcement, no group claims, and no compliance guarantees. Reserve social login for low-sensitivity consumer-facing portals only.

10. Manage duplicate contact records proactively

A unique email is required per authenticated user. Implement a CRM data quality process to detect and merge duplicate contact records before they block user authentication.

Which Authentication Method Should You Choose?

Here is a quick decision guide based on portal type and requirements:

For enterprise or partner portals (B2B): → Use SAML 2.0 with Microsoft Entra ID or AD FS. Enable Conditional Access and MFA at the IdP. This is the lowest-risk, highest-compliance option available in Power Pages.

For external customer portals (B2C): → Use OIDC with Azure AD B2C or Microsoft Entra External ID. Override the implicit grant default to use authorization code flow. Configure B2C policies to enforce MFA and password complexity.

For regulated industries (banking, healthcare, finance): → Use SAML 2.0 as the primary protocol. Formally document PKCE absence as a residual risk for any OIDC deployment. Disable local auth, social login, and open registration entirely.

For public community or consumer portals: → Social login (OAuth 2.0) is acceptable if the portal holds no sensitive data. Combine with open registration (invitation-code mode recommended). Implement CAPTCHA.

For internal development or demos: → Local authentication is acceptable for non-production environments. Ensure IsDemoMode is never set to True in any environment that connects to real data.

References and Further Reading

Official Microsoft Documentation

• Overview of authentication in Power Pages — Microsoft Learn
• Set up an OpenID Connect provider — Microsoft Learn
• Configure a SAML 2.0 provider with Microsoft Entra ID — Microsoft Learn
• Configure a SAML 2.0 provider with AD FS — Microsoft Learn
• Configure the Azure AD B2C provider — Microsoft Learn
• Local authentication, registration, and other settings — Microsoft Learn
• Configure an OAuth 2.0 provider — Microsoft Learn
• Migrate identity providers to Azure AD B2C — Microsoft Learn
• Power Pages security overview — Microsoft Learn
• Page permissions in Power Pages — Microsoft Learn
• Create web roles in Power Pages — Microsoft Learn

Standards and Security References

• OpenID Connect Core 1.0 Specification — OpenID Foundation
• OAuth 2.0 Security Best Current Practice (RFC 9700) — IETF
• SAML 2.0 Technical Overview — OASIS
• PKCE for OAuth Public Clients (RFC 7636) — IETF
• Microsoft Entra ID documentation — Microsoft Learn
• Azure AD B2C documentation — Microsoft Learn

Related Articles

• Power Pages security overview and best practices
• Configuring site settings in Power Pages
• Power Pages web roles and table permissions
• Microsoft Entra Conditional Access documentation