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.

Provider Protocol Documentation
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
Microsoft OAuth 2.0 Microsoft
LinkedIn OAuth 2.0 LinkedIn
Facebook OAuth 2.0 Facebook
Google OAuth 2.0 Google
Twitter OAuth 2.0 Twitter
Note: Twitter authentication for portals is temporarily unavailable because of the compatibility issues.
Local authentication
(not recommended)
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.

Open registration

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.

Next step

Get started with configuring the authentication for your portal

See also

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