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.
Power Apps Portals supports four protocols for external authentication:
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:
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.
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.
If you have an identity provider that happens to support multiple protocols, I recommend using Open ID Connect.
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.
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.
[…] post Power Apps Portals: External Authentication appeared first on Engineered […]
[…] you read my previous post, you might be asking yourself why this is necessary, since Power Apps Portals already supports […]
[…] you read my previous post, you might be asking yourself why this is necessary, since Power Apps Portals already supports […]