ENGINEERED CODE BLOG

Power Apps Portals: Authentication Overview

If you’re new to Power Apps Portals, or you’re an Adxstudio veteran, Portal authentication can be a tricky concept – there are a lot of options, and since we’re dealing with getting access to potentially sensitive data, you want to make sure you’re doing it right. I’ve got a few posts lined up on this subject, but I thought I’d start with a general overview of how authentication works in Power Apps Portals.

Logged In Portals Users Are Always Contacts

The first thing you need to understand is that all authentication is done in reference to a contact in CDS. Even if you are building an employee self-service portal, and you are using Azure AD to log in, and those people are licensed Power Apps or Dynamics 365 users, they still need to have a contact record to log into a Portal. The “user” object that represents the currently logged in user is always a contact, and never a system user.

When we talked about the options for Portal authentication, we are talking about who manages the actual usernames and passwords that are associated to contacts in CDS.

Two Main Types

At a high level, there are two types of authentication in Power Apps Portals: local and external.

Local authentication is when the username and password information is stored directly in CDS on the contact record. Usernames can either be the contact’s email address, or a special username field. A hashed version of the user’s password is stored, which makes it possible to verify that the correct password has been entered, but makes it impossible to retrieve their password from the database. While convenient and easy to use, local authentication has be deprecated by Microsoft, and should be avoided.

External authentication is when something outside of CDS is managing usernames and passwords – think Microsoft Accounts, Facebook, Twitter, etc. Users log in with credentials from other services, which are associated with a contact in CDS. These external authentication managers are known as identity providers, and there are a few different protocols for identity management. Portals supports four main external identity protocols: OAuth2, SAML, WS-Federation and Open ID Connect.

One of the great things about Portal authentication is that you don’t need to pick just one of these options – you can enable as many as you want. When you go to the sign in page on a Portal, the user is given a choice between all the configured identity providers.

So why doesn’t Microsoft want you to use local authentication? Well I can’t speak for them, but I can take a guess: Microsoft has a team that is focused on technology meant for authenticating people into applications like Power Apps Portals, and it’s not the Power Apps Portals team – instead, it is the team responsible for Azure AD B2C. I’ll be covering Azure AD B2C in a future post but, in short, it is a single identity provider that itself supports other identity providers like Facebook, Twitter, etc. Rather than Portals having to support Open ID Connect, OAuth2, SAML 2.0, etc, wouldn’t it be nicer if Portals just relied on something else that does authentication for a living?

Also, passing authentication off to external identity providers means Portals no longer needs to worry about saving username, passwords, and doesn’t have to worry about things like password resets. All things which are a pain and better dealt with by people who live and breath authentication.

How Is Authentication Configured?

I’m not going to get into the details of how to setup each of these types of authentication, since that documentation already exists on the official Portals documentation site. However, what I’ll mention here is that, at a high level, authentication is configured using Site Settings. Configuring authentication typically involves three or more Site Settings per provider.

How Do Contacts Get Usernames and Passwords?

While all users of a Portal must be a contact, not all contacts can log into the Portal. How do you go about associating a username and password (either local or external) with a contact?

There are typically two ways that contacts get associated with login information – either via registration or invitation.

Registration is used when the contact doesn’t already exist in CDS. If you’ve enabled open registration on your Portal, new users can sign into your Portal using any of the configured identity providers (or local authentication), which will create a bare-bones contact record associated with those login credentials. After logging in, the user will be presented with their profile page, which gives them the opportunity to fill out more details like their name, contact info, etc.

The invitation process is used when contacts already exist in your system. In this case, you don’t want users to register using open registration, as this will create the blank contacts mentioned earlier. Instead, you want to use an invitation code process to invite them to your Portal. Typically this means sending them an email with a unique code that they can enter when signing into the Portal – with this unique code, the Portal knows to associate the login information with the existing contact instead of creating a new blank one. For more details on the invitation process, see this documentation.

In my next post I’m going to dive a bit deeper into the various protocol supported for external authentication.

19 responses to “Power Apps Portals: Authentication Overview”

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

  2. Ankush says:

    Thanks Nicholas, for the great Post.
    I have an powerapps portal wherein I only want contacts already created in system to access portals.
    To make my portals (secure) I disabled all other authentication except local and even there I disabled registering as a new contact.
    Rather we will have contact created in cds and then we will send username and password to the contact so that we don’t have blank contacts.
    However portal contact does have option to visit profile page and update their details.

    Now regarding setting password, currently we use portals contact form and dialog box to set new password for the contact.

    I am not sure if my approach is completely secure but will look forward to if you have any inputs on the same.

    • Nicholas Hayduk says:

      Hi Ankush,

      I’d recommend using the invitation code process. It sounds like right now you are sending users their username and password in an email, which isn’t secure for a few reasons, including that the email might be intercepted, and because then you know the user’s password (ideally only the user knows their own password).

      Instead, create the contact, and then send them an invitation. They will get an email with a link where they can choose their own username and password.

      This would end up with a similar user experience, but much more secure.

      Nick

  3. Iyke says:

    I am trying to customise the knowledge article detail page, and as far as I’m aware there’s no way to do that using Liquid, unless you want to write a new web template to replace the default hidden one for this page. So I am left with javascript, but the problem is I don’t know how to check whether the user is logged in or not, using javascript. Any help would be greatly appreciated.

  4. JC says:

    Is it possible to embed another website passing the already authenticated user to this site?
    I understand it would depend on what the embeded website supports, but does the portal supports passing the credentials to other site?

    • Nicholas Hayduk says:

      A couple options I can think of – depends on your use case. If you’re just looking for single sign on, if you use something like Azure AD B2C on both sites, users wouldn’t be prompted with another login.

      If your other site needs to know the ID of the contact logged into the portal, there is the support for OAuth 2.0 implicit grant flow:

      https://docs.microsoft.com/en-us/powerapps/maker/portals/oauth-implicit-grant-flow

      This allows you to generate a token that contains the ID of the contact who is logged in. I could imagine a scheme where you pass this token to the other site to enable single sign on.

      Nick

  5. JC says:

    Thank you very much i´ve been reading your posts amd watching your youtube videos, and they are great.

    I have taken a look and ADB2C seems to be the way to go, but don’t know if i understood correctly, if the other site uses ADB2C, can the other site “know” more than just the fact that the users is authenticated?

    • Nicholas Hayduk says:

      I haven’t done this myself, but if the other site has a connection to CDS, there might be some data in the Azure AD B2C claims that might allow you to identify which contact it is. One thing you can look at is the External Identity entity related to the contact – it contains an ID that is unique to the user. Not sure if that ID is specific to the Portal, or if it is ID that would be available in the claims on the other site.

  6. Jeff Orris says:

    Excellent post! I’m a seasoned Dynamics dev. However, authentication wasn’t ever my strong suite with external IdPs. Specifically, bc I wasn’t ever given the task to handle that.

    I have a request to enable SAML2 in Dynamics 365 Online Customer Self-Service Portal and am testing with CircleSSO.

    I have the following requirements (to my knowledge that are required)

    1) SingleLogoutService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location
    2) SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location
    3) urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    4) ds:X509Certificate

    However, I’m fighting on how to implement these values with portal. Do you have a blog on how to achieve this?

  7. Derek H says:

    Hi Nick,

    I am trying to find reference to the deprecation of local authentication, and any timeline for it’s removal but haven’t been able to find any public announcement. Do you have an official source… we have several clients using local auth and cannot use the likes of google/facebook for auth, and Azure B2C could be overkill. The issue we are having is that password changes using the ADX workflow assembly in CRM are not being synced/overwriting cache on the portal (in the most recent case for a couple of days, until we did a full cache refresh)

    • Nicholas Hayduk says:

      Hey Derek,

      Unfortunately the “official” notice was removed – the closest from Microsoft is on https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/migrate-identity-providers where they recommend Azure AD B2C.

      That being said, I can confirm that I’ve had this conversation with the Microsoft Portals product team within the last few weeks, and it is definitely deprecated. The challenge is that Azure AD B2C is not currently supported in all Azure data centers. Until that happens, local login will still be available.

      I don’t consider Azure AD B2C to be overkill – we use it for even small portals with hundreds of users. That would be my recommendation.

      Nick

  8. Derek H says:

    Hi Nick,
    Thanks for the prompt response and answer, I have passed it back to the team. I guess at some stage I am going to have to learn the config of Azure B2C in the next little while.

    I must say last time I looked at trying to get Azure B2C up and running with portals was a very long time ago and the guides out there were old, incomplete or simply didn’t work. Hopefully that has improved since (hell, you probably have a blog post about it)

    Thanks,
    Derek

  9. Eduardo says:

    Hi Nick,

    Thanks for the great article. The company I work with has roughly 250 employees and only about 40 with Microsoft buisness standard licences(these employees work in the office). I plan on implementing a portal for our states covid reporting responsibilities. Do you know if any external logins/page views are included or do these all need to be purchased as add ons? Also is each external authenticator individually priced? I plan on getting a per user power apps plan for myself and the per app plan for the other 39 in office employees. Thank you for any help

    • Nicholas Hayduk says:

      Hi Eduardo,

      There are no external logins or page views included with any other packages – they must be purchased separately as an addon.

      Are the people using the portal employees? If so, they’ll need Power Apps/Dynamics licenses as well – external logins can only be used by people who aren’t employed by your organization.

      I’m not sure what you mean by “is each external authenticator individually priced”. For external logins, you can setup as many other providers (Twitter, Facebook, Google, etc) as you want – you don’t pay for those. You pay each time someone logs in with those (one charge per 24 hours). These logins packs are purchased in bundles of at least 100.

      Nick

  10. Eduardo says:

    Hey Nick,

    Thank you for answering my questions. Is there any reason why you wouldn’t want to or couldn’t have employees use the portal? Like security or lack of user permissions? We have about 300 employees and only about 40ish in the office have a buisness std licences already and I thought we could avoid getting everyone office and power apps licences by using a portal. Most of our emoloyees are field staff and do not need an office license. Mainly trying to create a form to track employee covid symptoms. Thank you very much for your help!

    • Nicholas Hayduk says:

      If people are employees of the organization, they’ll require at least a Power Apps license (or Dynamics, depending on what entities they are interacting with) to access a portal – using external licenses for them is not allowed. A portal can’t be used to avoid licensing – think of it as just another interface for Dynamics/Power Apps.

Leave a Reply

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

Contact

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.