Overview of authentication in Power Apps portals

In Power Apps portals, each authenticated portal user is associated with a contact record in Common Data Service. 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.

Note

Portal users must have an unique email address. If two or more contact records (including deactivated contact records) have the same email address, the contacts will not 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.

Important

Configuration information about common providers for protocols such as OpenID Connect, and SAML 2.0 are provided as examples. You can use any other provider of your choice for the given protocol, and follow similar steps to configure your provider.

Provider Protocol Documentation
Azure Active Directory OpenID Connect Azure AD with OpenID Connect
Azure Active Directory SAML 2.0 Azure AD with SAML 2.0
Azure Active Directory WS-Federation Azure AD with WS-Federation
Azure Active Directory B2C OpenID Connect Azure AD B2C with OpenID Connect
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
Local authentication
(not recommended)
Not applicable Local authentication

Tip

If you're already using an existing identity provider and would like 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 Active Directory B2C, though you can use any 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 may require users to provide an invitation code or valid email address to register with the portal. Whatever of 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, a not recommended approach of 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 Common Data Service environment upon sign-up.

With open registration enabled, users aren't required to provide an invitation code to complete the sign-up process.

Next steps

Get started with configuring the authentication for your portal

See also