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.

5 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.


  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.

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.