Power Pages security, in depth

Power Pages portals are exposed on the public internet, and most of them give external users authenticated access to Dataverse data. Getting the security model right matters more here than in any internal Power Platform application. The good news: the security model is well-defined and the pitfalls are documented.

Identity. Authenticated portal users are represented in Dataverse as Contact records. The contact has a primary identity-provider linkage — usually OAuth-2.0 via Entra ID, an external identity provider (Google, Microsoft, Facebook, Apple, LinkedIn), or a SAML/OpenID Connect federation. Local accounts (username/password stored in Dataverse) are supported but discouraged; identity-provider sign-in is more secure and scales better.

Multi-factor authentication. Configurable at the identity-provider level (e.g. Entra ID Conditional Access policies enforce MFA on the IdP, and Power Pages inherits it).

Web roles. Once authenticated, a portal user gets one or more web roles. Web roles are the portal-side equivalent of Dataverse security roles, but scoped to the portal only — they don't grant access to the underlying Dynamics 365 application. Each web role is associated with table permissions, page permissions, and content permissions.

Table permissions. The most important and most misconfigured Power Pages concept. Table permissions define what portal users (in specific web roles) can do with specific Dataverse tables. The privileges are familiar — Read, Create, Write, Delete, Append, Append-To — but the scope is what makes it nuanced:

• Global — across all rows in the table. Use sparingly; usually too permissive.
• Contact — rows owned by the signed-in contact. The default for self-service: a customer sees their own profile.
• Account — rows owned by the signed-in contact's parent account. A B2B portal: a buyer sees their company's data.
• Parental — through a configured 1:N relationship from a parent the user has permission to. E.g. cases linked to the user's account: the user has permission on cases because they have permission on the account, and the relationship grants child access.

Misconfigured table permissions are the #1 source of Power Pages data leaks. Test every permission scenario before going live.

Page permissions. Control which authenticated users see which pages. Anonymous browsing of certain pages, web-role gating of others. A "members area" exists because page permissions block unauthenticated users.

Content permissions. Control which file attachments are visible per user — for portals that distribute documents (statements, policy documents) per customer.

Anti-CSRF and request validation. Power Pages includes built-in protection against cross-site request forgery, with form-level tokens. Don't disable these.

Audit and logging. Portal access events log to Dataverse audit; configure audit on sensitive tables. Identity-provider login events log at the IdP.

DLP. Power Pages can be governed by data loss prevention policies like any other Power Platform app, classifying connectors as Business / Non-Business and preventing inadvertent data flow.

Operational reality. Run a security review before every Power Pages launch. Test every web role with a real test user. Audit table permissions quarterly. Treat portal security with the same rigour as a public website.