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 […]
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: https://login.microsoftonline.com/common/oauth2/v2.0/authorize.
Any thoughts?
I know we’ve done it where Azure AD Multi-tenant is one of the identity providers in Azure AD B2C. And the documentation (https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/configure-openid-settings#enable-authentication-by-using-a-multitenant-azure-ad-application) does indicate that it should be possible for a direct Azure AD integration (I’m 95% sure I’ve set that up as well).
Did you create a new Azure AD app registration, or did you try changing the app registration that comes with Portals to multitenant?
Nick
Hello,
I posted the question below in the Power Apps Community board recently and posting it here in case anyone has any more ideas. link: https://powerusers.microsoft.com/t5/Power-Apps-Portals/Retrieve-SAML-Response-from-Identity-Provider/m-p/823485#M5840
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?
Thanks!
Hi! Unfortunately I haven’t used the SAML2 in depth, so I don’t know the answer to this one.