Power Pages Authentication Guide 2025: OAuth 2.0, OIDC & SAML 2.0 Explained

The Three Players

Before diving into technical flows, let's establish who's involved in every Power Pages authentication exchange:

You (the user)

The person trying to log in.

Power Pages (your portal)

Your website. It needs to know who you are before letting you in.

Identity Provider (the bouncer)

The trusted company that checks IDs — Microsoft Entra External ID, Google, Okta, Facebook, and others.

The core question

How does your portal trust what Microsoft (or any other identity provider) says?

The answer: digital signatures. Like a tamper-proof seal on a letter — if the seal is intact and matches the sender's known key, you can trust the contents.

OAuth 2.0 / OpenID Connect Deep Dive

Common identity providers: Microsoft Entra External ID, Entra ID (Azure AD), Google, GitHub, Auth0, Okta (OIDC)

Protocol flow: Authorization Code Flow with PKCE (recommended) or Hybrid Flow

Real-world analogy: the nightclub with police verification

Imagine a nightclub (Power Pages) that doesn't issue its own IDs. Instead, it trusts the police station (identity provider) to verify everyone's identity.

You arrive at the club and want to get in
Bouncer says: "I need proof from the police station down the street"
You walk to the police station
Police verify your identity (check your passport) and give you a stamped wristband
You return to the club with the wristband
Bouncer checks the stamp (validates it's authentic) → "You're in!"

Why this works: the club trusts the police's stamp. The police only stamp wristbands for verified people. The stamp can't be forged (digital signature). The wristband expires after a few hours (token expiry).

Technical flow: Authorization Code Flow, step-by-step

Phase 1: User initiates login

Step 1: User clicks "Sign in with Microsoft" on Power Pages.

Like walking up to the nightclub.

Phase 2: Authorization request

Step 2: Power Pages generates an authorization request with:

client_id — your app's ID
redirect_uri — where to return after login
scope — what info you need (openid, email, profile)
state — random value to prevent CSRF attacks
nonce — random value to prevent replay attacks

Like the bouncer writing a note: "Please verify this person and send them back."

Step 3: the browser redirects the user to the identity provider (e.g. the Microsoft login page).

Like walking to the police station.

Phase 3: User authentication

Step 4: user enters username and password on the IdP's login page.

Step 5: the IdP validates the credentials against its user database.

Like the police checking your passport.

Phase 4: Authorization code exchange

Step 6: the IdP generates an authorization code (short-lived, single-use).

Step 7: the browser redirects back to Power Pages with the code in the URL:

https://yoursite.powerappsportals.com/signin-oidc?code=abc123&state=xyz

Like getting a temporary receipt from police — not the full ID yet.

Step 8: Power Pages verifies the state parameter (CSRF protection).

Step 9: Power Pages makes a backend request to the IdP's token endpoint:

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=abc123&
client_id=your-client-id&
client_secret=your-secret&
redirect_uri=https://yoursite.powerappsportals.com/signin-oidc

Like the club manager calling the police station to verify the receipt.

Why backend? the client_secret must never be exposed to the browser.

Phase 5: Token validation & session creation

Step 10: the IdP returns tokens:

id_token (JWT) — contains user identity claims
access_token — for API calls (optional in Power Pages)
refresh_token — to get new tokens without re-login (optional)

Step 11: Power Pages validates the id_token:

✅ Signature is valid (using the IdP's public key)
✅ Issuer (iss) matches the expected IdP
✅ Audience (aud) matches our client_id
✅ Token hasn't expired (exp claim)
✅ Nonce matches the one we sent

Like the bouncer checking the stamp is authentic and not expired.

Step 12: Power Pages extracts user claims from the token (email, name, etc.).

Step 13: Power Pages creates or updates the contact record in Dataverse.

Step 14: Power Pages creates a session cookie.

Step 15: the user is redirected to the originally requested page.

Like finally getting into the club with your verified wristband.

Phase 6: Subsequent requests

Every page load: Power Pages checks the session cookie.

Token expired? Use the refresh token to get new tokens (if configured).

Session expired? The user must log in again.

Why the two-step dance? (Code → tokens)

The problem: if the IdP sent tokens directly in the browser URL (or as a POST to the browser), malicious JavaScript on the page could steal them.

The solution: the Authorization Code Flow separates concerns:

Frontend: the browser only ever sees a short-lived, single-use authorization code
Backend: the Power Pages server exchanges the code for tokens using the client secret
Result: tokens never touch the browser, which makes token theft far harder

It's like getting a receipt at the police station, then the club manager calls to verify and gets the full details privately.

Visual flow diagram

sequenceDiagram autonumber actor User participant Browser participant PP as Power Pages participant IdP as Identity Provider User->>Browser: 1. Navigate to portal Browser->>PP: 2. Request protected page PP->>Browser: 3. Redirect to login page rect rgb(200, 220, 255) Note over User,Browser: User initiates login User->>Browser: 4. Click "Sign in with Azure AD" end rect rgb(255, 220, 200) Note over Browser,IdP: Authorization Request Phase Browser->>PP: 5. POST /signin-oidc PP->>PP: 6. Generate auth request
(client_id, redirect_uri, scope, state, nonce) PP->>Browser: 7. HTTP 302 Redirect to IdP Browser->>IdP: 8. GET /authorize?params end rect rgb(200, 255, 220) Note over User,IdP: User Authentication Phase IdP->>Browser: 9. Show login page User->>Browser: 10. Enter username/password Browser->>IdP: 11. POST credentials IdP->>IdP: 12. Validate credentials end rect rgb(255, 255, 200) Note over Browser,PP: Authorization Code Exchange IdP->>Browser: 13. HTTP 302 with code Browser->>PP: 14. GET /signin-oidc?code=xyz&state=abc PP->>PP: 15. Verify state parameter PP->>IdP: 16. POST /token
(code, client_id, client_secret) IdP->>IdP: 17. Validate code & client IdP->>PP: 18. Return id_token + access_token end rect rgb(220, 200, 255) Note over PP: Token Validation & Session Creation PP->>PP: 19. Validate id_token signature PP->>PP: 20. Check iss, aud, exp, nonce PP->>PP: 21. Extract user claims PP->>PP: 22. Create/update user in Dataverse PP->>PP: 23. Create session cookie end PP->>Browser: 24. Set-Cookie + Redirect to original page Browser->>PP: 25. Request original page with cookie PP->>Browser: 26. Return protected content Browser->>User: 27. Display page

Diagram legend: the colored bands group related steps together. Numbers match the step-by-step explanation above.

Required parameters

These parameters must be configured for authentication to work:

Parameter	Description	Example value
Provider Name REQUIRED	The text displayed on the sign-in button that users see on the login page	"Sign in with Company Account" "Sign in with Microsoft"
Authority REQUIRED	The identity provider's authorization endpoint URL. Tells Power Pages where to redirect users for authentication.	`https://{tenant}.ciamlogin.com/` (Entra External ID) `https://login.microsoftonline.com/{tenant-id}/` (Entra ID) `https://accounts.google.com/` (Google)
Client ID REQUIRED	The application (client) ID from your IdP app registration. Uniquely identifies your Power Pages site to the identity provider.	`12345678-90ab-cdef-1234-567890abcdef`
Redirect URL REQUIRED	The Power Pages callback URL where the IdP sends users after authentication. Auto-generated by Power Pages — always use the Copy button, never type this manually.	`https://yoursite.powerappsportals.com/signin-oidc`
Metadata Address REQUIRED	The OpenID Connect discovery document URL. Contains all the IdP's endpoints, supported features, and public keys for token validation. Power Pages fetches this automatically to configure itself.	`https://{tenant}.ciamlogin.com/.well-known/openid-configuration`
Scope REQUIRED	Space-separated list of OAuth scopes to request. `openid` is mandatory. Add `email` for the user's email, `profile` for first/last name.	`openid email` (minimal) `openid email profile` (recommended)
Response Type REQUIRED	The OAuth flow type. `code id_token` (hybrid flow) is recommended for security — it provides both an authorization code and an ID token.	`code id_token` (recommended)
Client Secret REQUIRED*	The client secret from your IdP app registration. Required when Response Type includes `code`. Proves the token exchange request comes from your authorized site. Keep it secure.	*Required only if Response Type contains `code`
Response Mode REQUIRED	How the IdP returns the authentication response. `form_post` is recommended — it sends tokens via HTTP POST (safer than URL fragments).	`form_post` (recommended)

Optional / advanced parameters

These provide additional control but aren't required for basic authentication:

Parameter	Description	Default / use case
External Logout	Enable federated sign-out. On: signing out of Power Pages also signs the user out of the IdP. Off: only signs out of Power Pages.	Off (default). Turn on for high-security scenarios.
Post Logout Redirect URL	Where to redirect users after sign-out. Must be configured in the IdP's allowed logout URLs.	`https://yoursite.powerappsportals.com/`
RP Initiated Logout	Allow the relying party (Power Pages) to initiate sign-out at the IdP. Only works when External Logout is on.	Off (default). Requires External Logout = On.
Issuer Filter	Wildcard-based filter for multi-tenant scenarios. Use this to accept tokens from multiple Azure AD tenants.	`https://sts.windows.net/*/` — B2B portals with users from different companies
Validate Audience	When on, Power Pages checks that the `aud` claim matches one of your Valid Audiences.	Off (default). Production recommendation: on + set Valid Audiences.
Valid Audiences	Comma-separated allowed audience values. Prevents token misuse across applications.	`api://12345678-90ab-cdef`. Requires Validate Audience = on.
Validate Issuers	When on, Power Pages only accepts tokens from IdPs in your Valid Issuers list.	Off (default). Prevents token replay from unauthorized IdPs.
Valid Issuers	Comma-separated allowed issuer URLs.	`https://sts.windows.net/{tenant1}/,https://sts.windows.net/{tenant2}/`
Registration Claims Mapping	Map claims from the IdP token to Dataverse contact fields during registration. Format: `contact_field=token_claim`.	`firstname=given_name,lastname=family_name`. Text and Boolean only.
Login Claims Mapping	Map claims to Dataverse contact fields on every sign-in, keeping contact data in sync.	Use the same mapping as Registration for consistency.
Nonce Lifetime	How long (minutes) the nonce value is valid, preventing replay attacks.	10 minutes (default). Adjust if users on slow networks hit timeouts.
Use Token Lifetime	Match the Power Pages session lifetime to the IdP token expiry. Overrides the default 8-hour timeout — session ends when the token expires (typically 1 hour).	Off (default = 8 hours). Turn on for high-security portals.
Contact Mapping with Email	Automatically link the IdP identity to a Dataverse contact by matching email address. Off: a new contact is created for every new IdP identity, even on an email match.	On (default, recommended). When off, the same user can create multiple contacts across different IdPs.

OAuth/OIDC quick start

For 90% of OAuth/OIDC scenarios, you only need the required parameters:

Register an app in your IdP (Entra External ID, Google, etc.)
Copy the Redirect URL from Power Pages → paste it as the Redirect URI in the IdP
Get Client ID and Client Secret from the IdP
Find the Metadata Address (usually in the IdP app overview or endpoints section)
Set Scope to openid email (or openid email profile for first/last name)
Set Response Type to code id_token and Response Mode to form_post
Test in incognito mode

OAuth/OIDC dos and don'ts

Do — OAuth best practices

Use code id_token response type — hybrid flow provides the best security and UX
Always request the email scope — required for user identification and contact mapping
Use the Copy button for Redirect URL — typos cause 80% of OAuth failures
Verify the metadata URL is publicly accessible — open it in a browser without authentication
Start with minimal scopes — openid email is enough; add profile only if needed
Set client secret expiry to 6–12 months — forces rotation without being too frequent
Test token claims in jwt.io — verify email, name, groups arrive as expected
Enable diagnostic logging before testing — Power Pages → Settings → Authentication
Test with non-admin accounts — admin accounts have different token claims
Configure claims mapping for first/last name — improves the profile page experience

Don't — OAuth pitfalls

Don't type the Redirect URL manually — one wrong character = cryptic "redirect_uri_mismatch"
Don't forget the trailing slash in Authority — https://login.microsoftonline.com/{tenant-id}/
Don't share client secrets across multiple sites — each site needs its own app registration
Don't test only in your own browser — test incognito, different browsers, mobile
Don't use implicit flow — response type id_token alone is deprecated
Don't request unnecessary scopes — more scopes = more consent prompts = higher drop-off
Don't ignore token expiry — the default 1-hour lifetime needs a session strategy
Don't forget the Post Logout Redirect URL — otherwise users see the IdP's logout page
Don't assume SSO = Single Sign-Out — SSO works, but single sign-out is not supported
Don't skip claims mapping validation — wrong mapping breaks user profiles

Top 5 OAuth/OIDC configuration mistakes

1. Redirect URI mismatch

Problem: the URL in Power Pages doesn't exactly match the one in the IdP app registration (trailing slash, http vs. https, casing).

Symptom: "redirect_uri_mismatch" or "AADSTS50011".

Fix: use the Copy button in Power Pages, paste the exact value into the IdP.

2. Missing or wrong scope

Problem: scope doesn't include openid (mandatory) or email (needed for contact mapping).

Symptom: authentication works, but users have no email address in Power Pages and can't receive notifications.

Fix: set Scope to at least openid email.

3. Metadata URL not accessible

Problem: metadata URL requires authentication or sits behind a firewall/VPN.

Symptom: "Unable to retrieve metadata" or 404/401 during configuration.

Fix: metadata must be publicly accessible — test by opening it in a browser while logged out.

4. Expired client secret

Problem: the client secret expired (typically after 6–24 months).

Symptom: authentication worked before, then suddenly fails with "invalid_client" or "AADSTS7000222".

Fix: generate a new secret, update Power Pages, set a calendar reminder 30 days before the next expiry.

5. Wrong response mode

Problem: using query or fragment with a code id_token response type.

Symptom: tokens appear in the browser URL bar (security risk), or response mode mismatch errors.

Fix: always use form_post — the safest option for Power Pages.

OAuth/OIDC best practices by role

For identity provider admins (Entra External ID, Google, Auth0)

App registration setup

One app registration per Power Pages site — isolates configuration, easier troubleshooting, better security
Use descriptive app names — "Power Pages Production Customer Portal", not "App1"
Document all settings — screenshot the app registration, save in project documentation
Configure multiple owners — don't rely on a single person for secret rotation

Secret management

Set a 6-month expiry for client secrets — balances security and operational overhead
Use descriptive secret names with the expiry date — "Prod Secret (Expires Dec 2025)", not "Secret 1"
Create two secrets with staggered expiry — allows zero-downtime rotation
Set calendar reminders 30 days before expiry — prevents emergency "authentication is down" incidents

Claims & token configuration

Always include the email claim — essential for Power Pages contact mapping
Configure optional claims for profile data — enable given_name, family_name
Test tokens in jwt.io — decode ID tokens to verify claims before testing in Power Pages
Configure group claims for role mapping — use groups to auto-assign Power Pages roles
Keep token lifetime at the default 1 hour — don't extend it, to avoid security risk

For Power Pages admins

Configuration & testing

Always test in incognito/private mode — catches cookie and cache issues
Enable diagnostic logging before testing — logs show exact OAuth errors with codes
Test with non-admin accounts — admin tokens carry different claims
Test across devices — desktop Chrome, mobile Safari, Edge — OAuth behaves differently
Verify the email claim arrives in the contact record — check after the first login

Claims mapping

Configure Registration Claims Mapping — firstname=given_name,lastname=family_name
Use the same mapping for Login Claims Mapping — keeps contact data synced with the IdP
Don't map fields users can't change — mapping job title when users can't edit it causes confusion
Test claims mapping with a real user account — verify mapped fields land correctly

Session management

Understand the default 8-hour session — Power Pages session ≠ token expiry (token expires at 1 hour, session continues)
Consider Use Token Lifetime for high-security portals — forces re-authentication when the token expires
Test session expiry behavior — does the user get a clear error message after 8 hours?
Educate users about IdP session vs. Power Pages session — signing out of the portal doesn't sign out of the IdP

For consultants & developers

Troubleshooting workflow

Verify the Redirect URL — 80% of OAuth issues are redirect URL mismatches
Check Metadata URL accessibility — should return JSON without authentication
Verify Client ID and Secret — copy-paste from the IdP, don't trust memory
Check the scope configuration — must include openid at minimum
Review Power Pages diagnostic logs — look for specific error codes (AADSTS*, invalid_client, etc.)
Use the browser DevTools Network tab — watch the flow: authorization request → redirect → token exchange

Common error codes

AADSTS50011 — redirect URI mismatch
AADSTS7000222 — invalid client secret
AADSTS50105 — user not assigned to app
invalid_request — missing required parameter
unauthorized_client — client not authorized

Project delivery

Screenshot every working config screen — Client ID, Authority, Scopes, Claims Mapping
Document the client secret rotation process — who does it, how often
Create an error runbook — document errors seen during testing, with solutions
Provide user documentation — explain consent, logout, and session timeout

Single Sign-On (SSO) with OAuth/OpenID Connect

Quick answer: yes. OAuth 2.0 and OpenID Connect enable SSO across multiple applications.

How SSO works

The concert wristband analogy

Imagine a music festival with multiple stages (applications):

The entry gate checks your ticket and gives you a wristband
Stage 1 (App 1) sees your wristband → "You're in!"
Stage 2 (App 2) sees the same wristband → "You're in here too!"
No need to show your ticket again at each stage

That wristband is your access token from the identity provider.

What Power Pages supports

Single sign-in — log in once, access multiple Power Pages sites (if they use the same IdP)
Cross-application SSO — works with other apps using the same identity provider
Front-channel sign-out — logs you out of both Power Pages and the IdP

What Power Pages doesn't support

Single sign-out — logging out of one app won't automatically log you out of all apps
Cross-provider SSO — sessions can't be shared between Google and Microsoft logins

Real-world SSO scenarios

Scenario 1: employee portal + intranet

Setup: both use Microsoft Entra External ID

Employee logs into SharePoint → gets a token from Entra External ID
Employee visits the Power Pages portal → the same token works
No second login required

Scenario 2: customer portal + support app

Setup: both use Okta

Customer logs into the support app → gets an Okta token
Customer clicks a link to the Power Pages portal → automatically signed in
Seamless experience

What breaks SSO?

Different identity providers — portal uses Google, app uses Microsoft (won't share sessions)
Token expired — tokens typically last 1 hour, then you need to re-authenticate
Different domains — cookies don't cross domains (use the same parent domain if possible)
Incognito/private mode — no cookies, no SSO

Setting up SSO

Step 1: use the same identity provider everywhere

All apps → Microsoft Entra External ID, or
All apps → Okta, or
All apps → Google

Step 2: configure apps in the IdP

Register each app (Power Pages, SharePoint, custom apps)
Use the same tenant/organization
Configure proper redirect URLs for each app

Step 3: test the flow

Log into App 1 → get a token
Open App 2 in the same browser → should auto-login
Check: no second password prompt = SSO working

SSO token lifetime

Token type	Typical lifetime	What happens after
ID Token	1 hour	Needs refreshing (usually silent)
Access Token	1 hour	Refresh using the refresh token
Refresh Token	90 days (Microsoft)	Need to log in again
Power Pages Session	8 hours (configurable)	Redirected to the login page

Pro tip: silent token refresh

OAuth/OpenID Connect providers can silently refresh tokens in the background using refresh tokens:

The user's session stays active without re-login
It happens automatically before the token expires
The user doesn't notice anything

Power Pages does this automatically — you don't need to configure anything special.

When SSO doesn't work

Problem: "I logged into App A but still need to log in to Power Pages."

Checklist:

☐ Same identity provider? (Both must use Entra External ID, not one Entra + one Google)
☐ Same tenant? (Both must be in the same Entra External ID tenant)
☐ Same browser? (SSO doesn't cross browsers)
☐ Cookies enabled? (SSO needs cookies)
☐ Token still valid? (Check if it has expired)

SSO best practices

Keep it simple — one IdP for all apps (don't mix Google + Microsoft + Okta)
Communicate session limits — tell users "session expires in 8 hours"
Implement "remember me" — a longer refresh token means fewer re-logins
Test across apps — make sure SSO actually works before launch
Document the flow — so support knows what's expected

SAML 2.0 Deep Dive

Common identity providers: Okta, Microsoft Entra ID (Enterprise Apps), Azure AD B2C (with custom policies), Ping Identity, OneLogin, Shibboleth

Protocol flow: SP-initiated SAML flow (Power Pages redirects the user to the IdP for authentication)

Real-world analogy: the embassy visa system

Imagine you want to enter a foreign country (Power Pages) that requires a visa. You can't just show up — you need proof from your home country's embassy (identity provider) that you're authorized.

You arrive at the border (Power Pages login page)
Border guard says: "You need a visa from your embassy" and gives you an official form (SAML Request)
You take the form to your embassy (IdP login page)
Embassy staff verify your identity (check your passport, ask security questions)
Embassy stamps your visa application form (SAML Assertion) with an official seal
You return to the border with the stamped form
Border guard verifies the embassy seal (XML signature validation), checks it's authentic → "Welcome!"

Why this works: the border guard trusts the embassy seal (both agreed on security certificates beforehand). The embassy seal is tamper-proof (XML digital signature). The visa has an expiry (NotOnOrAfter). The visa is for this specific person (NameID matches).

Technical flow: SP-initiated SAML 2.0, step-by-step

Phase 1: User initiates login (service provider initiated)

Step 1: user clicks "Sign in with Okta" (or your SAML provider) on Power Pages.

Like arriving at the border checkpoint.

Phase 2: SAML authentication request (AuthnRequest)

Step 2: Power Pages generates a SAML AuthnRequest (XML document) containing:

Issuer — the service provider realm (your site's identifier)
AssertionConsumerServiceURL — where to send the response
ID — unique request ID (prevents replay attacks)
IssueInstant — timestamp when the request was created

Example SAML request:

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="_abcd1234"
  Version="2.0"
  IssueInstant="2025-11-06T10:30:00Z"
  Destination="https://idp.example.com/saml/sso"
  AssertionConsumerServiceURL="https://yoursite.powerappsportals.com/signin-saml2">
  <saml:Issuer>https://yoursite.powerappsportals.com/</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>

Like the border guard giving you an official form to take to the embassy.

Step 3: Power Pages encodes the XML request (Base64), optionally compresses it (Deflate), and redirects the browser to the IdP:

https://idp.example.com/saml/sso?SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdC...

Like walking to the embassy with the form.

Phase 3: User authentication at the IdP

Step 4: the IdP decodes and validates the SAML request:

Checks the Issuer is a known service provider
Validates the IssueInstant isn't too old
Checks AssertionConsumerServiceURL is registered

Step 5: the IdP shows a login page to the user.

Step 6: the user enters credentials (username/password, MFA, etc.).

Step 7: the IdP validates the credentials.

Like the embassy staff checking your passport and asking security questions.

Phase 4: SAML response (assertion) generation

Step 8: the IdP creates a SAML Assertion (XML) containing:

Issuer — the IdP's entityID
Subject/NameID — user's unique identifier (email, UPN, etc.)
Conditions — audience (must match the Service Provider Realm), NotBefore, NotOnOrAfter
AttributeStatement — user claims (email, first name, last name, roles)
AuthnStatement — when/how the user authenticated

Example SAML assertion:

<saml:Assertion ID="_xyz5678" IssueInstant="2025-11-06T10:31:00Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID Format="email">[email protected]</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2025-11-06T10:30:00Z" NotOnOrAfter="2025-11-06T11:31:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://yoursite.powerappsportals.com/</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="email"><saml:AttributeValue>[email protected]</saml:AttributeValue></saml:Attribute>
    <saml:Attribute Name="firstname"><saml:AttributeValue>John</saml:AttributeValue></saml:Attribute>
  </saml:AttributeStatement>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
</saml:Assertion>

Step 9: the IdP signs the XML assertion using its private key (X.509 certificate).

Like the embassy stamping and sealing the visa form.

Phase 5: POST assertion back to the service provider

Step 10: the IdP Base64-encodes the signed SAML response.

Step 11: the IdP sends an auto-submitting HTML form to the browser (HTTP POST binding):

<form method="POST" action="https://yoursite.powerappsportals.com/signin-saml2">
  <input type="hidden" name="SAMLResponse" value="PD94bWwgdmVyc2lvbj0iMS4w..." />
  <input type="submit" value="Continue" />
</form>
<script>document.forms[0].submit();</script>

Step 12: the browser automatically POSTs to the Power Pages ACS URL.

Like returning to the border with the stamped visa.

Phase 6: Assertion validation & session creation

Step 13: Power Pages decodes the SAML response.

Step 14: Power Pages validates the assertion:

✅ Signature valid: uses the IdP's public key (from metadata) to verify the XML signature
✅ Issuer matches: assertion Issuer = Authentication Type (entityID)
✅ Audience matches: Audience = Service Provider Realm
✅ Not expired: current time between NotBefore and NotOnOrAfter
✅ Not replayed: Assertion ID hasn't been used before (cached)

Like a border guard checking: is the embassy seal authentic? Is the visa for this country? Not expired? Not used before?

Step 15: extract user attributes from the AttributeStatement (email, name, etc.).

Step 16: create or update the contact record in Dataverse using NameID and attributes.

Step 17: create the Power Pages session cookie.

Step 18: redirect the user to the originally requested page.

Like finally being allowed to cross the border.

Key SAML differences from OAuth/OIDC

1. XML instead of JSON: SAML uses verbose XML documents. OAuth/OIDC uses compact JSON tokens.

2. Signatures on XML: SAML signs the entire XML assertion. OAuth signs JWT tokens with simpler Base64 encoding.

3. No backend token exchange: the SAML assertion is POSTed directly to the browser (but it's signed, so still secure). OAuth has a backend code-for-tokens exchange.

4. Certificate-based trust: SAML requires exchanging X.509 certificates beforehand. OAuth uses metadata discovery URLs.

5. Enterprise-focused: SAML is older (2005) and common in enterprise/B2B scenarios. OAuth/OIDC is newer (2012/2014) and more modern.

Visual flow diagram

sequenceDiagram autonumber actor User participant Browser participant PP as Power Pages
(Service Provider) participant IdP as Identity Provider
(Okta/Entra ID) User->>Browser: 1. Navigate to portal Browser->>PP: 2. Request protected page PP->>Browser: 3. Redirect to login page rect rgb(200, 220, 255) Note over User,Browser: User initiates login User->>Browser: 4. Click "Sign in with Okta" end rect rgb(255, 220, 200) Note over PP,IdP: SAML Authentication Request (AuthnRequest) Browser->>PP: 5. POST /signin-saml2 PP->>PP: 6. Generate SAML AuthnRequest XML
(Issuer, ACS URL, ID, Timestamp) PP->>Browser: 7. HTTP 302 Redirect with encoded SAML Request Browser->>IdP: 8. GET /sso?SAMLRequest=... end rect rgb(200, 255, 220) Note over User,IdP: User Authentication Phase IdP->>IdP: 9. Decode & validate SAML Request IdP->>Browser: 10. Show login page User->>Browser: 11. Enter username/password Browser->>IdP: 12. POST credentials IdP->>IdP: 13. Validate credentials end rect rgb(255, 255, 200) Note over IdP,PP: SAML Response (Assertion) Generation IdP->>IdP: 14. Create SAML Assertion XML
(Issuer, NameID, Attributes, Conditions) IdP->>IdP: 15. Sign XML with X.509 certificate IdP->>Browser: 16. Auto-submit HTML form with SAMLResponse Browser->>PP: 17. POST /signin-saml2 with SAMLResponse end rect rgb(220, 200, 255) Note over PP: Assertion Validation & Session Creation PP->>PP: 18. Decode SAML Response PP->>PP: 19. Validate XML signature (using IdP public key) PP->>PP: 20. Check Issuer, Audience, NotBefore, NotOnOrAfter PP->>PP: 21. Extract NameID & Attributes PP->>PP: 22. Create/update user in Dataverse PP->>PP: 23. Create session cookie end PP->>Browser: 24. Set-Cookie + Redirect to original page Browser->>PP: 25. Request original page with cookie PP->>Browser: 26. Return protected content Browser->>User: 27. Display page

Diagram legend: notice how SAML uses XML (not JSON) and signs the entire assertion instead of using a backend token exchange like OAuth.

Required parameters

These parameters must be configured for SAML authentication to work:

Parameter	Description	Example value
Provider Name REQUIRED	The text displayed on the sign-in button	"Sign in with Okta" "Sign in with Company SSO"
Metadata Address REQUIRED	The SAML 2.0 federation metadata document URL. Contains all SAML endpoints, certificates, and supported features. Power Pages parses this automatically.	`https://login.microsoftonline.com/{tenant-id}/federationmetadata/2007-06/federationmetadata.xml` (Entra ID) `https://yourorg.okta.com/app/{app-id}/sso/saml/metadata` (Okta)
Authentication Type REQUIRED	The `entityID` value from the SAML metadata document, uniquely identifying the identity provider. Find it by opening the Metadata Address URL and copying the `<entityID>` value from the root `<EntityDescriptor>` element.	`https://sts.windows.net/{tenant-id}/` (Entra ID) `http://www.okta.com/{externalKey}` (Okta)
Service Provider Realm REQUIRED	The App ID URI from your IdP app registration (also called Audience in SAML terms). Must match exactly what you configured in the IdP as the SP Entity ID.	`https://yoursite.powerappsportals.com/` `api://{app-id}`
Assertion Consumer Service URL REQUIRED	The Power Pages callback URL where the IdP sends SAML assertions (also called ACS URL). Auto-generated by Power Pages; must match the IdP's configured ACS/Reply URL.	`https://yoursite.powerappsportals.com/signin-saml2`

Optional / advanced parameters

Parameter	Description	Default / use case
Validate Audience	When on, Power Pages checks that the `Audience` element matches one of your Valid Audiences values, preventing assertion replay attacks.	Off (default). Turn on for production.
Valid Audiences	Comma-separated list of allowed audience values, matching your Service Provider Realm.	`https://yoursite.powerappsportals.com/`. Requires Validate Audience = on.
Contact Mapping with Email	Automatically link the IdP identity to a Dataverse contact by email match. Off: always create a new contact for each new SAML identity.	On (default). Ensure the IdP sends an email claim (NameID or attribute).

How to find the entityID (Authentication Type)

Copy the Metadata Address URL from your IdP
Paste it into a web browser
You'll see an XML document
Look for the <EntityDescriptor entityID="..."> tag at the top
Copy the entityID value — that's your Authentication Type

Example: in <EntityDescriptor entityID="https://sts.windows.net/abc123/">, the entityID is https://sts.windows.net/abc123/.

SAML 2.0 dos and don'ts

Do — SAML best practices

Always verify the metadata URL is accessible — should return XML without authentication
Copy entityID exactly from metadata — including protocol, trailing slash, casing
Match Service Provider Realm to the IdP configuration — exactly what was configured as SP Entity ID
Configure Name ID format in the IdP — Persistent or Email format works best for Power Pages
Send the email claim in the SAML assertion — as NameID or a separate email attribute
Test assertions in a SAML decoder tool — decode responses to verify claims
Turn on Validate Audience in production — prevents assertion replay attacks
Use the SHA-256 signing algorithm — SHA-1 is deprecated and may be rejected
Configure assertion expiry appropriately — 5–10 minutes is typical
Document the certificate renewal process — SAML certificates expire

Don't — SAML pitfalls

Don't confuse Service Provider Realm with ACS URL — they serve different purposes
Don't use the same value for Realm and ACS URL — a common mistake causing validation errors
Don't type the entityID manually — copy the exact value from the metadata XML
Don't forget to configure claim rules in the IdP — Power Pages needs at minimum the NameID claim
Don't use the SHA-1 signing algorithm — deprecated, may cause rejections
Don't ignore certificate expiry — SAML certs expire (typically 1–3 years)
Don't test only the SP-initiated flow — some IdPs require IdP-initiated configuration too
Don't assume SAML = OAuth — different protocols, configuration, and error messages
Don't skip metadata validation — verify it contains SingleSignOnService and a signing certificate
Don't forget clock skew tolerance — ensure the IdP and Power Pages servers use NTP

Top 5 SAML configuration mistakes

1. Service Provider Realm vs. ACS URL confusion

Problem: using the same value for both fields, or swapping them.

Symptom: "Audience mismatch" or "Invalid destination" errors.

Fix: Service Provider Realm = who you are (your SP entity ID). ACS URL = where to send the response (/signin-saml2). These must differ.

2. Wrong entityID (Authentication Type)

Problem: entityID doesn't match the metadata document.

Symptom: "Unknown issuer" or "Issuer mismatch" errors.

Fix: open the metadata URL, find <EntityDescriptor entityID="...">, copy the exact value.

3. Missing email claim

Problem: the IdP doesn't send an email claim, or sends it in an unexpected format.

Symptom: users authenticate but the contact record has no email.

Fix: configure the IdP to send email as NameID or as a dedicated email attribute claim.

4. Metadata URL not accessible

Problem: metadata requires authentication, is behind a firewall, or returns HTML instead of XML.

Symptom: "Unable to retrieve metadata" or "Invalid metadata document".

Fix: metadata must be a publicly accessible URL returning valid XML.

5. Clock skew issues

Problem: a time difference between the IdP and Power Pages causes assertion validation failures.

Symptom: intermittent "Assertion expired" or "Assertion not yet valid" errors.

Fix: ensure the IdP uses NTP; configure assertion validity to 5–10 minutes.

SAML 2.0 best practices by role

For identity provider admins (Okta, Entra ID, Ping)

SAML application setup

Use descriptive app names — "Power Pages Customer Portal (Production)", not "SAML App 1"
Configure the Single Sign-On URL (ACS URL) correctly — must end with /signin-saml2
Set the SP Entity ID to the site URL
Configure the Name ID format — "Persistent" or "Email" for best compatibility
Make metadata publicly accessible — Power Pages must fetch it without authentication

Claim configuration

Always send the email claim — as NameID or as .../claims/emailaddress
Send first name and last name if available — use givenName and surname
Consider sending group memberships — usable for Power Pages role assignment
Test claims with a SAML decoder — verify all expected claims arrive

Certificate management

Use SHA-256 — SHA-1 is deprecated
Set calendar reminders for certificate expiry — typically 1–3 years
Rotate certificates without downtime — configure the new cert alongside the old
Publish the new certificate in metadata before activation

Security settings

Sign assertions, not just responses — prevents assertion substitution attacks
Set assertion validity to 5–10 minutes
Don't sign with SHA-1
Enable audience restriction

For Power Pages admins

Configuration & testing

Copy the Assertion Consumer Service URL from Power Pages — don't type it manually
Verify Service Provider Realm matches the IdP configuration — exact match, case-sensitive
Test the metadata URL before configuring
Copy entityID from metadata XML — don't guess
Enable diagnostic logging before testing
Use a SAML decoder browser extension

Troubleshooting tools

SAML-tracer or SAML DevTools browser extension — captures and decodes SAML traffic
Online SAML decoder — samltool.com
Power Pages diagnostic logs — full assertion validation errors
IdP sign-in logs — check if authentication succeeds at the IdP

Production readiness

Turn on Validate Audience — set Valid Audiences to your Service Provider Realm
Document the certificate expiry date
Test from multiple networks — corporate VPN, home internet, mobile
Verify Contact Mapping with Email is on — prevents duplicate contacts

For consultants & developers

SAML troubleshooting checklist

Verify metadata accessibility — should return XML
Check entityID matches — compare Authentication Type to <EntityDescriptor entityID>
Verify Service Provider Realm matches the IdP
Check the ACS URL is correct — must end with /signin-saml2
Use a SAML decoder — verify claims
Check Power Pages diagnostic logs
Verify the certificate is valid — expiry date, signing algorithm (SHA-256+)

Common SAML error messages

"Unknown issuer" → entityID doesn't match the assertion
"Audience mismatch" → Service Provider Realm doesn't match the assertion's audience
"Invalid destination" → ACS URL in the assertion doesn't match the configured value
"Assertion expired" → clock skew, or assertion validity too short
"Signature validation failed" → certificate mismatch, expired cert, or wrong algorithm
"Missing NameID" → IdP not sending the NameID claim

Project documentation

Screenshot the IdP SAML configuration — SP Entity ID, ACS URL, NameID format, claim rules
Save the metadata URL and entityID
Document the certificate expiry process
Create a SAML error runbook
Provide user documentation

Social Identity Providers (quick setup for B2C)

What are social identity providers?

Power Pages includes five pre-configured OAuth 2.0 providers for consumer authentication scenarios. These are simplified, wizard-based alternatives to the generic OAuth/OIDC setup covered above.

Microsoft

Google

Facebook

Twitter/X

Key limitation: Power Pages doesn't support other OAuth providers beyond these five. For custom providers (Auth0, Okta, or your own OAuth server), use the generic OpenID Connect configuration instead.

Supported social providers

Provider	Setup location	Best use case	Special requirements
Microsoft	Azure Portal	B2C portals where users have Microsoft accounts	Azure AD app registration
Google	Google Console	Public-facing customer portals, wide consumer reach	Enable Google People API
Facebook	Facebook Developers	Consumer apps, social integration	App registration, privacy policy URL
LinkedIn	LinkedIn Developers	Professional networks, B2B customer portals	LinkedIn app registration
Twitter/X	X Developer Platform	Social media integration, public community portals	Twitter developer account

Configuration parameters

Social identity providers require only 2–3 configuration values in Power Pages:

Parameter	Description	Where to find it
Client ID REQUIRED	Unique identifier for your OAuth application at the identity provider	App registration in the provider console
Client Secret REQUIRED	Secret key for authenticating your application to the provider	App registration secrets section
Reply URL AUTO-GENERATED	Power Pages callback URL where users return after authentication. Copy from the Power Pages wizard, paste into the provider console.	Format: `.../signin-{provider}` (e.g. `/signin-google`, `/signin-facebook`, `/signin-microsoft`)

Optional additional settings

All social providers share these optional advanced settings (expand "Additional settings" in the Power Pages wizard):

Setting	Description
Scope	Comma-separated list of permissions to request (e.g. `email,profile`)
Registration enabled	Off: denies registration if no contact exists. On: allows new user registration (if the site setting permits).
Contact mapping with email	On: associates a unique contact record with a matching email address. Not applicable for Microsoft's multitenant endpoint.
Authentication type	OWIN authentication middleware type (advanced — usually leave default)
Backchannel timeout	Timeout in milliseconds for back-channel communications (advanced)

Social OAuth vs. generic OAuth/OIDC

Aspect	Social OAuth (wizard)	Generic OAuth/OIDC (manual)
Supported providers	Only 5: Microsoft, Google, Facebook, LinkedIn, Twitter/X	Any OIDC-compliant provider (Entra External ID, Auth0, Okta, custom)
Setup method	Wizard with 2 fields (Client ID + Secret)	Manual with 9+ parameters
Configuration	Authority/Metadata auto-configured	You provide Authority, Metadata Address, Scopes, Response Type, etc.
Primary use case	B2C consumer portals, public websites	B2B enterprise portals, advanced features
Token format	JWT (JSON)	JWT (JSON)
Complexity	Very low	Low–medium
Advanced features	Limited (no custom scopes, limited claims mapping)	Full control (custom scopes, claims, token validation)

When to use social identity providers?

Use social OAuth when:

Building B2C customer portals or public-facing websites
Users already have Google, Facebook, Microsoft, LinkedIn, or Twitter/X accounts
You want the fastest possible setup (under 10 minutes)
You don't need custom claims mapping or advanced token validation
The target audience is consumers, not enterprise employees

Use generic OAuth/OIDC instead when:

Building enterprise B2B portals with a corporate IdP (Entra External ID, Okta, Auth0)
You need custom claims mapping from the IdP to Dataverse contact fields
You require advanced token validation (audience, issuer, custom validators)
You want control over scopes, response types, response modes
Using a provider not in the list of 5 (e.g. Ping Identity, Keycloak, a custom OAuth server)

Social IdP best practices

Security & privacy considerations

Privacy policy required: most social providers (Facebook, Google) require a privacy policy URL during app registration
Minimal scope requests: only request permissions you actually need
GDPR compliance: for EU users, ensure social login complies with GDPR (consent, data processing agreements)
Terms of service: review each provider's terms — some restrict commercial use
Email verification: not all social providers guarantee verified emails. Facebook emails may not be verified; Google emails are.

Common pitfalls with social IdPs

Cross-provider SSO doesn't work: users who log in with Google cannot use Microsoft for the same contact. Each social provider creates a separate identity.
Cannot mix social IdPs for SSO: if you configure both Google and Microsoft, they won't share sessions.
Reply URL must match exactly: trailing slash, http vs. https, subdomain — one wrong character breaks it.
Provider app approval delays: some providers (Facebook, LinkedIn) require review before going live, taking days to weeks.
Rate limiting: social providers have API rate limits. High-traffic portals may hit limits during login spikes.

Multi-provider setup strategy

Many portals offer multiple social login options. Recommended approach:

Choose 2–3 providers max — don't overwhelm users with 5 buttons; pick what's relevant for your audience
Monitor usage — track which providers users actually use, remove unused ones
Set up redundancy — configure 2+ providers so an outage on one doesn't lock users out
Keep it simple — one IdP for all apps is ideal; mixing providers across apps confuses users

Session Security Deep Dive

The big question: "If the session cookie is the key to entry, can I just copy it to another machine and be authenticated?"

The short answer

Technically: yes, you could copy the cookie and gain access.
In practice: Power Pages implements security measures to make this harder (but not impossible).

Why this matters

Session hijacking (cookie theft) is a real security concern. If an attacker gets your session cookie, they can impersonate you until the cookie expires.

The risk: an attacker with your cookie doesn't need your password. They're already "in."

Security measures in Power Pages session cookies

Power Pages session cookies have these built-in protections:

Security flag	What it does	Attack it prevents
HttpOnly ✅	JavaScript cannot read the cookie	XSS attacks trying to steal cookies
Secure ✅	Cookie only sent over HTTPS	Network interception on unencrypted connections
SameSite ✅	Cookie won't be sent from other domains	CSRF (cross-site request forgery) attacks
Short expiry ✅	Cookie expires after 8 hours (typical)	Limits the window for abuse if stolen

What Power Pages doesn't check (by default)

IP address — the cookie works from any IP address
User agent — the cookie works in any browser
Device fingerprint — no device binding
Geolocation — no location validation

This means: if an attacker gets your cookie, they can use it from a different machine or location until it expires.

Real-world attack scenarios

Scenario 1: malware on the user's machine

Attack:

Attacker installs malware on the user's computer
Malware reads browser cookies from disk
Malware sends cookies to the attacker's server
Attacker uses the cookie on their machine — full access until expiry

Defense:

Antivirus software (user responsibility)
Keep OS and browser updated
Short session timeout (admin control)
User education (don't use shared devices)

Scenario 2: network sniffing (mitigated by HTTPS)

Attack:

User on public WiFi without HTTPS
Attacker captures network traffic
Attacker extracts the session cookie
Attacker replays the cookie — session hijacked

Defense:

Power Pages forces HTTPS (built-in)
Secure flag on cookies (prevents transmission over HTTP)
Still vulnerable if the user ignores certificate warnings

Scenario 3: XSS attack (mitigated by HttpOnly)

Attack:

Attacker finds a vulnerability in custom portal script
Attacker injects JavaScript targeting document.cookie
The script tries to read the session cookie
The HttpOnly flag blocks access

Defense:

HttpOnly flag (built into Power Pages)
Content Security Policy (configure in the portal)
Input validation on all forms
Regular security audits of custom code

How to minimize risk

For Power Pages admins

1. Short session timeouts (e.g. 2–4 hours instead of 8)

Configured at the Power Pages level
Balance security vs. user convenience
Limits the damage window if a cookie is stolen

2. Conditional Access policies (Entra External ID, requires Premium license)

Restrict by IP range (e.g. corporate network only)
Block suspicious locations
Require a compliant device
Configuration complexity varies by IdP

3. Monitor session activity

Enable diagnostic logging in Power Pages
Review Entra External ID sign-in logs regularly
Look for unusual patterns

4. Use a Web Application Firewall (WAF)

Azure Front Door or similar
Can detect session hijacking patterns (e.g. same cookie from multiple IPs)
Rate limiting to prevent brute force

5. Implement custom session validation

Use the Power Pages Web API or custom code
Check for suspicious behavior (e.g. rapid page access)
Trigger re-authentication if needed

For end users

Important: as a portal user, you have no control over session timeouts or security policies — those are controlled by the identity provider admin and Power Pages admin.

What you can do to protect yourself:

Never access sensitive portals on shared/public computers
Don't stay logged in unnecessarily — log out when done
Keep your browser and OS updated
Use antivirus software
Be cautious on public WiFi (use a VPN if possible)
Clear browser cookies after using shared devices
Report suspicious login notifications immediately

If you need stronger security measures, contact your portal administrator.

Detecting cookie theft

Red flags to monitor:

Indicator	What it means	Action
Same user, different IPs simultaneously	Possible cookie theft	Force logout, require re-authentication
Login from impossible locations	Can't be in the US and China 5 minutes apart	Block session, alert user
Rapid requests from a single session	Automated attack or data scraping	Rate limit, CAPTCHA, or block
User agent suddenly changes	Cookie used in a different browser	Optional: re-authenticate for high-security scenarios

Reality check: what you can actually monitor

Out-of-the-box (no additional tools):

As Power Pages admin:

✅ Diagnostic logs (errors and failures only)
❌ No IP addresses, user agents, or session details
❌ No real-time monitoring capabilities

As Entra External ID admin:

✅ Sign-in logs (Azure Portal → Entra External ID → Monitoring → Sign-in logs)
✅ Shows IP, location, device, browser, success/failure
⚠️ Only captures login events, not ongoing session activity
❌ Can't detect if the same cookie is used from multiple IPs simultaneously

To actually detect the red flags above, you need:

Tool	What it does	Cost
Azure Application Insights	Track Power Pages requests, IPs, sessions	Pay-per-use (~€2–5/GB ingested)
Azure Monitor + Log Analytics	Correlate sign-in logs + Power Pages logs	Pay-per-use (~€2.50/GB)
Microsoft Entra ID Protection	Automatic risk detection (impossible travel, etc.)	Premium P2 (~€8–10/user/month)
SIEM (e.g. Microsoft Sentinel)	Advanced threat detection, custom rules	Enterprise pricing (~€200+/month)

Bottom line: the red flags table shows what you should monitor, but detecting them requires additional tools and budget. For most Power Pages deployments, this level of monitoring is only justified for high-security scenarios (financial data, healthcare, admin portals).

What you can do without extra tools

Practical approach for most projects:

Enable Entra External ID sign-in logs (free, always on)
- Review weekly for unusual login patterns
- Look for logins from unexpected countries
- Check for failed login attempts (brute force?)
Enable Power Pages diagnostic logging (free)
- Captures authentication errors
- Helps debug login issues
- Won't catch session hijacking, but shows system health
Implement Conditional Access (Entra External ID, requires Premium license)
- Restrict logins by IP range (e.g. corporate network only)
- Block high-risk countries
- Require device compliance
- Prevention is better (and cheaper) than detection
Short session timeouts (Power Pages setting, free)
- Reduce from 8 hours to 2–4 hours
- Limits the damage window if a cookie is stolen
- No additional tools needed
User education (free)
- Tell users to log out on shared devices
- Warn about phishing attempts
- Provide a clear "report suspicious activity" contact

Session security comparison

Security measure	Power Pages default	Additional protection available
HTTPS enforcement	✅ Always on	—
HttpOnly cookies	✅ Enabled	—
Secure flag	✅ Enabled	—
SameSite attribute	✅ Enabled	—
IP binding	❌ Not default	Via Conditional Access (Entra External ID)
Device binding	❌ Not available	Via Conditional Access (Entra External ID)
Geolocation checks	❌ Not default	✅ Via Conditional Access (Entra External ID)
Additional authentication factors	❌ Not built-in	Configure at IdP level (complex setup)

The bottom line

Session cookies are vulnerable to theft — this is true for all web applications, not just Power Pages.

The defense is layered security:

Base protections (HTTPS, HttpOnly, Secure flag) → built-in
Short session timeouts → limits the damage window
Conditional Access → blocks suspicious activity (Premium license)
Monitoring & alerts → detect and respond quickly (extra tools needed)
User education → prevents careless mistakes (free)

No single measure is perfect — but together, they make stealing sessions significantly harder and less valuable.

Should you worry?

Low-risk scenarios:

Public marketing portal (no sensitive data)
Internal portal on a corporate network only
Short sessions (2–4 hours) with Conditional Access enabled

High-risk scenarios:

Portal with financial transactions
Access to personal health information
Administrative functions (user management, settings)
Publicly accessible with sensitive data

Recommendation: for high-risk scenarios, implement all available protections (short sessions + Conditional Access + monitoring + WAF). Consider step-up authentication for critical operations.

Conclusion

Authentication in Power Pages is basically three friends passing notes: you, your portal, and Microsoft (or Google, or whichever identity provider you've chosen).

Remember these five things

Use OAuth/OpenID Connect — it's the modern way. SAML is for legacy systems.
It's all about trust — your portal trusts the identity provider's digital signature, like a passport stamp.
Security happens in steps — multiple redirects mean more secure, not broken.
Tokens have expiry dates — usually 1 hour. That's normal.
Check your URLs match exactly — most auth failures come down to a wrong redirect URL.

Now you understand how login works. When something breaks, you'll know exactly where to look.