Authentication & User Roles

Authentication & User Roles are two important security concepts in Microsoft Power Pages. Authentication answers the question, “Who is the user?” User roles answer the question, “What is this user allowed to access?”

Microsoft Learn explains that an important consideration when building public-facing websites is making sure that only the correct stakeholders can access critical business data. Power Pages provides a security model that includes site visibility, authenticated users, web roles, table permissions, page permissions, HTTPS headers, and security scan capabilities. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Authentication verifies the identity of a Power Pages site user, while user roles and permissions control what that user can see, open, create, update, or manage inside the website.

What is Authentication in Power Pages?

Authentication is the process of confirming the identity of a user who accesses a Power Pages website. When a user signs in, Power Pages can recognize that user and apply the correct security rules.

Microsoft documentation explains that Power Pages can use Microsoft Dataverse contact records to associate authenticated Power Pages site users. It also explains that page permissions can be configured to protect specific pages. [2](https://github.com/MicrosoftDocs/power-pages-docs/blob/main/power-pages-docs/security/authentication/index.md)

Microsoft Learn also states that Dataverse contact records represent Power Pages users, and users can get access to a site through authentication. Power Pages can integrate with authentication providers such as Microsoft Entra External ID, Microsoft, and LinkedIn. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Authentication Concept	Simple Meaning	Power Pages Example
Authentication	Verifies who the user is	A customer signs in to a customer portal
Authenticated User	A user who has signed in successfully	A registered partner logs in to view partner records
Anonymous User	A visitor who has not signed in	A visitor browses a public FAQ page
Identity Provider	A service used to sign in users	Microsoft Entra External ID, Microsoft, or LinkedIn
Dataverse Contact	The record used to represent a Power Pages site user	A customer contact record is linked with website access

What are User Roles in Power Pages?

In Power Pages, user roles are mainly managed using web roles. A web role groups users and connects those users to permissions for pages and data.

Microsoft Learn explains that web roles allow users to perform special actions or access protected content and data on the site. Web roles link to users, table permissions, and page permissions. Because users can be assigned multiple web roles, they can get cumulative access to site resources. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Microsoft Learn also explains that a web role is basically a collection of permissions to site content, and before authenticated users can be granted access to restricted tables or restricted pages, they need to be assigned to a web role. [3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Role Concept	Simple Meaning	Example
Web Role	A collection of permissions for site content and data	Customer, Partner, Manager, Administrator
Authenticated Users Role	A default role for signed-in users	All logged-in users can access basic user pages
Anonymous Users Role	A default role for users who are not signed in	Public visitors can access public pages
Multiple Roles	One user can have more than one role	A user can be both Customer and Premium Customer
Cumulative Access	Access can combine from multiple roles	A user receives permissions from all assigned roles

Authentication vs Authorization

Authentication and authorization are related, but they are not the same. Authentication confirms identity. Authorization controls access after identity is known.

Area	Question Answered	Power Pages Example
Authentication	Who is the user?	The user signs in through an identity provider
Authorization	What can the user access?	The user’s web role allows access to selected pages or Dataverse records
Authentication Result	User identity is known	The site recognizes the signed-in contact
Authorization Result	User access is controlled	The user can view only the allowed page, list, form, or data

Microsoft Learn supports this distinction by explaining that users access a site through authentication, while web roles, table permissions, and page permissions control access to protected content and Dataverse information. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

How Power Pages Security Works

Power Pages security can be understood as a layered model. A user first reaches the site, then may sign in, then receives web roles, and then those roles are checked against page permissions and table permissions.

User visits Power Pages website
        |
        v
Is the user signed in?
        |
        +-- No  → Anonymous user rules apply
        |
        +-- Yes → Authenticated user is linked to Dataverse Contact
                    |
                    v
                Web roles are checked
                    |
                    v
        Page permissions and table permissions are applied
                    |
                    v
        User sees only allowed pages and data

This diagram is a learning-friendly representation based on Microsoft Learn’s explanation that Dataverse contact records represent Power Pages users, authenticated users can be assigned web roles, web roles link to table and page permissions, and page/table permissions protect content and data. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Authenticated Users

An authenticated user is a user who has signed in to the Power Pages site. Once the user signs in, Power Pages can apply the correct security rules based on the user’s contact record and assigned web roles.

Microsoft Learn states that authenticated users can be assigned web roles that provide specific access to information on the site. It also states that all authenticated users, or contacts, are automatically assigned to the Authenticated Users web role. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Authenticated User Scenario	Meaning
Customer signs in	The customer can access protected customer pages if permissions allow it.
Partner signs in	The partner can access partner-specific content if assigned the correct web role.
Employee signs in	The employee can use internal or employee-facing portal features if permitted.

Anonymous Users

Anonymous users are visitors who browse the website without signing in. They may be allowed to view public content, but they should not automatically receive access to protected business data.

Microsoft Learn states that anonymous, or unauthenticated, users can visit a site and get access to assets through the Anonymous Users web role. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Microsoft Learn also explains that when a web role is set as the Anonymous Users Role, it is the default role for all users and is intended to be used with table permissions. It also states that a site can have only one Anonymous Users web role for unauthenticated users. [3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Anonymous User Access	Recommended Use	Example
Public pages	Allowed when content is meant for everyone	Home, About, FAQ, Contact page
Public information	Allowed when no private business data is exposed	Service descriptions or public announcements
Business data	Should be controlled carefully using permissions	Public enquiry form with limited create permission

Web Roles

Web roles are central to user role management in Power Pages. They determine which users can access protected content and data.

Microsoft Learn explains that a web role is a collection of permissions to the content of a site. It also explains that web roles can be created and assigned through the Portal Management app. [3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Microsoft Learn states that web roles link to users, table permissions, and page permissions. Because users can be assigned multiple web roles, access can be cumulative across the roles assigned to the user. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Web Role	Possible Purpose	Example Access
Customer	For registered customers	Submit and view own service requests
Partner	For external partner users	View partner-specific records or forms
Manager	For users who review submitted data	View request lists or approval pages
Administrator	For portal administrators or support users	Manage wider website or data access

The role names in the table are teaching examples. The underlying concept is based on Microsoft Learn’s explanation that web roles allow users to perform special actions or access protected content and data on the site. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Default Web Roles

Power Pages supports default web role behavior for authenticated and anonymous users.

Microsoft Learn explains that if Authenticated Users Role is set to Yes, the web role becomes the default role for all authenticated users, and a site should have only one Authenticated Users web role for authenticated users. [3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Microsoft Learn also explains that if Anonymous Users Role is set to Yes, the web role becomes the default role for all users, is intended to be used with table permissions, and a site can have only one Anonymous Users web role for unauthenticated users. [3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Default Role Type	Who Gets It?	Important Point
Authenticated Users Role	Signed-in users	A website should have only one default authenticated users web role.
Anonymous Users Role	Users who are not signed in	A website should have only one default anonymous users web role.

Assigning Users to Web Roles

After creating a web role, users need to be assigned to that role. Microsoft Learn explains that site users can be assigned to web roles either from the contact record or from the web role record. [3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Microsoft Learn also explains that if a site uses the enhanced data model, web roles should be assigned from the contact under the enhanced data model. [3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Assignment Method	Meaning
From Web Role	Select a web role and add existing contacts to that role.
From Contact	Select a contact and add existing web roles to that contact.
Enhanced Data Model	Assign web roles from the contact under the enhanced data model.

Page Permissions

Page permissions protect website pages. They help control which users or roles can view specific pages or page content.

Microsoft Learn states that page permissions are associated with web roles to allow access and can protect content and components on individual pages. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Microsoft documentation also states that users may want to limit access to site pages and data to specific users, and page permissions can be configured to protect specific pages. [2](https://github.com/MicrosoftDocs/power-pages-docs/blob/main/power-pages-docs/security/authentication/index.md)

Page Permission Scenario	Recommended Access
Home page	Public or anonymous access may be allowed.
FAQ page	Public or anonymous access may be allowed.
My Requests page	Authenticated users only.
Manager dashboard	Manager or administrator web role only.
Admin page	Administrator web role only.

The page examples are learning scenarios based on Microsoft Learn’s documented concept that page permissions protect individual pages and are associated with web roles. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Table Permissions

Table permissions protect Dataverse data that is exposed through Power Pages. This is critical because Power Pages websites often allow external users to view or submit business data.

Microsoft Learn explains that access to Dataverse records is automatically restricted in Power Pages when using forms, lists, Liquid, the Portals Web API, and other components accessing Dataverse tables. To allow access to Dataverse records, makers need to configure table permissions and associate those table permissions with web roles. [4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Microsoft Learn also states that table permissions are associated with web roles to provide appropriate access to users. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Table Permission Element	Meaning	Example
Table	The Dataverse table being protected	Service Request, Registration, Application
Privileges	The allowed actions on data	Read, Create, Write, Delete, Append, Append To
Access Type	The scope of records the user can access	Global, Contact, Account, Self
Web Role Association	The role that receives the permission	Customer role gets access to customer request records

Table Permission Access Types

Microsoft Learn states that the Power Pages design studio shows four access types for table permissions: Global access, Contact access, Account access, and Self access. [4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Access Type	Meaning from Microsoft Learn	Teaching Example
Global access	Applies selected table permission and privileges to users from selected roles for all records.	Administrator can read all support requests.
Contact access	Applies selected table permission and privileges to users from the selected role associated to the signed-in user.	Customer can view records connected to their contact.
Account access	Applies selected table permission and privileges to users from the selected role associated to the signed-in user's account.	Partner user can view records linked to their account.
Self access	Applies selected table permission and privileges to users from the selected role for only their own Contact record.	User can update their own profile contact information.

The meaning of each access type is based on Microsoft Learn’s table permissions article; the teaching examples are beginner-friendly examples aligned with those meanings. [4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

How Web Roles, Page Permissions, and Table Permissions Work Together

A secure Power Pages site usually combines web roles, page permissions, and table permissions. Web roles identify the user group. Page permissions protect the page. Table permissions protect the Dataverse records shown or submitted on that page.

Web Role
   |
   +-- Page Permissions
   |       |
   |       +-- Controls which pages the user can access
   |
   +-- Table Permissions
           |
           +-- Controls which Dataverse records the user can access

Microsoft Learn states that web roles link to users, table permissions, and page permissions, and table permissions are used to protect access to Dataverse information through lists, forms, Liquid, and the Web API. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Example: Customer Portal Role Design

A customer portal may allow anonymous visitors to see public pages, signed-in customers to submit and view their own requests, and administrators to view all records.

User Type	Authentication Status	Suggested Web Role	Access Example
Visitor	Anonymous	Anonymous Users	Can view Home, About, FAQ, and public content
Customer	Authenticated	Customer	Can submit service requests and view allowed records
Support Agent	Authenticated	Support Agent	Can view support-related pages and records according to permissions
Administrator	Authenticated	Administrator	Can access administrative pages and broader records if permissions allow

This is a teaching example. It is based on Microsoft Learn’s concepts that anonymous users can access assets through the Anonymous Users web role, authenticated users can be assigned web roles, web roles provide access to protected content and data, and table/page permissions control access. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Example: Course Registration Website

For a course registration website, some pages may be public while registration history or admin review pages should be restricted.

Page or Data	User Role	Security Idea
Course Overview Page	Anonymous Users	Public visitors can read course information.
Registration Form	Anonymous Users or Authenticated Users	Users can submit registration data if table permissions allow create access.
My Registrations Page	Authenticated Users	Signed-in users can view records allowed by table permissions.
Registration Admin List	Administrator	Admin users can review registrations if page and table permissions allow it.

This scenario is a learning example based on Microsoft Learn’s explanation that page permissions protect pages, table permissions protect Dataverse data through lists and forms, and web roles connect users to those permissions. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Authentication & User Roles Design Process

A good Power Pages security design should start with user analysis. First, identify the user groups. Then decide who must sign in, which pages they can view, and which Dataverse records they can access.

Identify user groups
        |
        v
Decide anonymous vs authenticated access
        |
        v
Create web roles
        |
        v
Assign users to web roles
        |
        v
Configure page permissions
        |
        v
Configure table permissions
        |
        v
Test access as each user type

This design process is a teaching workflow based on Microsoft Learn’s documented security components: authenticated users, web roles, page permissions, and table permissions. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)[3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Recommended Role Planning Table

Before building a Power Pages site, learners should prepare a role planning table. This makes security easier to explain, build, test, and maintain.

Role Name	User Type	Sign-in Required?	Pages Needed	Data Needed
Anonymous User	Public visitor	No	Home, About, FAQ	Only public or permitted data
Customer	External registered user	Yes	My Requests, Submit Request	Own or related records based on permissions
Partner	External business user	Yes	Partner Dashboard, Submission Forms	Partner-related records based on permissions
Admin	Site support or administrator	Yes	Admin Pages, Review Lists	Broader records if permissions allow

This planning table is a classroom tool. It is aligned with Microsoft Learn’s explanation that authenticated users can be assigned web roles, web roles link to page and table permissions, and table permissions control Dataverse access through site components. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Security Workspace

Microsoft Learn states that the Security workspace in the Power Pages design studio can be used to monitor, protect, and manage Power Pages sites. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Microsoft Learn also states that table permissions can be added and modified from the Security workspace by selecting Security in the design studio and then selecting Table permissions in the Protect section. [4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Security Area	Purpose
Site visibility	Controls who can access the site during development or public use.
Authenticated users	Represents users who access the site through authentication.
Web roles	Groups users and links them with permissions.
Page permissions	Protects individual pages and page components.
Table permissions	Protects Dataverse data accessed through forms, lists, Liquid, and Web API.

These security areas are based on Microsoft Learn’s Power Pages security model. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Authentication Provider Planning

Authentication provider planning means deciding how users will sign in to the Power Pages website. This decision depends on the audience and business scenario.

Microsoft Learn states that Power Pages can integrate with authentication providers like Microsoft Entra External ID, Microsoft, and LinkedIn. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Audience	Authentication Planning Question
Customers	How should customers identify themselves when they sign in?
Partners	Should partner users have separate controlled access?
Employees	Should employee access be separated from external visitor access?
Anonymous visitors	Which pages and data should be available without sign-in?

The planning questions are teaching recommendations based on Microsoft Learn’s statement that users access Power Pages through authentication and can be integrated with authentication providers. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)

Authentication & User Roles Checklist

Checklist Item	Question to Ask
User Groups	Who will use the website: anonymous visitors, customers, partners, employees, or admins?
Authentication	Which users must sign in?
Identity Provider	Which authentication provider will be used for sign-in?
Web Roles	Which web roles are required for each user group?
Page Permissions	Which pages should be public and which should be protected?
Table Permissions	Which Dataverse tables should each role access?
Privileges	Should users read, create, update, or delete records?
Access Type	Should access be Global, Contact, Account, or Self?
Testing	Has the site been tested using each user role?

This checklist is based on Microsoft Learn’s documented Power Pages security model, including authenticated users, web roles, page permissions, and table permissions. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Best Practices for Authentication & User Roles

Identify all user groups before creating web roles.
Keep public pages separate from protected pages.
Use web roles to group users by access requirement.
Use page permissions to protect pages that should not be public.
Use table permissions to protect Dataverse data shown through forms, lists, Liquid, and the Web API.
Assign only required privileges such as Read, Create, Write, or Delete.
Avoid giving broad access unless the business scenario requires it.
Test the website as anonymous users and as each authenticated role.

These best practices are teaching recommendations based on Microsoft Learn’s explanation that correct stakeholders should access critical business data, web roles control protected content and data, and table permissions are needed to allow Dataverse record access. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Common Mistakes Beginners Make

Thinking authentication alone protects all data.
Forgetting that page permissions and table permissions are separate security concepts.
Creating forms and lists without configuring table permissions.
Giving all users broad access instead of using proper role-based access.
Not testing anonymous user access before launch.
Not testing each web role separately.
Creating too many roles without a clear purpose.
Not documenting which role can access which page and data.

These mistakes are instructional cautions based on Microsoft Learn’s security model for authenticated users, web roles, page permissions, and table permissions. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Authentication & User Roles Terms to Remember

Term	Simple Meaning
Authentication	The process of verifying who the user is.
Authenticated User	A user who has signed in to the Power Pages site.
Anonymous User	A visitor who has not signed in.
Dataverse Contact	The contact record that represents a Power Pages site user.
Web Role	A collection of permissions that controls access to protected content and data.
Page Permission	A permission used to protect content and components on individual pages.
Table Permission	A permission used to protect Dataverse records accessed through Power Pages components.
Global Access	Access type that applies permissions to all records for selected roles.
Contact Access	Access type based on the signed-in user’s associated contact.
Account Access	Access type based on the signed-in user’s associated account.
Self Access	Access type for the user’s own contact record.

These terms are based on Microsoft Learn’s Power Pages security, web roles, authentication, and table permissions documentation. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)[2](https://github.com/MicrosoftDocs/power-pages-docs/blob/main/power-pages-docs/security/authentication/index.md)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

Important Points to Remember

Authentication verifies the identity of a Power Pages user.
Dataverse contact records represent Power Pages users.
Power Pages can integrate with authentication providers such as Microsoft Entra External ID, Microsoft, and LinkedIn.
Web roles allow users to access protected content and data.
Users can have multiple web roles, and access can be cumulative.
All authenticated users are automatically assigned to the Authenticated Users web role.
Anonymous users can access assets through the Anonymous Users web role.
Page permissions protect individual pages and page components.
Table permissions protect Dataverse records accessed through forms, lists, Liquid, Web API, and other components.
Table permissions must be associated with web roles to provide access to Dataverse records.

These points summarize Microsoft Learn’s guidance on authenticated users, web roles, page permissions, and table permissions in Power Pages. [1](https://learn.microsoft.com/en-us/power-pages/security/power-pages-security)[4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)[3](https://learn.microsoft.com/en-us/power-pages/security/create-web-roles)

Simple Summary

Authentication & User Roles are core security concepts in Power Pages. Authentication identifies the user, while user roles control what the user can access. In Power Pages, users are represented by Dataverse contact records, and authenticated users can be assigned web roles.

Web roles connect users to permissions. Page permissions protect pages, and table permissions protect Dataverse data shown through forms, lists, Liquid, Web API, and other Power Pages components. Microsoft Learn explains that to allow access to Dataverse records in Power Pages sites, table permissions must be configured and associated with web roles. [4](https://learn.microsoft.com/en-us/power-pages/security/table-permissions)

For beginners, the most important idea is this: do not only create pages and forms. Always plan who can sign in, which role they receive, which pages they can open, and which Dataverse records they can access.

Conclusion

Authentication & User Roles are essential for building secure Power Pages websites. A business website may look complete with pages, forms, and lists, but it is not production-ready unless authentication and access control are planned correctly.

Authentication confirms the user’s identity. Web roles group users by access needs. Page permissions protect website pages. Table permissions protect Dataverse records. Together, these features help ensure that public visitors, customers, partners, employees, and administrators see only the content and data they are allowed to access.

After learning this topic, learners can move to Power Pages Forms & Dataverse Data, where they will understand how forms, lists, Dataverse tables, and permissions work together to create secure data-driven business websites.