ecLearn - Learning Management System built on top of Microsoft Dataverse for Power Platform and Dynamics 365 users


Power Apps Portals: External Authentication

In my previous post, I gave an overview of authentication with Power Apps Portals, and I mentioned that external authentication is the way to go. In this post, I’ll dive a bit deeper into external authentication.

Supported External Authentication Protocols

Power Apps Portals supports four protocols for external authentication:

  • Open ID Connect
  • OAuth2
  • SAML 2.0
  • WS-Federation

Oldies But Goodies

WS-Federation and SAML 2.0 are older technologies which I don’t see being used as much with Power Apps Portals, but they are still very much supported. I believe WS-Federation is often used to include ADFS as an identity provider, whereas SAML 2.0 is used in a variety of different applications. Power Apps Portals supports having multiple different SAML 2.0 identity providers configured for a single Portal, whereas I believe only a single WS-Federation identity provider is supported.


For OAuth2, Portals supports a specific list of identity providers:

  • Microsoft Account
  • Twitter
  • Facebook
  • Google
  • LinkedIn
  • Yahoo

Unfortunately, unlike the other types of external authentication types, if your OAuth2 provider of choice isn’t on the list, it isn’t supported unless is also supports one of the other types of authentication.

Open ID Connect

The newest type of external authentication protocol is Open ID Connect, which is built on top of OAuth2.

As an aside, the “auth” in OAuth doesn’t stand for authentication, but actually authorization. OAuth is meant for authorizing access to services – think of giving permissions to apps that will post to your Facebook feed on your behalf. It was never really meant for authentication (which is verifying identity). Open ID Connect is a layer on top of OAuth2 specifically meant for authentication.

Power Apps Portals supports any compliant Open ID Connect identity provider, and you can configure as many as you’d like.

What Should You Use?

If you have an identity provider that happens to support multiple protocols, I recommend using Open ID Connect.

Multiple External Identities for a Single Contact

A contact can be related to many external identities – this means that different logins can result in the same contact logging in.

These various identities can be managed on the Manage External Identities page in the Profile section on the Portal. Once logged in, users can add more external identities, or remove existing ones (although they can never remove the last one).

As an example, if someone originally signs up using Facebook, they can then also associate a LinkedIn profile with their Portal account. Then, logging in with either account will result in the same experience.

How Are External Identity Details Stored In CDS?

For external authentication, there is actually a separate entity in CDS that stores the information needed to link a contact to their external identity – this entity is called External Identity. An External Identity record is made up of two main fields: the username and the identity provider. Long story short, when someone logs into the Portal, the Portal uses a combination of which identity provider the user logged in with, and the username returned by that identity provider to find the appropriate External Identity record in CDS. The contact record associated to that External Identity record is then set as the currently logged in contact.

It’s important to note the “username” that the Portal sees from an identity provider is not typically the username that the user enters. It is more often a GUID-type identifier. Also, most identity providers will give out “usernames” that are specific to the app that is being used for authentication. So even if you use the same Facebook account to login into different systems, each of those systems will see a different “username”. So the username field in External Identity doesn’t usually mean much to anyone except the identity provider itself.

In my next post I’m going to cover Microsoft’s preferred identity provider, Azure AD B2C, which is enabled on the Portal using Open ID Connect.

8 responses to “Power Apps Portals: External Authentication”

  1. […] post Power Apps Portals: External Authentication appeared first on Engineered […]

  2. […] you read my previous post, you might be asking yourself why this is necessary, since Power Apps Portals already supports […]

  3. […] you read my previous post, you might be asking yourself why this is necessary, since Power Apps Portals already supports […]

  4. Evin says:

    Have you successfully used an Azure Multi-Tenant app registration for Portal Authentication. I have tried setting it up according to documentation, and I still get an error message that the user needs to be added as a guest to the Tenant, which is what I though the Multi-Tenant option avoided. I am using the common redirect URI:

    Any thoughts?

  5. biggo78 says:


    I posted the question below in the Power Apps Community board recently and posting it here in case anyone has any more ideas. link:

    Is there a way to get the SAML response from an IDP to grab attribute information?

    I’ve configured my portal to authenticate to a 3rd party IDP using SAML2. If the email address doesn’t exist in the portal, it automatically create it in the contact record with first, last, and email address. I want to grab another attribute that’s included in the SAML assertion for my needs. Is there a way to do that through a plugin or another way that I’m not aware of?


    • Nicholas Hayduk says:

      Hi! Unfortunately I haven’t used the SAML2 in depth, so I don’t know the answer to this one.

  6. Ian says:

    Hi Nicholas

    I too am struggling with multitenancy authentication using OpenID Connect do you know if this really is possible?

    Following the documentation results in page not found when clicking on the sign in page

    I’ve not been able to find a single video or blog post showing the setup of this which makes me think its not actually possible.

Leave a Reply

Your email address will not be published. Required fields are marked *


Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365 & Power Platform. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.