Once our Portal Apps Portal is connected to Azure B2C, we can use our B2C Tenant as the middle-man to allow our Users to log in via their existing credentials with a number of other general Apps or Services.
This can be particularly useful to allow Users to log into our Portal using their existing Facebook, Twitter or LinkedIn Accounts.
This article will focus on how we can connect LinkedIn to our Portal and let our end users log in via their LinkedIn Account Details.
Step 1 - LinkedIn Developer – Create an App
Our first step is to open Linkedin for Developers and create an App that will link our Azure B2C with Linkedin – this can be started here: Developers | Linkedin
From there we can create a New App with the following details:
- App Name
- Linkedin Page to declare your Company or App in Linkedin
- Privacy Policy is preferred to declare how your App will use the Data from any Linkedin User Accounts that link with your App – this is not required and so can be avoided whilst in Development and Testing, but should be detailed as a requirement for any Production Portal given the Handshake between your Application and data from LinkedIn.
With our App declared with Linkedin – this will give us a Client ID and Secret that we will use to configure into Azure B2C
We also need to navigate into Products and add the ‘Sign In with Linkedin’ feature to our App:
We then take this into Azure B2C.
Step 2 - Azure B2C Identity Provider
We start this second step by navigating into Identity Providers.
This will present a standard list of Social OpenID Providers, including LinkedIn.
We can then enable the LinkedIn Provider to configure the connection between our B2C Tenant and LinkedIn – here we supply the Client ID and Secret that LinkedIn has generated for our App.
Once configured in our Azure B2C, this will then give us a Callback URL that we will add into the configuration of our App back in LinkedIn Developer – this is typically: https://[tenant-name].b2clogin.com/[tenant-name].onmicrosoft.com/oauth2/authresp
We also need to create a second Callback URL in the LinkedIn Developer App, this should be in the format: https://[tenant-name].b2clogin.com/[directory-tenant-id]/oauth2/authresp where the directory-tenant-id is taken from our Azure B2C app overview page under essentials, it is the value for ‘Directory (tenant) ID’ here.
N.B. these two callback URLs are case sensitive, and they must be entirely in lower case to work, so make sure you convert both URLS to all lower case!”
Step 3 – See it in action!!
With this in place and our Sign in with LinkedIn Product approved in the App – we can test the way Users can log in or create an Account with our Portal.
If we navigate into our Portal and attempt to log in via B2C, we will see the usual B2C Login but with an additional option to use Linkedin:
We can click on our new LinkedIn option to log in with our existing LinkedIn Account rather than be forced to create a wholly new password just for Azure B2C.
When using our LinkedIn Account with our Portal for the first time, we do still need to register ourselves to Azure B2C and specify the same key details we have configured in our Azure B2C. In our example here: First Name, Last Name and Job Title – as we set up in one of the articles earlier in this series.
As the authentication passes through Azure B2C to then federate with LinkedIn – the Contact tracking works in exactly the same way as non-federated B2C:
- Contacts match / deduplicate on Email Address in the same way
- Each Contact will track the External Identity between Dynamics / Power Apps and Azure B2C
- No Password is stored in Dynamics
This means that (as we would expect with Power Apps Portals) the same Contact Record is captured for each User with the details we need for each Portal User – with the Authentication Provider going via Azure B2C’s connection with LinkedIn so we never need to store a Password in Azure B2C.
Whilst the Contact in Dynamics is exactly the same regardless of the end Identity Provider – we can see this detail in Azure B2C as the broker between validated identities elsewhere and our consumer in Power Apps Portals.
As a general security note, any system where we can avoid storing and particularly viewing a Password is inherently more secure than the alterative – there is a risk where we are outsourcing that authentication to a 3rd party supplier and so are only as secure as that 3rd party’s security itself; but in general Microsoft’s method of handling Azure B2C and LinkedIn’s security will be stronger than any Custom Model we may implement for a specific Portal. (with a possible side note that established Authentication Providers may be a larger target than a smaller ‘homebrew’ system – but in general, leveraging the experience and investment of establishment providers is a stronger security approach.)
This approach of taking the power of the network and interconnected networks working together in the Cloud is in itself a good example of how the Cloud improves over an older approach of dedicated systems or sharing common code modules that are still installed independently on-premise.
This connection of the LinkedIn Account to Azure B2C also ensures that MFA is enforced to validate identities connecting to the Linked identity.
Once done, our end result is that a User can log into our Portal through their LinkedIn Username and Password – meaning that our Portal Audience has one less password to remember.
Whilst simply removing the need for our User’s to have a unique Password may seem like a small improvement – it lowers the barrier to entry or friction for Users adopting our Portal.
This ease of use means that more Users will engage with our Portal, and so allow any Portal Rollout to be more successful.
This concept of getting the foundation right can often be crucial to getting better ROI out of any project or technology deployment.
Step 4 – Direct Connection from Power Apps Portals to LinkedIn
This series of articles is focused on how we can use Azure B2C to connect our Portal to a number of different identity providers for a better and more secure Portal.
But it is worth noting that Power Apps Portals can be connected directly into LinkedIn without going via B2C.
This is available via a new set of functionality from the recent end of 2020 Release Wave of functionality in Power Apps Portals and can be seen from the Power Apps Maker area:
Clicking into Authentication Providers then presents us with a similar list to Azure B2C but with a crucial difference that this is connecting directly from the Portal to LinkedIn
For LinkedIn this requires many of the same details for a Client ID and Secret from our LinkedIn App, and adding the link to allow LinkedIn to passback into your Portal.
There is then advantages and disadvantages to direct authentication vs going through a centralised broker such as your B2C Tenant – with our preference coming down on the side of B2C.
To avoid this article becoming even longer, this will be the subject of a follow-up article looking specifically at this direct route for Portals and LinkedIn.
We hope you found our 5 Part Power Apps Portals Guide helpful – If you have any questions for CRMCS, please don’t hesitate to contact us at contact@crmcs.co.uk
Further Reading…
We understand there are a wealth of articles on Azure B2C – but not too many on integrating with a specific provider such as LinkedIn and seeing this in action with Power Apps Portals, and was one of the reasons for focusing on LinkedIn as a single provider to document how we action these steps.