The last chapter established that table permissions decide what a visitor can access — but a table permission on its own doesn't know who's looking at the page. Something has to establish who the visitor is, then connect that identity to the right table permissions. That's the job of authentication and Web Roles.
- Authentication confirms who a visitor is — via a local account or an external identity provider
- A Web Role is the portal's version of a security role, built for external visitors
- Each table permission is tied to one or more web roles
- Anonymous Users is the default role for anyone not signed in
Authentication: how a visitor signs in
Authentication is a visitor proving who they are before the site treats them as a known, signed-in identity. Power Pages supports two approaches:
- A local Power Pages account — a username and password created directly on the portal, like signing up on any ordinary consumer website
- An external identity provider — signing in with an account a visitor already has, such as a Microsoft account, a Google account, or an organization's own identity system through Azure AD B2C
Either way, the result is the same: the portal ends up knowing exactly which visitor is sitting behind the browser.
Web Roles: the portal's version of a security role
Once authenticated, a visitor is sorted into a Web Role — the Power Pages equivalent of a security role, but built for external visitors and assigned entirely separately from the internal system. A Web Role connects a signed-in visitor to the table permissions from the last chapter: each table permission is tied to one or more web roles, and a visitor only gets the access granted by whichever web roles they've been assigned.
One web role always exists by default, whether or not anyone signs in: Anonymous Users. It's applied to any visitor browsing without being signed in, and it's typically kept deliberately thin — enough for genuinely public pages, none of the personal, scoped data that requires knowing who the visitor is.
| Web Role | Who's assigned it | Typical access |
|---|---|---|
| Anonymous Users | Anyone not signed in | Public pages only, no personal data |
| Authenticated Users | Any signed-in visitor | Common access shared by all signed-in visitors |
| Custom role, e.g. "Customers" | Specifically assigned signed-in visitors | Table permissions scoped to their own records |
Showing your ID to get a wristband
At an event with general admission, backstage, and VIP areas, someone checks your ID at the door first — that's authentication. You're then handed a wristband, and that wristband, not your ID, is what every door checks from then on.
Authentication is showing your ID at the door. The Web Role is the wristband color you're handed afterward. Anonymous Users is the basic wristband given to anyone who never checked in at all — it keeps the truly public parts of the site open without requiring a login for everything.
How the pieces connect
Put together, the flow is:
- A visitor authenticates (or doesn't, and stays Anonymous)
- That identity gets one or more Web Roles
- Each Web Role is linked to specific table permissions
- Those table permissions decide exactly which records, scopes, and privileges apply on any List or Form the visitor encounters
Every chapter in this course has been building toward this single chain. The capstone chapter next walks through it end to end on one worked example.