Overview of authentication in Power Apps portals
Effective October 12, 2022, Power Apps portals is Power Pages. More information: Microsoft Power Pages is now generally available (blog)
We will soon migrate and merge the Power Apps portals documentation with Power Pages documentation.
In Power Apps portals, each authenticated portal user is associated with a contact record in Microsoft Dataverse. Portal users must be assigned to web roles to gain permissions beyond unauthenticated users. To configure permissions for a web role, configure its webpage access and website access control rules. Portals allows portal users to sign in with their choice of an external account based on ASP.NET Identity. Though not recommended, portals also allows a local contact membership provider-based account for users to sign in.
Power Pages also allows makers to set up authentication. More information: What is Power Pages
Portal users must have a unique email address. If two or more contact records (including deactivated contact records) have the same email address, the contacts won't be able to authenticate on the portal.
The following table lists common identity providers for portals, the protocol that can be used with the provider, and the relevant documentation.
Configuration information about common providers for protocols such as OpenID Connect and SAML 2.0 are given as examples. You can use the provider of your choice for the given protocol, and follow similar steps to configure your provider.
|Azure Active Directory (Azure AD)||OpenID Connect||Azure AD with OpenID Connect|
|Azure AD||SAML 2.0||Azure AD with SAML 2.0|
|Azure AD||WS-Federation||Azure AD with WS-Federation|
|Azure AD B2C||OpenID Connect||Azure AD B2C with OpenID Connect
Azure AD B2C with OpenID Connect (manual configuration)
|Azure Directory Federation Services (AD FS)||SAML 2.0||AD FS with SAML 2.0|
|AD FS||WS-Federation||AD FS with WS-Federation|
Note: Twitter authentication for portals is temporarily unavailable because of the compatibility issues.
|Not applicable||Local authentication|
If you're already using an existing identity provider and want to migrate your portal to use another identity provider, read Migrate identity providers. The example shows how you can migrate an existing identity provider to Azure AD B2C, though you can use the provider of your choice to migrate to.
Portal administrators have several options for controlling account sign-up behavior. Open registration is the least restrictive sign-up configuration, where the portal allows a user account to be registered by providing a user identity. Alternative configurations might require users to provide an invitation code or valid email address to register with the portal. Whatever the registration configuration, both local and external accounts participate equally in the registration workflow. Users can choose which type of account they want to register.
During sign-up, the user has the option of selecting an external identity from a list of identity providers or—in an approach that's not recommended—creating a local account (providing a username and password). If an external identity is selected, the user is required to sign in through the chosen identity provider to prove that they own the external account. In both external or local identity provider situations, the user is immediately registered and authenticated with the portal. A new contact record is created in the Dataverse environment upon sign-up.
With open registration enabled, users aren't required to provide an invitation code to complete the sign-up process.
Configure the Azure AD B2C provider for portals
Configure an OAuth 2.0 provider for portals
Configure an OpenID Connect provider for portals
Configure a SAML 2.0 provider for portals
Configure a WS-Federation provider for portals
Authentication and user management in Power Apps portals