Add external identity provider to your apps with AD B2C

Imagine a website offers you two options to create an account - Sign up with your Google account or create a new account by specifying your email ID and choose a new password. It won’t be a surprise to choose the first option as you don’t have to apply all your creativity to generate and remember a fancy new password. Reusing an existing Google also makes you less worried about your password appearing in some data breaches.

Do you want to offer this experience to your users? Do you want to let them sign up / sign in to your app with their existing social account? Read on to know how you can leverage Azure AD B2C to add this to your site.

Introduction

Remembering passwords for every web site or app that you use is difficult. Your users will thank you if you let them use their existing social accounts such as GitHub, Twitter, Facebook and so on. It makes their experience with your app better and secure. This also helps you as a developer to delegate the user account maintenance to a 3rd party. The 3rd party apps such as Google or Twitter, handle everything about the user’s credentials, multi-factor authentications, password rules etc. and you can rely on the user being verified.

Azure AD B2C offers this integration with 3rd party identity providers almost out of the box. In this post, I will give an overview of what types of social accounts you can add to your app with Azure AD B2C and a high level overview of how it works.

This is part 5 of the series on Azure Active Directory B2C. You can find the earlier posts here.

1. Setting up a tenant in Azure AD B2C
2. Creating and testing user flows in Azure AD B2C
3. Use Azure AD B2C in a React JS SPAB2C
4. Protect your Web APIs with AD B2C

AD B2C offerings

In our ealier posts, we have seen how to use AD B2C to let users sign in to your application by putting in an email ID and a password. This is called Local account in AD B2C. In addition to this, AD B2C offers ways to integrate your app with several external social or enterprise identity providers. Some of the major identity providers supported out of the box are listed below.

• Twitter
• Facebook
• Google
• LinkedIn
• Amazon
• Apple
• Microsoft account
• GitHub (preview)
• WeChat (preview)
• Custom OIDC identity provider

User Experience

So how does this look from an end user’s perspective?

After you provision external identity providers in your AD B2C tenant, the sign-in / sign-up page shows the configured identity providers. User selects one of the identity providers, and they are redirected to the sign in page of that identity provider. The user then signs in to their account on that identity provider. They are then redirected back to your application via AD B2C. While redirecting, the AD B2C issues ID token for that user which contains the claim for identity provider along with other claims configured in AD B2C. Your application can even tailor some behaviour if required using this information about which identity provider the user has signed in with.

The diagram below represents this flow. You can see that after the sign-in process is completed, the application receives the identity provider claim in ID token which in this case is set to ‘twitter.com’ indicating the user signed in with Twitter account.

Configuring an Identity Provider in AD B2C

Let’s see how to configure an external identity provider in AD B2C.

There are two aspects of configuring an identity provider in AD B2C before you can use it on your user flow page. Details for each identity provider differ but these steps remain same.

1. Create an app registration inside the respective identity provider

This is similar to the app registration we create inside AD B2C. You need to create the app registration inside the respective identity provider. Usually most identity providers will have a separate area for creating and configuring app registrations. For example, Twitter has a separate website https://developer.twitter.com, LinkedIn hosts the developer apps on https://developer.linkedin.com/ while for Google, you need to go the Google developer console. This client registration helps establish the connect between AD B2C and the respective identity provider.

When configuring the identity provider app, you need to provide a couple of details from AD B2C, which include the origin URL and a callback URL. These are used by the identity provider to validate incoming request for authentication and then redirecting back to AD B2C which can then do the redirect user to your app.

After creating the app registration, you need to get a client ID and client secret for that app from the identity provider. In some cases (Twitter for example), you need to use values of the API key and secret instead of client ID and secret. These values are then used in the AD B2C configuration for that identity provider.

2. Configure identity provider details in AD B2C

In AD B2C, you create the configuration for each identity provider that you intend to use in your user flows. Each of them needs some details like the metadata URL of the identity provider, the authorization flow, response methods, claims mapping and the client ID and secret obtained from the app registration as explained earlier. The metadata URL for any identity provider exposes information to interact with it using the OAuth2 protocol, such as the authorize and token endpoints. Claims mapping is a process of matching claims received from the identity provider maps to claims in AD B2C. This is necessary as the claim names may not be consistent across various identity providers.

AD B2C supports some identity providers out of the box, which means most of the details are already configured for you and hidden. You only need to create the app registration in the identity provider and configure AD B2C with the client ID and client secret. If you intend to add a custom OpenID connect provider however, you need to configure all the details yourself. I will talk about adding a custom identity provider in a future blog post.

Once these configurations are completed both in the identity provider and AD B2C, then you are ready to consume the identity provider in your user flow. In your user flow, you can see the configured identity provider and select it for that user flow. Users of your app will immediately see the choice on the user flow page such as sign-in or sign-up and hopefully buy you a coffee!

References

Microsoft Docs

Summary

This post was a high-level overview of the possibilities to add 3rd party authentication providers in AD B2C. I hope this post helped you to know another valuable feature of AD B2C. In upcoming posts, I will go through detailed process for adding some of the identity providers to your AD B2C user flows. Let me know in comments your feedback and enjoy learning!